- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 25 Feb 2026 16:16:29 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-overflow] How should `text-overflow: <string>` handle forced line breaks?``, and agreed to the following: * `RESOLVED: line breaks are suppressed as in ruby` <details><summary>The full IRC log of that discussion</summary> <florian> q+<br> <ydaniv> andreubotella: related to line-clamp, what happens when you have a force line break, even if you have a span inside the paragraph, and the elipsis string still forces a line break<br> <ydaniv> ... currently Firefox seem to remove the new line from the string<br> <ydaniv> ... it's not clear what the behavior should be, and whether is should be common to text-overflow and elipsis<br> <ydaniv> ... for text-overflow I think it should be that elipsis can not occupy more than one string<br> <ydaniv> ... either trimming the new line or removing it<br> <dbaron> (maybe Andreu meant "one line" rather than "one string", I think?)<br> <ydaniv> ... for block elipsis, not so clear, but impl. wise would be nice to work the same way<br> <ydaniv> ... it's better to just deal with that line the same<br> <astearns> ack florian<br> <ydaniv> florian: I think problem is were inhering the behavior of white space from outside<br> <ydaniv> ... I also think that generally the whitespace processing is complecated enough, don't want to invent more<br> <ydaniv> ... if we set whitespace nowrap it supress the new line and that's fine<br> <ydaniv> ... perhaps in future we want a pseudo element that handles this, some day<br> <ydaniv> ... but for now new lines turn into spaces and not wrap<br> <ydaniv> ... I think that's simple, and would be my preference<br> <ydaniv> astearns: wondering whether changing the wrap value is an overkill<br> <ydaniv> florian: given we don't have a pseudo class/element to describe it, it's the same<br> <ydaniv> ... so far we don't have a way to address it directly and that's the behavior you get<br> <ydaniv> ... spending a lot of time to describe the behavior is not a good use of time<br> <ydaniv> astearns: if the mechanism is nowrap, may be other side effects we did not consider<br> <dbaron> (what we do seems like it could affect what happens to runs of multiple spaces, under some conditions)<br> <ydaniv> andreubotella: checking if we have chars with forced line breaks even with nowrap...<br> <ydaniv> ... some are converted to whitespace at this points, not sure how all of these interact<br> <ydaniv> florian: some of these would demand a forced line break<br> <astearns> ack fantasai<br> <fantasai> https://www.w3.org/TR/css-ruby/#anon-gen-unbreak<br> <ydaniv> fantasai: perhaps copy the rules of surpressing line breaks in ruby<br> <ydaniv> astearns: shall we resolve on that?<br> <ydaniv> andreubotella: Sebastian proposed another thing that may be interesting, there are other possible solutions, like clipping first line, but probably would be better to supress the line break<br> <ydaniv> PROPOSED RESOLUTION: line breaks are converted to spaces as in ruby<br> <ydaniv> fantasai: not necessarily converted to whitespace, just suppressed, depending on context<br> <ydaniv> PROPOSED RESOLUTION: line breaks are suppressed as in ruby<br> <ydaniv> astearns: objections?<br> <ydaniv> florian: if you look at ruby it has a note that we're doing it since it's simple<br> <ydaniv> ... should we remove it?<br> <ydaniv> astearns: I'd prefer to leave it for now<br> <ydaniv> florian: ok<br> <ydaniv> andreubotella: we should probably link to that issue<br> <ydaniv> ... so that if there's an update<br> <ydaniv> florian: just a comment for now, no issue<br> <florian> https://drafts.csswg.org/css-ruby-1/#issue-f0987196<br> <ydaniv> astearns: if you feel strongly about it please open an issue<br> <ydaniv> RESOLVED: line breaks are suppressed as in ruby<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12557#issuecomment-3960400974 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 February 2026 16:16:30 UTC