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.