- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Oct 2023 16:37:28 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-overflow] Is continue: discard working in the fragment tree useful?`, and agreed to the following: * `RESOLVED: Spec 'continue: collapse', add issue about whether 'line-clamp' invokes 'discard' or 'collapse'` <details><summary>The full IRC log of that discussion</summary> <fantasai> TabAtkins: We have the 'continue: discard' functionality, part of 'line-clamp' feature<br> <fantasai> ... can say element only has 3 lines of text, ellipsized, discard the rest<br> <fantasai> ... used to be defined in a very bizarre way in WebKit<br> <fantasai> ... want to change<br> <fantasai> ... Currently defined in terms of fragmentation<br> <fantasai> ... we already have a good definitionof how fragmentation works<br> <fantasai> ... Emilio and Ian both have perf concerns about invoking fragmentation<br> <fantasai> ... and wanted to address this in a simpler manner<br> <fantasai> ... that accomplishes the right thing<br> <fantasai> ... but lets us do the rest of the stuff -- suppression, question of what happens to stuff after cut point -- in a cheaper simpler way<br> <fantasai> TabAtkins: Florian had a list of questions, which didn't have clear answers<br> <fantasai> TabAtkins: Andreu and Ian went through the list of questions<br> <fantasai> TabAtkins: and we summarized at the end<br> <fantasai> TabAtkins: a few open questions, but I think that overall this looks reasonably well-defined<br> <Rossen_> q+<br> <Rossen_> q_<br> <Rossen_> q-<br> <fantasai> TabAtkins: assuming it is in fact better for perf, seems it also accomplishes the same thing for author purposes<br> <chrishtr> q+<br> <florian> q+<br> <fantasai> TabAtkins: so, question is, Florian do you still have concerns?<br> <andreubotella> q+<br> <fantasai> TabAtkins: Should we continue to pursue this approach and spec it out?<br> <iank_> q+<br> <Rossen_> ack chrishtr<br> <fantasai> chrishtr: It's not just perf, it's also very difficult to implement fragmentation definition in the spec<br> <fantasai> chrishtr: so I think there's a huge practicality advantage to Emilio's proposal<br> <Rossen_> ack florian<br> <fantasai> florian: Many of the questions have been answered, and I'm now less fuzzy on how it works, so that's helpful<br> <fantasai> florian: Some questions which are important haven't been answered yet, so I suspend judgement until I understand how that works<br> <fantasai> florian: in terms of complexity, yes, version that involves fragmentation is more complex<br> <fantasai> florian: however I wonder if the difference isn't overstated<br> <fantasai> florian: given Andreu has been able to prototype both<br> <fantasai> florian: So it seems more easily within reach than originally suspected<br> <fantasai> florian: However, I'd like to move away from overall battle about the approach without discussing the details<br> <fantasai> florian: just having a meta discussion slows us down<br> <fantasai> florian: we should write both down<br> <fantasai> florian: to be really sure what we mean<br> <fantasai> florian: The fundamental mechanics are different, but at the edges there are likely details that can inform each other<br> <fantasai> florian: E.g. A few interesting questions have been raised about fragmentation, and I think there are answers<br> <fantasai> florian: and for alternative approach, questions that I'd like answers<br> <fantasai> florian: so my preference would be to spec both, and use the implementations from Andreu to explore compat, performance, and usefulness to authors<br> <fantasai> florian: In the trivial cases, both will do the same thing<br> <fantasai> florian: but if you try to apply to more complex content, there will be differences in behavior<br> <fantasai> florian: and being able to see those results will help us understand whether one is better, or if each is better in different cases<br> <fantasai> [missed]<br> <fantasai> andreubotella: I agree with Florian in that maybe we should try to figure out both approaches at the spec level<br> <fantasai> andreubotella: and use the prototypes<br> <Rossen_> ack andreubotella<br> <fantasai> andreubotella: in terms of implementation complexity, 'continue: discard' in Chromium took me maybe three months (not all in one set)<br> <chrishtr> q+<br> <fantasai> andreubotella: with multicol/overflow columns you have discarded behavior... I prototyped that first<br> <fantasai> andreubotella: I had to be judicious in which assertions to fire when boxes were not laid out, but otherwise not much difficulty<br> <fantasai> andreubotella: implementing lne-clamping on top of that was not hard<br> <fantasai> andreubotella: implementation in Firefox, which doesn't have fragments as output would be a lot more complicated<br> <fantasai> andreubotella: not impossible to do without re-architecting, might have more perf cost.<br> <fantasai> andreubotella: my understanding is WebKit is working to output fragments, and WebKit did not want to block on them being able to implement the new model<br> <Rossen_> ack iank_<br> <fantasai> iank_: Wrt implementability, I think Blink is in the best situation for 'continue: discard'<br> <fantasai> iank_: but at the end of the day, I'd like this feature in all engines<br> <fantasai> iank_: implementability will be far easier with 'continue: collapse'; same in WebKit<br> <florian> q+<br> <Rossen_> ack chrishtr<br> <fantasai> chrishtr: to add on about implementation, thanks for details andreubotella<br> <fantasai> chrishtr: 3 months is what I would have expected<br> <fantasai> chrishtr: because we have new layout architecture, we can build this on top<br> <fantasai> chrishtr: I don't think that it's easy at all to do it in WebKit or Gecko, and would have multi-year delay to get feature in hands of developers<br> <fantasai> chrishtr: and it's a highly requested feature<br> <fantasai> chrishtr: as I understand it, the clipping version does solve a lot of their problems, and is way way easier in engines that haven't invested into fragment-based architecture<br> <fantasai> chrishtr: My proposal is to add another value to the spec that is the clipping version<br> <fantasai> chrishtr: don't remove the other one<br> <fantasai> chrishtr: could even ship the other version also<br> <fantasai> chrishtr: but in the nearer term, could implement the second property<br> <andreubotella> q+<br> <fantasai> chrishtr: and then be able to compare in practice, what are the gaps, and allow engines to prioritize adding the second version over time<br> <fantasai> florian: I agree we should spec both. I don't think I'm ready today to decide which should be invoked by the `line-clamp` shorthand<br> <fantasai> florian: because it would be different values on 'continue', e.g. 'continue: discard' vs 'continue: collapse'<br> <Rossen_> ack florian<br> <fantasai> florian: if we can agree on that today, we can make some progress. Going further, I have more issues<br> <fantasai> chrishtr: so we'll spec 'continue: collapse', write down complete spec, add tests, work through issues, and then come back to group<br> <fantasai> florian: and while we're doing this, we can make progress on both variants<br> <fantasai> florian: that sounds good to me<br> <TabAtkins> fantasai: I'm a little confused about the assertion that Gecko doesn't work on a fragment basis<br> <TabAtkins> fantasai: the fundamental layout object in gecko is a fragment; the wholel ayout algo is based on that<br> <Rossen_> ack fantasai<br> <Zakim> fantasai, you wanted to comment on Gecko<br> <emilio> q+<br> <TabAtkins> fantasai: Boxes aren't even a first-class object, fragments are, and boxes are a linked chain<br> <TabAtkins> fantasai: So I'm not sure I udnerstand why this is more difficult in gecko than another engine<br> <TabAtkins> fantasai: not that I disagree with the approach, necessarily, just confused<br> <Rossen_> ack emilio<br> <fantasai> emilio: The main issue is that fragments cannot easily be discarded. So to implement continue:discard, you need to lie and keep the layout object around, and push it into a list of things that haven't been laid out, and figure out how that interacts with everything else<br> <fantasai> emilio: it's not only implementability, but what does "discard" mean for a lot of the things that interact with layout tree, like OM, caret movement, etc.?<br> <Rossen_> ack andreubotella<br> <fantasai> andreubotella: I'm not sure we should ship both variants in non-experimental builds of engines<br> <fantasai> andreubotella: if we agree that discard is better, which I'm not sure we agree, but we ship collapse first, then authors will depend on that. I'm not sure that's what we want to encourage<br> <Rossen_> q?<br> <chrishtr> if collapse works for a developer use case that's great. if it doesn't and a browser supports discard, they'll use that<br> <fantasai> Rossen_: so the last agreement was that we a path forward to experiment with both<br> <fantasai> florian: Proposal would be to spec 'continue: collapse', but an issue in the spec about whether 'line-clamp' invokes that or discard<br> <fantasai> florian: work through issues in both, and see where that takes us<br> <florian> s/but an issue/put an issue/<br> <fantasai> Rossen_: ok, let's take a resolution on that<br> <fantasai> PROPOSAL: Spec 'continue: collapse', add issue about whether 'line-clamp' invokes 'discard' or 'collapse'<br> <fantasai> RESOLVED: Spec 'continue: collapse', add issue about whether 'line-clamp' invokes 'discard' or 'collapse'<br> <florian> s/that or discard/that or 'continue: discard'<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7708#issuecomment-1758081281 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 16:37:30 UTC