Hacker News Reader

Comment by robust-cactus | Hacker News Reader

So many options when all I ever wanted was 100dvh

A year ago I skimmed through the spec and counted ~40 distance units in CSS (12 font units, 18 viewport units, 7 absolute distance units if I counted correctly).

As you'd expect, none of them do what you'd really want them to do.

Off topic, but analogous:

About a year ago, the last time I checked the Wikipedia page on energy use, I counted IIRC 10-20 different units being referenced. It is almost as if people were working to prevent uniform understanding and intuition.

12 more now apparently

I was just thinking about how many units for measurements are there in CSS. Thanks for providing the answer.

so actually XKCD is wrong https://xkcd.com/927/

standards proliferate because they're bad not because we need to unify standards under one master standard!

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

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.

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);
    }

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.

Reply on news.ycombinator.com