- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Sep 2024 00:50:02 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-overflow] Line-clamp and approaches to ellipsis insertion`, and agreed to the following: * `RESOLVED: Remove characters *at* break opportunities *in* logical order, for line-break` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> florian: As you might remember, line-clamp has been specced for a few years based on fragmentation<br> <TabAtkins> florian: the longhand that triggers that is called continue:discard<br> <TabAtkins> florian: andreu has been working on an alternative not based on fragmentation, which we're calling continue:collapse<br> <TabAtkins> florian: aside from the primary diff between these two, one thing was deliberately designed into continue:discard and not discussed much, and apparently assumed away in continue:collapse, I wanted to talk about it<br> <TabAtkins> florian: on the line you add the ellipsis, how<br> <TabAtkins> florian: the pre-existing ellipsis mechanism is from text-overflow:ellipsis<br> <TabAtkins> florian: I argue that's not appropriate here<br> <TabAtkins> florian: that's for a single line, which is overflowing the line box. you chop it off at the end of the box, and then some, just enought to add the ellipsis char<br> <TabAtkins> florian: this is a physical operation, it makes sense in that context<br> <TabAtkins> florian: but in line-clamp we're not overflowing<br> <TabAtkins> florian: the logical way to remove content in this context is to act like linebreaking. you basically have a line that's a little too short, so you put a little less content in it<br> <andreubotella> q+<br> <TabAtkins> florian: this means you chop off from the *logical* end of the line, not the physical end<br> <TabAtkins> florian: if you don't do this, you'll chop the logical *middle* of the line, missing *two* parts of the text<br> <TabAtkins> florian: the following lines, and the logical middle of your line<br> <TabAtkins> florian: if you're trying to read the text, it makes no sense<br> <TabAtkins> florian: it's also weird if you split in the middle of words<br> <TabAtkins> florian: dropping at the same boundaries as line wrapping allows you significantly reduces the amount of misunderstandings you can get from chopping text<br> <TabAtkins> florian: kind of secondary, but still<br> <TabAtkins> florian: the issue is a bunch of pictures of text asking how weird it is to chop physically rather than logically<br> <TabAtkins> florian: so what I want is just to establish whether, regardless of discard or collapse, we should indeed preserve this "just do line breaking and break logically" behavior<br> <TabAtkins> florian: also, now that we know how much stuff to remove for the ellipsis, where do we put it? physical end or logical end of the line?<br> <TabAtkins> florian: but that's only relevant if we agree on the first<br> <TabAtkins> addison: i18n discussed this at length recently<br> <TabAtkins> addison: we're fairly strongly supportive of logical string truncation<br> <TabAtkins> addison: it means the kept part of the string makes sense<br> <TabAtkins> addison: and if you made the box wider, the removed text would be at the end of the line and would make sense to come in<br> <TabAtkins> addison: So we think logical truncation makes the most sense. and is the easiest here, because you find a break point and then proceed, rather than doing a bunch of ranges<br> <astearns> ack andreubotella<br> <TabAtkins> andreubotella: currently it's implemented the same as text-overflow:ellipsis in Chrome, after bidi reordering<br> <TabAtkins> andreubotella: I don't oppose doing what Florian said, my initial impl was just following existing chrome ellipsis behavior<br> <TabAtkins> andreubotella: but having heard the bidi reasoning, that sounds fine<br> <emilio> q+<br> <astearns> ack dbaron<br> <TabAtkins> andreubotella: might offer some impl challenges, but don't thi8nk they're insurmountable considering the benefit<br> <TabAtkins> dbaron: my intuition about the logical truncation is that it's sort of like you're doing layout into a shorter line (shrunk by the ellipsis)<br> <TabAtkins> dbaron: that's one way to think about it<br> <TabAtkins> dbaron: one subtlety is how you place the ellipsis, whether it's good to be closer to the text or further after doing this shorter-line layout<br> <TabAtkins> dbaron: so flush with the remaining text, versus flush with the line-end<br> <addison> q+<br> <TabAtkins> dbaron: I think I reasonably strongly agree with the consensus on logical truncation, but don't have a strong opinion on placement of the ellipsis<br> <TabAtkins> dbaron: it's interesting in both cases from a layout perspective<br> <TabAtkins> florian: addison had an interesting comment about that<br> <astearns> ack emilio<br> <TabAtkins> emilio: so we need to agree on ellipsis insertion not messing with following lines layout<br> <andreubotella> q+<br> <TabAtkins> florian: in the continue:collapse that's true, but discard it wouldn't<br> <TabAtkins> andreubotella: depends on how it's implemented<br> <TabAtkins> andreubotella: in chromium I don't think there's a way to preserve the breakpoint after a linebreak<br> <TabAtkins> andreubotella: so the way I was planning to go was to do it all at linebreak time, then the displaced content is pushed to the next line<br> <TabAtkins> andreubotella: but that's not the same as the impl I think emilio is thinking of<br> <TabAtkins> emilio: it would be silly because you'd still have to do the layout of everything past the break point<br> <TabAtkins> andreubotella: my impl wouldn't be doing the extra work<br> <TabAtkins> emilio: so you'd insert it during the first layout pass?<br> <TabAtkins> andreubotella: yes, tho with line-clamp:auto you'd still get two layouts<br> <TabAtkins> emilio: I dont' thi8nk we want line-clamp to cause multipass layout<br> <TabAtkins> andreubotella: you need it for auto, that's "as many lines as fit". not purely a paint-time info<br> <TabAtkins> andreubotella: unless it is in gecko?<br> <TabAtkins> emilio: you clamp the inner block and outer block, it's one pass<br> <astearns> ack addison<br> <andreubotella> q-<br> <TabAtkins> (I don't understand any of this, hopefully it makes sense)<br> <TabAtkins> addison: we talked about positioning in the WG convo<br> <TabAtkins> addison: our thinking is that the ellipsis generally wants to behave as part of the text<br> <TabAtkins> addison: the trick is you probably want to provide the equivalent of a strong marker that matches the next inked character's direction<br> <Bert> q+ to ask how you know what the language/direction of the ellipsis text is.<br> <andreubotella> q+<br> <TabAtkins> addison: you need to know if the run is gonna break or not. ellipsis is a neutral character, you want it to jump to the left or right side of the text, according to where the bidi algo would have put the ellipsis in if was actually in the text<br> <TabAtkins> florian: give it directionality of the thing it replaces<br> <TabAtkins> fantasai: no, directionality of paragraph<br> <TabAtkins> florian: using what it replaces intrigues me<br> <TabAtkins> addison: you don't want it isolated, you want to let bidi just do the job of deciding left or right side<br> <TabAtkins> addison: the characters just before it only provide half the context<br> <TabAtkins> fantasai: you also have to extract it from any embeddings<br> <TabAtkins> fantasai: two approaches you can take<br> <TabAtkins> fantasai: one is it acts like the preceding char, and attaches to that.<br> <TabAtkins> fantasai: dont' think we want that<br> <TabAtkins> fantasai: other is that it belongs to the paragraph<br> <TabAtkins> fantasai: we're not ellipsizing a particular phrase, we're ellipsizing the whole paragraph, so having it take the paragraph's qualities makes sense<br> <TabAtkins> fantasai: it also helps show it's a continuation of the paragraph, not the single phrase<br> <TabAtkins> addison: that's potentially fair, I did some playing with this<br> <TabAtkins> addison: it kinda behaves normally<br> <TabAtkins> addison: I think it's worth going offline and writing it down better, describing why it's a good proxy<br> <TabAtkins> addison: but it is possible that what you're saying it the right answer<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: the fundamental questions are logical or physical clipping (I think logical)<br> <TabAtkins> fantasai: and whether the ellipsis is attached to the immediately preceding character or an attribute of the paragraph itself, and from that the rest falls out<br> <TabAtkins> florian: I support opening a followup for this. My starting position matched fantasai, but addison's remarks made me think there were subtleties<br> <TabAtkins> fantasai: since we're breaking form linebreaking proeprties, not per-character proeprties<br> <TabAtkins> fantasai: it seems like a more natural break, not as strongly attached to the previous character as you would if you broke in the middle of a word<br> <astearns> ack Bert<br> <Zakim> Bert, you wanted to ask how you know what the language/direction of the ellipsis text is.<br> <TabAtkins> Bert: might be different issue, from what I understand it's not always just an ellipsis character, but can be something else<br> <TabAtkins> florian: the spec has an answer for that, whether that answer is what we want is another question<br> <TabAtkins> Bert: okay. if it's an ellipsis you can say it's neutral, but if it's something else...<br> <TabAtkins> fantasai: I also think that case, if it's like "continues on page 25", if you break in the middle eof hot pink small text, but paragraph is generally normal sized black text, you want the "continues on" to follow the paragraph's styling.<br> <TabAtkins> fantasai: and directinality<br> <TabAtkins> fantasai: the ellipsis probably needs to be isolated, but it should take the paragraph's directionality<br> <astearns> ack andreubotella<br> <TabAtkins> andreubotella: I don't have an opinion on this discussion, but if we end up going with "matching the next/prev character", anything other than the paragraph base directiond<br> <TabAtkins> andreubotella: I think in the spec it should be specified in terms of the bidi level of the ellipsis character or replacement string<br> <TabAtkins> andreubotella: Becuase if you're breaking as part of line-breaking, or even afterwards, you wouldn't be placed back further than the bidi algorithm's progress. you'd at least have the levels of the shown characters.<br> <TabAtkins> andreubotella: this follows, should be the same as adding a LTR Mark character<br> <TabAtkins> andreubotella: so I think it should be specced to match impls in that degree<br> <TabAtkins> emilio: agree<br> <TabAtkins> emilio: I think we should at least agree to not do the physical truncation the naive way<br> <TabAtkins> emilio: there are multiple ways to do this that makes sense<br> <TabAtkins> emilio: imagine you don't have the ability to redo the line layout at that tpoint<br> <TabAtkins> emilio: we should still truncate at a point that makes sense, might mean truncating more text than what you originally needed.<br> <TabAtkins> emilio: but that's still way better than putting the ellipsis at the physical end<br> <TabAtkins> emilio: so I think we should at least agree on that, not naive physical clipping where you just remove characters until it fits<br> <TabAtkins> florian: I agree, but I'm not sure what you're proposing is "enough"<br> <TabAtkins> emilio: trying to start from a point nobody disagrees<br> <TabAtkins> emilio: I also feel strongly we shoudln'ta effect layout of following lines, to require no relayout<br> <astearns> ack fantasai<br> <TabAtkins> q+<br> <TabAtkins> fantasai: one possible resolution is you remove up to a valid linebreaking point, not less than that<br> <TabAtkins> florian: in logical space? or is that a separate resolution?<br> <TabAtkins> fantasai: separate. Just saying we remove chunk in linebreaking chunks<br> <xiaochengh> q+<br> <TabAtkins> addison: aren't those related? can you compute a linebreaking opportunity physically?<br> <TabAtkins> fantasai: you can't remove a single letter from English, for example<br> <fantasai> TabAtkins: Emilio, wondering about implications of what you were saying<br> <fantasai> TabAtkins: seems you do line layout, figure out lines<br> <fantasai> TabAtkins: on final line, truncate somehow and put ellipsis in<br> <fantasai> TabAtkins: and missing words don't flow into the next line<br> <fantasai> TabAtkins: they are just hiding<br> <fantasai> emilio: right, don't relayout past breaking point<br> <florian> q+<br> <astearns> ack TabAtkins<br> <TabAtkins> andreubotella: Not sure if we should decide today, it has implications on impl<br> <TabAtkins> emilio: yeah, just wanted to resolve on basic constraints first, like we don't trigger multipass layout<br> <TabAtkins> emilio: you'd expect clamping to make the layout cheaper, not more expensive<br> <TabAtkins> andreubotella: i'm not sure if in blink you can drop lines after layout<br> <TabAtkins> emilio: I think you can, you just don't paint them<br> <TabAtkins> florian: regardless, I think we should ellipsize in logical order<br> <Bert> q+ to ask if 'line-clamp: "\0A …"' works to put the ellipsis on a separate line? And if so, can I right-align that line?<br> <astearns> ack xiaochengh<br> <TabAtkins> xiaochengh: I agree we should do logical clamping<br> <TabAtkins> xiaochengh: but seems complicated, no one size fits all. might have different fonts or colors on ellipsis<br> <TabAtkins> xiaochengh: so I think we need a pseudo-element to style the ellipsis<br> <TabAtkins> florian: eventually yes, I don't think it's needed as a level 1 feature<br> <astearns> ack florian<br> <TabAtkins> xiaochengh: with a pseudo-element we could postpone some of the issues, like where to put the ellipsis (flush with text, or flush with line end)<br> <TabAtkins> florian: maybe with pseudo we could override some of the decisions, but we'd still need a default answer<br> <astearns> ack Bert<br> <Zakim> Bert, you wanted to ask if 'line-clamp: "\0A …"' works to put the ellipsis on a separate line? And if so, can I right-align that line?<br> <TabAtkins> xiaochengh: yeah but at least we wouldn't have to bikeshed too much since it wasn't as fatal to tet it wrong<br> <TabAtkins> astearns: no, defaults are still very important<br> <TabAtkins> Bert: ah, xiaocheng's suggestion just gave me an answer to what happens with the styling of the ellipsis<br> <TabAtkins> astearns: can we resolve to have line-clamp remove characters at break opportunities in logical order?<br> <TabAtkins> florian: Knowing there will be follow-up discussions.<br> <TabAtkins> astearns: concerns?<br> <TabAtkins> emilio: we can add a "barring impl craziness"<br> <TabAtkins> emilio: I think everyone agrees this is the right mode<br> <TabAtkins> florian: yeah, if it ends up impossible we'll have to revisit<br> <TabAtkins> astearns: so looks like agreement that it's necessary, and if impl blocks it, we'll still need some *third* thing<br> <TabAtkins> astearns: objections?<br> <TabAtkins> RESOLVED: Remove characters *at* break opportunities *in* logical order, for line-break<br> <TabAtkins> florian: so I think we e need to still figure out alignment of the ellipsis, and then andreu and emilio argue about what happens with the remaining stuff on the line<br> <TabAtkins> emilio: okay<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10844#issuecomment-2372644310 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 September 2024 00:50:03 UTC