Hacker News Reader

Comment by techdragon | Hacker News Reader

Honestly most of us probably just wanted 100dvh from the start... the idea that the viewport was "fixed" was less than ideal situation.

View on HN

Also 100dvh is less than ideal, since it snaps between 100svh and 100lvh when the browser's chrome contracts/expands (at least on Safari. I would like to know how google did implement it in Chrome on android). The reflow that this generates is probably even worse than just having the bottom part of the viewport clipped.

The space between is why dvh would be preferable; with this whole vmin/vmax/etc design, you’re setting brittle rules with specific parameters. With dvh it would all just work, and would even match whatever animation the browser used to transition between heights.

In Safari there is no transition. The viewport height snaps between svh and lvh at the end of the browser's chrome collapse/expand animation. I don't have an android phone to check the Chrome's implementation, but I imagine it working in the same way, since animating the heights of potentially all the elements in the page can not be done in an efficient way by the browsers, and having a stuttery scroll as soon as you start scrolling a web page would not be a great user experience.

For most use cases, I think something along the lines of this would do the trick:

    /*
     * Show the element full height but make sure content
     * fits the “small” viewport with the toolbars visible.
     */
    .full-blend {
      height: 100lvh;
      padding-block: calc((100lvh - 100svh) / 2 + 1em);
    }

Reply on news.ycombinator.com