Hacker News Reader

Comment by int_19h | Hacker News Reader

"None of the viewport units take the size of scrollbars into account. On systems that have classic scrollbars enabled, an element sized to 100vw will therefore be a little bit too wide. This is as per specification."

Kind of amazing that this is literally the unit meant to solve such problems, and yet it doesn't. And the GitHub discussion seems to imply that it's mostly down to what the existing browsers did?

https://github.com/w3c/csswg-drafts/issues/1766

View on HN

“This is per specification.” is an awful cop-out. It’s something where there was a tolerable workaround, but it was ripped out because only Firefox ever implemented it and no one else wanted to. Even though the viewport units are fundamentally completely wrong on almost all documents without it, so that it’s basically impossible to use them correctly.

And then they continued to completely ignore this in the new units, only caring about the mobile issues.

Perhaps more relevant now is https://github.com/w3c/csswg-drafts/issues/6026 (loosely about bringing something back). The scrollbar-gutter suggestion would be fairly decent, mitigating the minor ugliness of overflow: scroll if the document isn’t long.

vh was also invented to solve the height problem and it didnt. The current workaround still involves javascript! And dvw doesnt even solve the scrollbar problems so , javascript again.

There s so much going wrong with CSS through the years (cough, grid) that one wonders if it's being deliberately sabotaged. But most likely it's suffering from FOMOitis where , every weekly design trend must make its way into CSS.

Or maybe at some point Chrome developers will get fed up and say f'it and invent a new simple pixel level language to do whatever you want.

I’d argue that’s actually a decent description of what Flutter is.

> vh was also invented to solve the height problem and it didnt. The current workaround still involves javascript!

Does it? `min-height: stretch` (expanded into `min-height: -webkit-fill-available` by autoprefixer) plus a `@supports (min-height:-moz-available)` workaround for FF seems to solve the problem, however inconvenient. That's what I've always used anyway.

[1] https://caniuse.com/mdn-css_properties_min-height_stretch

> (cough, grid)

What's wrong with grid?

i find it terrible design that breaks html as a language (that s meant to be readable). a bunch divs positioned arbitrarily via css is much less intuitive than <tables> where you can move blocks of markup to redesign geometrically . It's such a simpler mental model , and a set of <grid> elements would suffice. Changing layout with css grid involves changing multiple classes and is atrocious. Then there is the cryptic syntax where somehow "1 fraction" = "fill the rest of the space with it". I can hardly understand the motivation behind the grid design. Using tables is still much more pleasant, but modern browsers dislike table layouts and render them horribly.

> a bunch divs positioned arbitrarily via css is much less intuitive than <tables> where you can move blocks of markup to redesign geometrically <...> Using tables is still much more pleasant, but modern browsers dislike table layouts and render them horribly.

With html being a semantic markup language, tables should appropriately be used for tabular data. Grids are addressing a layout concern, in which you want to position stuff on your page just so. With grids, you can easily change the arrangement of your elements within a grid at different screen sizes, or opt out of the grid altogether. With html table markup, that would not be not possible.

the main problem with tables (besides render speed) is that it's very hard to prevent them being stretched wide by long contiguous words (like aaaaaaaaaaaaaaaaaa...) and images, and the usual ways to prevent those things don't work right in them. also there's no css rules for rowspan/colspan

> don't work right in them. also there's no css rules for rowspan/colspan

Yeah that's what i m talking about. Someone has been racist to tables

I find it far easier to change things with grid than with tables. I think you might want to check named grid-templates if changing things currently requires changing classes.

How do you do responsive design when your layout is hard-coded as part of your document?

The column-span could be a css property. Still more readable

> Kind of amazing that this is literally the unit meant to solve such problems, and yet it doesn't.

I thought the problem this was literally meant to solve was the ambiguity about what a viewport is on mobile browsers with various browser ui elements (address bar, keyboard) taking up space.

Isn't the problem with scrollbars one that it is easy to get into edge cases that result in infinite loops if the gutter space isn't stable?

The point is that scrollbars also affect what the viewport, meaningfully defined, is.

Getting into infinite loops is a possibility with any non-trivial layout engine if you implement it in certain ways. Per GitHub discussion, though, there is a known algorithm to handle it; the problem is that only Firefox implemented it, and even that as an experiment.

I think one could argue (as many already have) that the purpose of the viewport units is not to solve scrollbar related problems. You can give your <body> element a width of 100% and it will fill all the viewport's space without the scrollbar. 100vw, in contrast, will add the scrollbar's width to this. Having these two be different can be quite beneficial, too.

Such an argument is not useful, because no one wants viewport units that include the document scrollbars. Only with great difficulty can I imagine a valid use case for such units (and the recent CSS property scrollbar-gutter is a better solution for almost all remaining theoretical applications) and don’t believe I have encountered even a single instance in the wild.

actually the 100% thing only works if you also apply it to the html element too (I believe). and that's kind of the problem, 100% refers to the height of the parent. so if you want to have an element that isn't the body fill up at least the entire viewport, you have to apply this to every parent element as well, which can be very annoying depending on the situation. of course what you end up doing is just using 100vh anyway, since you never want there to be a horizontal scrollbar anyway

Reply on news.ycombinator.com