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

> On 15 Jul 2015, at 19:22, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> On Fri, Jul 3, 2015 at 9:20 AM, Florian Rivoal <florian@rivoal.net> wrote:
>> - keep visible+clip computing into auto+clip
> 
> Agree; if you're explicitly just clipping one dimension, better to
> make the other dimension scrollable so you don't lose content, because
> anything overflowing was visible previously.
> 
>> - change overflow:visible + contain:paint to compute into
>>  overflow:auto + contain:paint
> 
> STRONGLY disagree.  overflow:visible + contain:paint was *explicitly
> intended* to allow optimizations surrounding a lack of scrollability.
> This is possible optimization #2 in
> <http://dev.w3.org/csswg/css-containment/#containment-paint>.

overflow:clip was a point of contention during a teleconf where we talked about this but for which you had sent regrets. Let's restart that discussion.

(This is also an continuation to that thread: https://lists.w3.org/Archives/Public/www-style/2015Jul/0013.html, since both discussion got intertwined.)


First, here's a quick summary of how I understood the discussion we had during the teleconf (full minutes here, but they're longer than my summary: https://lists.w3.org/Archives/Public/www-style/2015Jul/0097.html):

1) In terms of name, "overflow: clip" reminds of the clip property, which made a few people think that either it should be a paint-only operation like the clip property (with no effects on BFCs), or that it should be named differently if it really is a variant of "overflow:hidden".

2) If we're doing overflow:clip as a paint-only operation (i.e.: does not establish a BFC), then it makes sense to be able to do overflow-x:clip overflow-y:visible. This would require a rework of the text-overflow and resize properties, since they assume it is impossible for overflow to be visible in one direction only.

3) If it should be a paint only operation (i.e.: does not establish a BFC), several people wondered why we were doing this with the overflow property, rather than with the clip property. I have nothing against extending the clip property, but to be able to use properties like text-overflow or resize on a contain:paint element, contain must work its magic through (computed values of) the overflow property.

4) As long as we're doing a variant of "overflow:hidden", calling it "overflow: hidden no-scroll" sounded preferable to "overflow: clip" to people on the call (Rossen and me explicitly, others not disagreeing), to avoid confusion with the clip property.

5) Rossen and smfr thought that introducing "overflow: hidden no-scroll" just to avoid the cost of scrolling was overkill, and browsers out to be able to detect when the scrolling facilities of "overflow: hidden" are not used, and simply skip allocating buffers when that's the case.


My take is that we have a 3 potential ways forward:


A) "overflow: clip" is a paint only operation, it does not (on its own) create a BFC, and if "contain" is not "paint", you can have "overflow-x:clip" in one dimension and "overflow-y:visible" (and vice versa). Amend the definition of "resize" and "text-overflow" (and anything else that depends on "overflow") to deal with the new possibility of being visible in one dimension only.

B) Rename to "overflow: hidden no-scroll". It creates a BFC. If you specify it in one dimension only and leave the other visible, the visible one computes to auto.

C) Don't introduce a new value to overflow, make "contain:paint" cause "overflow:visible" to compute to "overflow:hidden", and implement heuristics to detect when browsers should avoid allocating the resources needed to do the scrolling.


I don't like A very much, due to the ripple effects, at least on resize and text-overflow and maybe on other things we haven't though of yet, of a) not establishing a BFC and b) being able to be visible in one dimension only. If the use cases for this kind of clipping justify it, I would much prefer having this be pursued independently via extensions to the clip/clip-path properties.

Between B and C, if browser vendors are convinced / can convince each-other than the  heuristics needed to detect when the cost of scrollability can be skipped are realistically possible, then I am fine with C, but if not, we need B.


If we go with B, we need to decide between 2 variants, If we have "contain:paint; overflow-x:visible; overflow-y:something-else;"

B1 => overflow-y:something else acts first, and overflow-x is auto

B2 => contain:paint acts first, and overflow-x is "hidden no-scroll"

As discussed earlier (see the top of this mail and the mail it is replying to), I strongly favor B1, to avoid accidentally dropping content.


Once we decide on all of that, we're left with the point Tab strongly disagreed with, at the top of this mail. Should contain:paint cause overflow:visible to compute to overflow:auto, making sure that no overflowing content gets lost, but requiring the author to explicitly activate whichever of A, B, or C we kept, in order to get all optimizations, or should it cause overflow:visible to compute to whichever of A, B, or C we kept, making maximum optimization straightforward, but at the risk of dropping content?


 - Florian

Received on Tuesday, 28 July 2015 23:53:52 UTC