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: Thu, 17 Jan 2013 04:41:58 -0800
Message-ID: <CAAWBYDAq8zq4ZqKEA0-rNQ62-GByFgPOhg-actSnC6Ad4vtOpg@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 Thu, Jan 17, 2013 at 4:06 AM, L. David Baron <dbaron@dbaron.org> wrote:
> On Wednesday 2013-01-16 20:00 -0800, Tab Atkins Jr. wrote:
>> 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".
>
> I disagree with this argument.  A common case of pages that are
> consciously single-screen but might occasionally overflow is slides.
> It's relatively common to end up having to present a slide deck at
> an unexpected size due to projector configuration.  When this
> happens, sometimes some of the larger slides end up with scrollbars,
> and it's far better to have the scrollbar than to encourage authors
> to use overflow:hidden in this case.
>
> I'm having trouble thinking of a consciously-single-screen page
> where in the "error" case where they don't fit on a screen, the
> desired behavior is actually to clip rather than have a scrollbar.
>
> That said, I'm also having trouble thinking of a convincing use case
> for 'vw' in this context where percentages (which don't have this
> issue) wouldn't be fine.

My usual styling for my slide decks is such a use-case - they use a
very large <body> as a canvas upon which screen-sized slides are
placed, so I can't use percentages on the slides.  However, the slides
themselves are overflow:auto, so a too-large slide is still fully
reachable.


> Replace the following text:
>
>   # The viewport-percentage lengths are relative to the size of the
>   # initial containing block. When the height or width of the
>   # viewport is changed, they are scaled accordingly.
>
> with:
>
>   # The viewport-percentage lengths are relative to the size of the
>   # initial containing block, adjusted for space that might be
>   # occupied by scrollbars on the viewport.
>   #
>   # The <dfn>scrollbar-adjusted initial containing block</dfn> is
>   # defined to be the same as the initial containing block, except
>   # that, in continuous media, if the user-agent implements
>   # 'overflow' that applies to the viewport (see [[!CSS21]] <a
>   # href="http://www.w3.org/TR/CSS21/visufx.html#overflow">section
>   # 11.1.1</a> for the 'overflow' that applies to the viewport)
>   # using scrollbars that occupy space, it is modified in the
>   # following cases:
>   #
>   #   1. If the computed value that applies to the viewport of
>   #      whichever of 'overflow-x' or 'overflow-y' governs the
>   #      behavior of overflow in the <i>block-flow direction</i>
>   #      [[!CSS3-WRITING-MODES]] (for normal Latin text,
>   #      'overflow-y') is either <strong>'scroll' or
>   #      'auto'</strong>, then on the side on which this scrollbar
>   #      would appear (for normal Latin text, typically the right
>   #      side), the scrollbar-adjusted containing block is reduced
>   #      by the width (or height) that such a scrollbar would
>   #      occupy, though never to a width (or height) smaller than 0.
>   #
>   #   2. If the computed value that applies to the viewport of
>   #      whichever of 'overflow-x' or 'overflow-y' governs the
>   #      behavior of overflow in the <i>inline base direction</i>
>   #      [[!CSS3-WRITING-MODES]] (for normal Latin text,
>   #      'overflow-x') is <strong>'scroll'</strong>, then on the
>   #      side on which this scrollbar would appear (for normal Latin
>   #      text, typically the bottom side), the scrollbar-adjusted
>   #      containing block is reduced by the height (or width) that
>   #      such a scrollbar would occupy, though never to a height (or
>   #      width) smaller than 0.
>   #
>   # When the height or width of the <i>scrollbar-adjusted initial
>   # containing block</i> changes, the lengths of the units must be
>   # scaled accordingly.
>
> Given that definition, the definitions of "vw unit" and "vh unit"
> below could just substitute "scrollbar-adjusted initial containing
> block" for "initial containing block".
>
> Does this seem reasonable?

I think so, yes.

~TJ
Received on Thursday, 17 January 2013 12:42:45 GMT

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