Re: [csswg-drafts] [css-overflow] Is continue: discard working in the fragment tree useful? (#7708)

Here's where I'm at. We have two different approaches.
* One (`continue: discard`) takes a dependency on fragmentation and is thereby largely described, though there remains open questions to look into. The other a new concept (`continue: collapse`), whose basic mechanism is described reasonably simply by @tabatkins in https://github.com/w3c/csswg-drafts/issues/7708#issuecomment-1747840639, though there remains open questions to look into.
* `continue: discard` is overall more complex, but it draws on a mechanism we have anyway; improvements to fragmentation interop or additional fragmentation features developped for the sake of `continue: discard` benefit other uses of fragmentation, and vice versa. `continue: collapse` is overall simpler, but it's something new and isolated.
* Difference in complexity of implementing `continue: discard` over `continue: collapse`, while probably true, should not be overstated: @andreubotella was able to prototype both in a reasonable amount of time.
* Both approches behave very similarly in simple cases (just flat text in a block without any structure to it), and the majority of the compat baggage is such simple cases. So from a compatibility with existing content, we are unlikely to be facing problems that arise from the inherent differences between either approaches.
* From a performance point of view, both approaches have pros and cons, which depend on actual content (and on the evolution of implementation strategies): invoking the fragmentation machinery has costs (at least with current implementations), so `continue: discard` takes a speed bump, but depending on the content that is being skipped, may gain it back because it doesn't need to lay out the parts that are skipped. `continue: collapse` is the other way around: likely cheaper to invoke, but still needing to layout the parts that don't get painted and to pay the cost of doing so.
* Because `continue: discard` is tied to fragmentation, it can be a stepping stone towards [`continue: fragments`](https://drafts.csswg.org/css-overflow-4/#fragment-overflow), which I think would be a very powerful and exciting feature; but that does mean its design is constrained by what makes sense for fragmentation. Because `continue: collapse` is *not* tied to fragmentation, we could make choices in its design that are at odds with the notion that there is a fragmented flow that stops somewhere and needs to be able to resume in a subsequent container, if that were to be useful for our specialized context.

My suggestion would be to temporarily set aside the question of which approach is the winner to pursue, as that seems to be holding back refining the nuances of each. I'd rather explore in detail what each approach means, resolve issues about them, use experimental implementations to find out about compat, performance, play with the pros and cons of their differences…Though the underlying mechanism is different, there may be things that each approach can learn from the other, and we should explore those.

The good news is that they both fit withing the same framework of interacting properties, as they would both be keywords on the `continue` property. I doubt that we will want to support both, but we could, there's no conflict between the two that would prevent that.

So how about that: we write both of them down, file and attempt to resolve issues against either, iterate for a while with insight learned from experimental implementations, and see where that takes us.

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7708#issuecomment-1757260858 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 11 October 2023 09:32:16 UTC