- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 17 Dec 2025 17:57:08 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-overflow] Initial value of `block-ellipsis` ``, and agreed to the following: * `RESOLVED: No change.` <details><summary>The full IRC log of that discussion</summary> <fantasai> florian: we have sever properties interacting<br> <fantasai> florian: shorthand is line-clamp<br> <fantasai> florian: one longhand is 'continue'. Answers, if content overflows, do we chop it up? how?<br> <fantasai> florian: Then block-ellipsis says whether we insert an ellipsis<br> <fantasai> florian: If you use line-clamp shorthand, it will say "yes, we chop up content; and yes we insert an ellipsis"<br> <fantasai> florian: But right now the initial value is 'none' for block-ellipsis<br> <andreubotella> s/none/no-ellipsis<br> <andreubotella> q+<br> <fantasai> florian: Which means if you do set 'continue' to something, you don't get an ellipsis<br> <fantasai> florian: andreubotella suggests that ellipsis gets created if you are chopping up content<br> <fantasai> florian: automaticall<br> <fantasai> florian: I won't *object* but I don't think is the right approach. If you want ellipsis, use the shorthand<br> <fantasai> florian: [expanation]<br> <fantasai> andreubotella: [missed]<br> <Rossen3> ack andreubotella<br> <fantasai> andreubotella: In my view, initially we had line clamp being exposed and longhands being exposed<br> <kbabbitt> s/[missed]/when we first opened this issue, the initial value was none, now it's no-ellipsis, just wanted to clarify that/<br> <fantasai> andreubotella: If you can trigger the behavior with 'continue' then we need to figure out what the initial value is<br> <fantasai> andreubotella: because this will only apply in continue contexts<br> <fantasai> andreubotella: I don't think it makes sense to have no ellipsis be the initial behavior because that's probably not what you want in continue contexts<br> <fantasai> andreubotella: Argument about line-clamp property<br> <fantasai> andreubotella: if you say line-clamp: 3; it will use the value of max-lines that you specified<br> <fantasai> andreubotella: but it will use a non-default value of block-ellipsis<br> <fantasai> andreubotella: In the end, would be fine with any decision because I expect that majority of usage would be through line-clamp shorthand<br> <fantasai> andreubotella: but I think ellipsis makes more sense than not<br> <kbabbitt> fantasai: agree with florian that we should not set initial value to have an ellipsis<br> <Rossen3> ack fantasai<br> <kbabbitt> fantasai: continue property was created for regions, where you don't want an ellipsis<br> <kbabbitt> ... we hooked it up to the line-clamp property as a way of [missed]<br> <kbabbitt> ... line-clamp has longhands because it wants to create a model that's much bigger<br> <kbabbitt> ... defaulting block-ellipsis to inserting an ellipsis would be contrary to many of the use cases this was designed for<br> <kbabbitt> ... as florian said, if you want ellipsis behavior, you should set line-clamp<br> <kbabbitt> ... max-lines property will set continue discard and ellipsis value for you<br> <florian> s/way of [missed]/way to explain it in terms of a bigger underlying system/<br> <kbabbitt> ... initial value of continue is also ?? so either way when you set line-clamp to a number, you're setting that number and also the other 2 longhands to non-initial values<br> <kbabbitt> ... that's a particular necessity to set block-ellipsis to initial value and make that value match in shorthand<br> <kbabbitt> ... done for usability<br> <florian> +1 to that<br> <kbabbitt> ... I think this is a case where we already had the right decision<br> <fantasai> andreubotella: If we look at continue for regions, then that makes sense<br> <florian> q?<br> <florian> q+<br> <fantasai> andreubotella: it is true that it was created for that<br> <fantasai> andreubotella: though no browser supports that use<br> <fantasai> andreubotella: I guess I don't have strong opinions one way or another<br> <Rossen3> ack florian<br> <fantasai> florian: I'm not sure we will ever get the bigger vision of what 'continue' can do, but the reason it exists to open that door. If we weren't interested in opening that door, we wouldn't have longhands as all.<br> <fantasai> florian: For people who want to do line-clamp, they should just use the shorthand.<br> <fantasai> Rossen3: So proposed path forward is to stay as-is and resolve as no change. Other thoughts?<br> <fantasai> Rossen3: Objections?<br> <fantasai> andreubotella: No strong objections. For line-clamp use case, I expect I will be using the shorthand.<br> <fantasai> andreubotella: Developer-oriented documentation should point to that.<br> <fantasai> andreubotella: Putting continue: discard aside, there is nothing you can do with the shorthand [...]<br> <fantasai> andreubotella: But those would be identical to ? that you could serialize<br> <fantasai> andreubotella: so no objection<br> <fantasai> Rossen3: anyone else?<br> <fantasai> RESOLVED: No change.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12667#issuecomment-3666517014 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 17 December 2025 17:57:08 UTC