- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Fri, 10 Jul 2009 14:51:33 -0400
- To: www-style@w3.org
I have a few questions about the vw, vh, and vm units (viewport units) from the CSS 3 Values and Units draft: http://www.w3.org/TR/css3-values/#vw First of all, are any browsers planning on implementing them? Are there any known problems with them? Is the spec considered stable and implementable? I haven't found open bugs for either Gecko or Mozilla, so if there's no known problem I'll go ahead and file some (David Hyatt told me on IRC that he thought they would be "very easy to implement"). Second of all, I noticed a possible ambiguity in the spec. It states that the units are "relative to the viewport's width/height". It's not clear (to me) whether this includes the scrollbar or not. I think the most desirable answer is that the width does *not* include the scrollbar ― i.e., the size of a vw will vary based on whether a scrollbar is present just as with resizing the window. A lot of uses of vw/vh would set something's width to 100vw, or its height to 100vh. (This could replace the current ugly situation of having to set html's width or height to 100%, which can break things quite confusingly and doesn't always do what you need.) But if the presence of the scrollbar is ignored, this will immediately cause the content to overflow slightly. Likewise for any set of heights/widths that are meant to add up to 100vh/100vw. Since there's no way to predict whether the scrollbar is present or how wide it will be, it becomes impossible to say "make this box just wide/tall enough that it doesn't overflow the viewport", which is (as far as I can tell) pretty much the *only* likely use of vw/vh/vm. I think that counting the scrollbar's width (height) as part of the viewport's width (height) would *greatly* reduce the utility of vw/vh/vm. Also, it looks like both Gecko and WebKit do not currently count the scrollbar as part of the width of the viewport. Set html { width: 100%; }, which should make the html element the same width as the ICB (and thus the viewport). Then check the width of the html element with and without the scrollbar. They differ, which I think means the viewport size does depend on scrollbar presence in at least Gecko and WebKit. I didn't test other browsers, but I'd expect they're the same. There are problems with depending on the scrollbar, though. You risk circular dependencies. For instance, say the browser window is 800x780px, and 20px of its 800px width is taken up by a scrollbar (so the total visible width is 780px, same as the height). Then let's say we have an element whose left edge is aligned with the left edge of the viewport, with nothing to the right of it (so there's initially no horizontal scrollbar), with width: 101vh;. This is 787.8px. But this will cause a horizontal scrollbar to appear, making the height 760px. Then the width will become 767.6px, which is less than 780px, so the scrollbar might end up disappearing, reappearing, disappearing . . . I don't know if this kind of scenario is likely to come up in practice. But it needs to be dealt with somehow. Maybe it could be noted that it's undefined. It's possible for similar scenarios to crop up already (e.g., foo { display: block; } foo:hover { display: none; }). Can anyone think of a good reason to prefer one particular way of handling this situation? Are there other situations like it that might come up? And does anyone think that vw/vh/vm should actually not depend on scrollbar presence? I think this would *dramatically* reduce their usability. I could provide further explanation of this if anyone's not convinced.
Received on Friday, 10 July 2009 18:52:14 UTC