Re: vw/vh/vm units

On Fri, Jul 10, 2009 at 1:51 PM, Aryeh Gregor<Simetrical+w3c@gmail.com> wrote:
> 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 . . .

This situation already exists.  Just open up the following document in
your browser:

<!DOCTYPE html>
<html><head>
<title>Test</title>
<style>
body {
 margin: 0;
 padding: 0;
 background: white;
}

#test {
 background: blue;
 padding-top: 135.5%;
}
</style>
</head><body>
<div id="test"></div>
</body></html>

Change your viewport so that it is the screen height but as skinny as
possible, then play with the percentage until the screen is completely
blue but there's no vertical overflow yet.  If you then increase the
padding-top by a *tiny* bit (half a percent or so), you'll trigger
vertical overflow.  The scrollbar appears, reducing the width of the
viewport, and thus the height of the block as well.  Because the
viewport is very tall and skinny, the height change is greatly
magnified.  In Firefox 3.5 you should see both horiz and vert
scrollbars, both inactive, plus a visible white stripe at the bottom.

This means that, at least in this situation, Firefox resolves the
circular dependency by just keeping the scrollbars but making them
inactive (since the content on the page no longer overflows).

Testing in Safari 4.0 (530.17) shows some slightly different behavior
- at the critical point Safari leaves a white gap on the right where
the scrollbar would be if there were any overflow.

Opera works similarly to Firefox (inactive scrollbar present, though
it doesn't automatically show a horizontal scrollbar like FF does).
IE seems to display a vertical scrollbar at all times, so it's not
subject to this problem.

> 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.

I am completely convinced that they should depend on scrollbar
presence, or in other words, the actual visible width of the window at
any time.  I'll be using vw/vh in exactly the ways you cited - to make
something stretch the full width or height of the screen.  Since all
browsers are already required to deal with the circular dependency
issue, there's no real argument against doing this.

~TJ

Received on Friday, 10 July 2009 19:52:16 UTC