W3C home > Mailing lists > Public > www-style@w3.org > July 2009

vw/vh/vm units

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Fri, 10 Jul 2009 14:51:33 -0400
Message-ID: <7c2a12e20907101151w3e535138k18518fbf8abeb5fc@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:19 GMT