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

On Tuesday 2012-12-04 12:45 -0500, Boris Zbarsky wrote:
> On 12/4/12 12:40 PM, Sylvain Galineau wrote:
> >Precisely. And so is there a compelling reasons for the spec to define which type of scrollbars
> >cause which units to adjust?
> 
> I don't think the spec would have to do that.  If we wanted the
> auto-adjusting behavior (which is not obvious), we could just define
> vw/vh to be in terms of the ICB.  Except that happens to be what
> http://dev.w3.org/csswg/css3-values/#viewport-relative-lengths says
> already, except it also talks about "viewport" which is not quite
> the same thing, the claims of
> http://www.w3.org/TR/CSS21/visudet.html#containing-block-details
> notwithstanding...

So the auto-adjusting behavior is not quite that simple, because
there are cases where what the vw/vh units compute to affect whether
there's a scrollbar, and vice-versa.  So with that proposal, there
are some cases with two valid layouts (e.g., a block of text with
width 100vw and no margins, at a viewport size specific to the text)
and some cases with no valid layouts (e.g., an image with width
100vw and no margins, at a viewport size specific to the image).

It's also quite a bit of a layering violation to make computed style
(the computed value of a <length>-valued property) depend on layout
(whether there's a scrollbar).  We made some pretty significant
changes in CSS 2.1 to avoid such problems (which implementations
largely never implemented as CSS 2.0 said).

(I also don't think that the current definition of initial
containing block means it has a different size from the initial
containing block for any reasons related to scrollbars.  It's just
that "viewport" is a term applying only to continuous media, whereas
"initial containing block" is the viewport for continuous media and
the page area for paged media.  But I think we should decide what
behavior we want and then figure out how to describe it.)


I have a pretty strong preference for solving this issue (i.e.,
ensuring that 100vw/100vh are never bigger than the area inside of
the viewport scrollbars).

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

We could also try to do something more complicated for 'auto', but
my inclination is not to do that.  I suspect that trying to do that
would require a good bit of wording about exact conditions, and
would end up being easy to implement in one or two browser engines
but not all of them.


However, we need to make a decision here pretty quickly.  We're
currently planning to ship viewport units in Firefox 19 (which is
expected to ship on February 18).  I think we still (but not for
much longer) have the option of pulling them out of that release if
we want to make changes.

Would other browser vendors be willing to change viewport units to
adjust for the 'overflow' that applies to the viewport?

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Received on Wednesday, 16 January 2013 09:15:20 UTC