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

On Tue, Jan 22, 2013 at 6:14 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> On 01/17/2013 04:06 AM, L. David Baron 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.
>
> For this reason, I'm leaning towards having ''auto'' behave like
> ''hidden'', because this means people won't use ''hidden'' just
> to get the units to fit correctly into an unscrolled viewport...
> and then have the error cases get clipped. They can always use
> ''scroll'' explicitly if they expect to have a scrollbar most of
> the time.

Dammit, I was typing up a rebuttal to this, but then I remembered that
the initial value for 'overflow' is "visible", not "auto", which means
that slides that overflow will actually overflow and be unseeable, not
just generate their own scrollbars, unless the author specifically
covers for that scenario.

In that case, I acknowledge that there's a reasonable user-safety
argument for making "auto" act like "hidden" in both dimensions.

The only argument I continue to have against it is that overflow-x/y
isn't yet specified anywhere, and it's *required* in order to get vw
to shrink for scrollbars while vh is the real height.  Without those,
you're stuck setting "overflow:scroll" and getting a probably-useless
horizontal scrollbar on the screen.

Another possibility is to just pick something safe, and then expose
vw/vh controls directly, as properties only valid on the
viewport-generating element (usually the root, I assume).

~TJ

Received on Wednesday, 23 January 2013 02:34:34 UTC