[css-overflow] How should `text-overflow: <string>` handle forced line breaks?

[jja08111]

Summary

The specification for text-overflow does not appear to define the expected behavior when the value contains a forced line break character (e.g., \0A). This has led to differing behaviors between browser implementations, creating an interoperability issue.

Details

During the implementation of text-overflow in Chromium, a question was raised about how to handle a string containing a forced line breaks character, for example, on a paragraph with white-space: pre.

There are currently different behaviors in browsers:

1. Chromium: In the related implementation patch, a string containing \0A results in the character being rendered as a missing glyph symbol (☒).
2. Firefox: The newline character is effectively removed from the string. For example, if the overflow string is 12 \0A 34, it is rendered as if it were 12 34.
3. Safari: String values not supported.

Discussion & The Question for the CSSWG

This ambiguity was noted during the Chromium patch review. The behavior was not discussed in related issues #11660 or #11683. The current thinking is that this behavior is undefined because forced line breaks are typically handled during the layout phase, before the text shaper (which would handle the overflow string) is invoked.

This issue is filed to seek clarification from the CSSWG on the intended behavior. What should an implementation do when a forced line break character is present in the text-overflow: <string>?

Possible resolutions could be:

• The line break character should be stripped from the string (Firefox's behavior).
• The character should be rendered as a replacement or missing glyph character (Chromium's behavior).
• The character should be treated as another form of whitespace, like a space.
• The spec should define that including such control characters makes the value invalid.

We believe the specification should be updated to provide a clear directive for this case to ensure consistent rendering across all user agents.

[SebastianZ]

One solution might also be to allow forced line breaks but clip the string to be one line high.

There's already a note in the spec. about avoiding layout reflows:

Setting the block overflow ellipsis's line-height to 0 makes sure that inserting it cannot cause the line’s height to grow, which could cause further relayouts and potentially cycles. This is almost equivalent to inserting the block overflow ellipsis as a paint-time operation, except that it still participates in alignment and justification. The downside is that unusually tall / deep glyphs in the block overflow ellipsis may overflow.

So the ellipsis might be rendered as if line-clamp: 1 ''; were applied to it. That would apply to the ellipses in both text-overflow and block-ellipsis.

Sebastian

[frivoal]

That note is about block-ellipsis. text-overflow has different mechanics.

[andreubotella]

That note is about block-ellipsis. text-overflow has different mechanics.

I don't think they're different enough. There's a lot of common behavior that's expressed in different words – for example, I think this line-height: 0 behavior for block-ellipsis is included in the "Ellipsing only affects rendering and must not affect layout" spec text for text-overflow.

I think whatever solution we end up choosing for text-overflow should also apply to block-ellipsis; but I'm not sure that clamping the ellipsis text itself is a good idea.

I'd say that if the string text has a forced line break, this is almost certainly a bug by the web developer; but since the presence of a forced line break depends on white-space-collapse, this isn't something that can be detected at parse time. Given that, an option could be to fall back into behaving like text-overflow: clip in that case. But another option would be to treat the string as ending at the first forced break – essentially @SebastianZ's proposal of clipping it to be one line high, but without (re?)ellipsizing it.