- From: Florian Rivoal <florian@rivoal.net>
- Date: Fri, 3 Jul 2015 18:20:03 +0200
- To: Daniel Holbert <dholbert@mozilla.com>
- Cc: www-style list <www-style@w3.org>
> 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