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

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

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.

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.  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"!)


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

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

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.

I find this counterintuitive, too.

~Danie

Received on Friday, 3 July 2015 06:23:09 UTC