- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 16 Sep 2022 23:48:52 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `continue:discard in the fragment tree`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: continue:discard in the fragment tree<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/7708<br> <TabAtkins> emilio: making line-clamp work using continue:discard has some side effects<br> <andreubotella> q+<br> <TabAtkins> emilio: Based on fragmetnation implies the boxes you clamp don't exist, so OM APIs return 0 sizes, etc<br> <florian> q+<br> <TabAtkins> emilio: And implies that like border-bottom disappears due to box-decoration-break<br> <heycam> q+<br> <TabAtkins> emilio: I think it would be both easier and more useful to impl line-clamp by clamping both content-height, as it does now, and the scrolalble overflow, and hiding the clamped lines rather thand iscarding fragments<br> <TabAtkins> emilio: There's been some discussion - I think in general it's a lot easier to implement but similarly useful<br> <TabAtkins> emilio: So easier to reach unprefixed line-clamp<br> <iank_> q+<br> <TabAtkins> emilio: We could decide to ship line-clamp as a longhand for now and decide what to do about shorthands later<br> <astearns> ack andreubotella<br> <TabAtkins> andreubotella: it's not clear how line-clamp would work with editting (?)<br> <astearns> s/(?)/(!)/<br> <TabAtkins> andreubotella: Not clear where carat woudl go if you move past the clamped line<br> <TabAtkins> andreubotella: Would be less of an issue with emilio's model<br> <astearns> ack florian<br> <TabAtkins> florian: We'd also need to define how padding/etc will work. using fragmentation gets us that, it defines those<br> <TabAtkins> florian: One of the goals is to avoid reinventing all that<br> <TabAtkins> florian: It's true that the discarded part, we have incomplete answers about what to do with abspos in there, what happens to the caret, etc<br> <TabAtkins> florian: So maybe we do use fragmentation, but rather than discard the post-fragmentation is invisible<br> <TabAtkins> florian: but saying that it's easier to do it visually is in conflict with the existing knowledge that it's in conflict with visual stuff<br> <TabAtkins> florian: like bidi content<br> <TabAtkins> florian: in the fragment model, in document order, hen we have enough content to place the ellipsis; that's different from hiding characters at the end of the line<br> <TabAtkins> florian: another complaint about visual aspect is you hvae no control over what gets elided and whether it happens at sensible line-break points<br> <TabAtkins> florian: If using fragmentation, the line breaking properties work<br> <TabAtkins> florian: Another thing which is useful under the current model (and maybe usable under your new model), a lot of people want to clamp at 3 lines, but a lot want to clamp at 100px<br> <TabAtkins> iank_: still possible<br> <TabAtkins> florian: Not impossibl, but undefined. Defined with fragmentation, but not defined without.<br> <TabAtkins> florian: Don't want to display a half-line, for example<br> <TabAtkins> florian: So I think we can find ways to define things in terms of fragmentation that are less mysterious<br> <TabAtkins> florian: And also make some statements about "allowable approximations".<br> <TabAtkins> florian: But I think entirely discard fragmentation would be unfortunate<br> <TabAtkins> iank_: clarification, the visual model is purely about subsequent lines<br> <TabAtkins> iank_: Still do layout placement of ellipsis, etc<br> <TabAtkins> iank_: So not necessarily in conflict with what you want to achieve<br> <astearns> q?<br> <TabAtkins> iank_: I don't wanna have a spec where all the impls do emilio's model, and there's a bunch of soft wording about how it's allowed<br> <emilio> q+<br> <TabAtkins> florian: yeah point is not to write fiction, it's just that if we do emilio's model because it's more useful, we shouldn't omit the useful properties of the current spec<br> <TabAtkins> florian: If we treat it as something like a multicol where additional cols aren't painted, you can have an answer to all the API questions<br> <TabAtkins> iank_: there's still subtle diffs<br> <TabAtkins> iank_: in emilio's model it's actually desirable that you don't fragment the borders<br> <TabAtkins> emilio: say you calmp in a nested block with border/padding.<br> <TabAtkins> emilio: it has five lines, you clamp at 3, per fragmentation you're supposed to hide the border padding at the bottom<br> <TabAtkins> fantasai: which element has line-clamp here?<br> <TabAtkins> emilio: the bfc<br> <TabAtkins> fantasai: so inside the bfc you have a text with 5 text lines<br> <TabAtkins> fantasai: the bfc says line-clamp:3<br> <TabAtkins> fantasai: so you clamp after three lines, then what's after is clamped<br> <TabAtkins> emilio: no<br> <TabAtkins> iank_: You're just clamping the content box. You set the content box to the size afte clamping and then layout as normal.<br> <iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10735<br> <TabAtkins> [retreading the previous example]<br> <TabAtkins> emilio: the auto height of the inner box is 3 lines tall (plus mbp)<br> <TabAtkins> florian: So you're reinventing fragmentation...<br> <TabAtkins> emilio: no fragment would crop the border<br> <TabAtkins> florian: yeah we have box-decoration-break that lets you control it<br> <TabAtkins> iank_: well they're not repeated, because this *isn't* fragmentation<br> <TabAtkins> [missed]<br> <TabAtkins> florian: If we do it with fragmentation you can choose whether to clip those borders or not<br> <TabAtkins> iank_: You can here, with border:0<br> <TabAtkins> florian: No you can't, you can't predict whther the clamp activates or not<br> <TabAtkins> florian: fragmentation already solved this, dunno why we're reinventing<br> <TabAtkins> iank_: I think this is a small edge case and most people would expect the behavior from emilio's model<br> <TabAtkins> astearns: agree this is probably small, but there are tons of decisions in this space about what to do after a fragment break, and we'd have to reinvent all of these<br> <TabAtkins> emilio: don't think it's reinventing, we just do what we do if you clamp the auto size and visually hide the overlap<br> <TabAtkins> iank_: very similar to empty-cells on tables, or similar to visibility:hidden but not quite<br> <TabAtkins> astearns: ther'es a long queue<br> <florian> q+<br> <florian> ?<br> <TabAtkins> heycam: it's probably more like visibility:collapse on those additional lines at the end, they take up no space and aren't rendered<br> <TabAtkins> iank_: a little diff bc collapse applies to a container, and it of ten gets smushed in size and ther'es some other effects, but yeah<br> <astearns> ack heycam<br> <TabAtkins> iank_: the way we'd implement is exactly like empty-cells<br> <TabAtkins> heycam: at a high level in wk, i think we support getting to the full fragmentation model<br> <TabAtkins> heycam: But we'll need an interim solution, maybe emilio's or similar<br> <TabAtkins> heycam: think it would be useful to enumerate the diff between this and the full fragment solution so we can see what it's most similar to<br> <TabAtkins> heycam: and how likely it is we run into compat issue in the future<br> <TabAtkins> heycam: like gBCR() effects, etc<br> <TabAtkins> heycam: If that would change between the two solutions, that might be risky<br> <astearns> ack iank_<br> <TabAtkins> iank_: broadly i'm supportive of emilio's suggestion<br> <TabAtkins> iank_: webdevs strongly desire an unprefixed line-clamp<br> <TabAtkins> iank_: We, Blink, are probably the closest to ahving a fragmentation solution, but still a ways away<br> <TabAtkins> iank_: emilio's suggestion means all engines can ship something highly interoperable fairly quickly that will satisfy webdev demands<br> <TabAtkins> iank_: dont' want fiction, so if we do emilio's, want it in the spec<br> <TabAtkins> iank_: emilio's gets us there very quickly<br> <TabAtkins> iank_: I don't think emilio's and fragmentation are exclusive<br> <TabAtkins> astearns: If we come up with a list of things that are going to be different, how can we move from one to the other?<br> <TabAtkins> iank_: I don't think that we will<br> <TabAtkins> iank_: I think we'll be shipping whichever we start with<br> <TabAtkins> iank_: So like, I don't believe3 we'll be able to straight unprefix -webkit-line-clamp even with emilio's solution, bc devs are already depending on scrollable overlow returning a particular value to tell if clamping applied<br> <TabAtkins> iank_: I suspect we'll get somethign similar<br> <TabAtkins> iank_: with abspos at the end, for example<br> <TabAtkins> heycam: so what i'm hearing is that if we come to the full solution it will need a switch<br> <TabAtkins> iank_: I think that's ok; they're related problems but not necessarily the same<br> <TabAtkins> iank_: When we want to truncate content and continue it in a different fragmentatin, i wouldn't be sad if that was a different set of fragmentation properties<br> <TabAtkins> iank_: people are today using prefixed line-clamp and unhappy about it, we can all ship an unprefixed line-clamp with emilio's solution<br> <TabAtkins> astearns: but it's still different than emilio's?<br> <TabAtkins> iank_: P sure we can translate most of it over, only big compat change will be the scrollable overflow size change<br> <astearns> ack emilio<br> <astearns> ack florian<br> <TabAtkins> florian: I don't want fiction either, so I'm happy to make accommodations so we can match impls<br> <TabAtkins> florian: but i wanted to circle back to one potential differenence, because i didn't understand an earlier answer<br> <TabAtkins> florian: with emilio's, is it possible to "clamp after however many lines it takes to reach 300px"?<br> <TabAtkins> emilio: could be feasible, define that instead of "hide lines after the third" you'd hide all lines whose block-end edge is after 300px<br> <TabAtkins> florian: so you'd size the container to 300px, fill it in, start filling in content, then remove after...<br> <TabAtkins> emilio: not remove<br> <TabAtkins> florian: you said you'd draw the mbp of children at the bottom, so you'll need to make room to insert those back<br> <TabAtkins> florian: Note it's not the containr border i'm talking about, it's the content element's border<br> <TabAtkins> florian: before ocunting lines you don't know how many lines you'll take<br> <TabAtkins> fremy: you add both top and bottom mbp as you add it, then fill in lines until you hit the limit<br> <TabAtkins> iank_: yup<br> <TabAtkins> iank_: our -webkit-line-clamp will already abort and retry for compliated reasons. this is fine<br> <TabAtkins> florian: what troubles me is not that it's undoable, clearly it is and is even simpler, but it will have something *very similar* to fragmentation which isn't quite fragmentation.<br> <TabAtkins> astearns: which makes you uneasy<br> <TabAtkins> florian: yeah<br> <TabAtkins> florian: The bidi part I'm not sure how you solve<br> <TabAtkins> florian: we don't control what chunk of text on the last line is okay to remove<br> <TabAtkins> florian: this is a known problm of the existing paint-based ellipsis<br> <TabAtkins> emilio: i think blink does layout-time ellipsis<br> <TabAtkins> emilio: presuambly they ahve to reshpare arbitrary content when inserting it to avoid clipping<br> <TabAtkins> florian: and it can push content around?<br> <andreubotella> q+<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <TabAtkins> iank_: I'll ahve to double check, but i think we'll reshape, like if you land on a bad ligature we'll go back and split it<br> <TabAtkins> florian: it's not just painting a ligature, it's about dropping letters or a whole word<br> <TabAtkins> florian: simila for an abspos in the content, the static position changes depending on whether it's pushed to the next line or not<br> <TabAtkins> iank_: I think abspos are break oppos in our impl for this reason<br> <TabAtkins> astearns: next queue<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: there's a number of directions people ahve wanted to extend this in, and starting from fragmentation model gets you to a bunch of different places that we want to end up<br> <TabAtkins> fantasai: while starting from a visual model doesn't<br> <TabAtkins> fantasai: I also pasted a funny test case<br> <TabAtkins> fantasai: it's p weird<br> <fantasai> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10738<br> <fantasai> fantasai: This is the model we *want*?<br> <TabAtkins> andreubotella: regarding ellipsis, in current fragmentation there's block-ellipsis where youc an repalce the final lines with something<br> <TabAtkins> andreubotella: how would this work?<br> <TabAtkins> andreubotella: if the string has rtl and ltr characters?<br> <TabAtkins> florian: It's specified, i don't recall the details. I think we insert the string as a string without wrapping oppo and with bidi isolation<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-1249940725 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 16 September 2022 23:48:54 UTC