W3C home > Mailing lists > Public > www-style@w3.org > January 2013

Re: [css3-values] Interaction of vw/vh and scrollbars

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 16 Jan 2013 20:00:00 -0800
Message-ID: <CAAWBYDAheXvqe-0xbqrkehHUZK+LjwMuuRd-3Hdh0t+AT+GRWg@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Sylvain Galineau <sylvaing@microsoft.com>, James Robinson <jamesr@google.com>, "www-style@w3.org" <www-style@w3.org>
On Wed, Jan 16, 2013 at 1:14 AM, L. David Baron <dbaron@dbaron.org> wrote:
> One easy way to do that is to make viewport units depend on the
> 'overflow' that applies to the root (as defined in
> http://www.w3.org/TR/CSS21/visufx.html#propdef-overflow ), such
> that if:
>    * 'overflow:scroll', and
>    * 'overflow:auto' when there is overflow,
> create scrollbars that take up space, then the spec says that the
> space that would be taken up by those scrollbars is subtracted from
> the space for the viewport units.  (This would actually be worded in
> terms of 'overflow-x' for the 'vw' unit and 'overflow-y' for the
> 'vh' unit.)  That's just simple treating 'auto' like 'scroll'.


On Wed, Jan 16, 2013 at 6:28 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
>   - Discussed interaction of viewport units and scrollbars, and avoiding
>     relayout in 'overflow: auto' case.  Need use cases for deciding
>     whether 'auto' should be laid out as 'hidden' or 'scroll'.

I believe I can make a convincing case that we should make "auto" act
like "scroll" in the horizontal axis and "hidden" in the vertical (and
vice versa for vertical pages).

Most pages overflow the viewport.  Even among pages that don't
overflow the viewport, most have the *possibility* to do so - that is,
the author is not making a conscious decision to keep them in the
viewport, and the fact that it's small enough to not overflow is an
accident of content. Thus, by sheer numbers, we should support "auto"
being like "scroll" for vw.

As a second argument, pages which are consciously single-screen and
don't want to overflow the viewport have an overflow value that works
fine for them - "hidden".  Setting it does nothing bad for them,
assuming they don't screw up anywhere and accidentally overflow.  On
the other hand, pages that might overflow have no such value (or
rather, that value is "auto", which doesn't help us).  If they set
"scroll", they'll get scrollbars even when they don't overflow.  In
other words, it's easy for single-screen apps to override the "auto"
behavior if it doesn't work for them, but it's not easy for long-form
apps to do the same.  Thus, the default should favor the long-form
pages, and "auto" should act like "scroll".

As a third argument, regardless of what we choose, some pages will
suffer.  If we default vw to the full width (like "hidden"), pages
which trigger vertical scrollbars will overflow horizontally as well.
If we default vw to subtracting the scrollbar width (like "scroll"),
pages that are short enough to not trigger vertical scrolling will
have a 20px gap between their 100vw wide elements and the edge of the
screen.  I think it's reasonable to argue that horizontal scrolling is
*terrible* (especially for tiny amounts - very frustrating) and a much
worse outcome than a 20px gap in the layout.

For vh, every one of these arguments has the opposite conclusion: (1)
almost no pages horizontally overflow, so the numbers favor ignoring
scrollbar size; (2) horizontal overflow is nearly always either
intentional, in which case you can just set "scroll" yourself, or a
mistake, in which case your layout is borked anyway, and a minor
further borking from vh doing the wrong thing for you is unimportant;
and (3) nearly no pages will end up having only a "tiny" amount of
vertical overflow - they either have no overflow or a lot - and so
there's either nothing wrong or the problem is already large enough
that it overwhelms any problem that a slightly wrong-sided vh brings.

Thoughts?

~TJ
Received on Thursday, 17 January 2013 04:00:47 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:04 GMT