Re: [css-overflow] interaction between "overflow-x" and "overflow-y", when one of them is "clip"

> On 03 Jul 2015, at 08:22, Daniel Holbert <dholbert@mozilla.com> wrote:
> 
> Hi www-style,
> 
> I have several questions on how the new "overflow-[x|y]:clip" value works.
> 
> QUESTION (1): What style fixup (if any) should happen if an element has:
>  overflow-x: visible; /* or just unset */
>  overflow-y: clip;
> 
> ANSWER (I think): Right now, the spec says to promote overflow-x to
> "auto", because the following older spec text applies here:
>   # If one cascaded values is visible
>   # and the other is not, then computed
>   # values are the cascaded values with
>   # visible changed to auto
> http://dev.w3.org/csswg/css-overflow-3/#overflow-properties

Correct.

> I'm not sure this behavior makes any sense in this scenario, though. It
> seems more sensible that "overflow-x:visible" should be promoted to
> "clip", if it's promoted at all.

We can discuss whether visible/clip should compute to clip/clip instead
of auto/clip, but I do think visible together with clip needs to compute
into something that's not visible.
- Values other than visible cause the element to establish a BFC.
  You cannot do that in one direction only.
- The behavior of the resize property is undefined in you're visible
  in one dimension only.

> With the traditional values, I think (?) the promotion-to-"auto" was a
> result of the element becoming scrollable, and needing to also be
> scrollable in the other dimension.

I don't think there is any need to be scrollable in the other direction.
The requirement probably originated because you're either a BFC or
you're not, and we cannot have it in one dimension only.

Also, visible overflow on top of a scrollbar would be problematic, so
we cannot have that. computing to scroll would be needlessly intrusive
if the content didn't actually overflow, and computing to hidden would
risk accidentally dropping content, which is bad. So it's auto. This
justification only applies to visible+auto and visible+scroll, but
the BFC story justifies doing something in all 3 cases, so we might
as well do auto in all cases.

> But in this case, "overflow-y:clip"
> is *not* intended to make the element scrollable. (BUT, it actually
> might make it scrollable after all -- in the other dimension -- via
> forcing "overflow-x" to be "auto"!)

Not sure. If the author wanted clip in both directions, it is easy
to use the shorthand rather than only one of the -x and -y longhands.

If the content does not overflow in the dimension that they left
visible (and which we computed to auto), then the element does not
become scrollable, and we still match the author intention.

However, if the content does overflow in the direction not explicitly
set to clip, and the author did not consider it, the making visible
compute to clip means content disappears. Having visible compute to
auto might be ugly, but at least no content is lost without the author
explicitly asking for it.

Also, clip is meant to be the same as hidden, except you cannot scroll,
even programatically. We should avoid deviating from hidden's behavior
unless we have a good reason.


> QUESTION (2): Given my answer to Q1: now, what fixup happens if we also
> throw in "contain:paint", like so:
>  overflow-x: visible; /* or just unset */
>  overflow-y: clip;
>  contain: paint;
> 
> ANSWER (I think): we still end up with "overflow-x:auto".

Yes.

> You might expect that "contain:paint" would force "overflow-x" to
> "clip", because the contain:paint spec text currently says:
>   # If the computed value of overflow-x or overflow-y
>   # would otherwise have been visible, it must instead
>   # compute to clip.
> http://dev.w3.org/csswg/css-containment/#containment-paint

Maybe I should clarify that text, but in my mind, this clause does
not apply. The specified value of overflow-x (in your example) might
have been visible, but the computed value would not have been visible.


> BUT, this doesn't get a chance to apply, because we'll have already
> promoted "overflow-x" to "auto" when we create its computed value.

Indeed.

> I find this counterintuitive, too.

We could probably reverse the steps here, and have contain:paint
turn overflow-x into clip before overflow-y:[not-visible] gets a
chance to turn it into auto.

But the same argument as above still makes sense to me. The strongest
reason I can think of for an author to specify clip in one direction
and nothing (i.e. visible) in the other is if they did not consider the
possibility that their content might overflow in that other direction.
Dropping content if it does happen (e.g. larger than expected font)
sounds like the wrong thing to do.

The argument is somewhat weakened here, since they did specify
contain:paint, but maybe we can turn it around, and say that
contain:paint should turn visible into auto, not clip. That
would do the same as clip if the content does not overflow,
but would require authors to be explicit about dropping content
if that's what they want.

This goes partly against the idea of the contain property being a
"make things as fast as possible and don't ask me how" switch,
but dropping content without explicit request is bad, and it
is debatable whether contain:strict is such a request. I'd lean
towards saying no, it's a request for isolation and speed, not
for hidding.

Other effects of the contain property may very well do strange things
to your page if you don't think through it, but I don't think they
can hide content altogether.

Bottom line, my suggestion is to:

- keep visible+clip computing into auto+clip
- change overflow:visible + contain:paint to compute into
  overflow:auto + contain:paint

/Florian

Received on Friday, 3 July 2015 16:20:34 UTC