W3C home > Mailing lists > Public > www-style@w3.org > July 2015

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

From: Daniel Holbert <dholbert@mozilla.com>
Date: Thu, 2 Jul 2015 23:22:38 -0700
To: www-style list <www-style@w3.org>
Message-ID: <55962A2E.1050509@mozilla.com>
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

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.

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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:18 UTC