[css-overflow] Bidi handling for text-overflow and line-clamp ellipses

[jja08111]

The CSS Overflow Module Level 4 draft specifies inconsistent bidirectional (bidi) handling for the ellipsis generated by text-overflow versus the one generated by the line-clamp property.

1. text-overflow: ellipsis: The specification implies that the ellipsis is part of its paragraph for bidi purposes. Implementations typically treat it as inheriting the direction of the line it is attached to.
2. line-clamp (block-ellipsis): The specification for block-ellipsis states that it behaves as if it had unicode-bidi: plaintext.

This leads to two different implementation approaches for what is visually the same feature:

• text-overflow ellipsis inherits the parent's direction.
• line-clamp ellipsis uses plaintext logic to determine its direction.

This difference in behavior is surprising and seems unintentional. We'd like to ensure this behavior.

Context: https://chromium-review.googlesource.com/c/chromium/src/+/6817921/comment/c4178435_9956b836/

cc. @andreubotella @kojiishi

[kojiishi]

/cc @jfkthame Firefox is shipping the <string> option [caniuse].

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow] Bidi handling for text-overflow and line-clamp ellipses, and agreed to the following:

• RESOLVED: both ellipsis are isolates, treated as a neutral char at the paragraph's embedding level, and take their bidi direction from the paragraph

The full IRC log of that discussion

<fantasai> s/Topic/Subtopic/
<TabAtkins> andreubotella: This came up in the review of impl for text-grow/shrink
<TabAtkins> andreubotella: you can set a custom string on block-ellipsis, what happens with bidi
<TabAtkins> andreubotella: for text-overflow, spec implies the text is part of the element's context for text purposes
<TabAtkins> andreubotella: but in existing impls it inherits direction of line
<TabAtkins> andreubotella: in both cases the ellipsis is a bidi isolate
<TabAtkins> andreubotella: but what's the default direction?
<TabAtkins> andreubotella: for text-overflow it presumably inherits from line
<TabAtkins> andreubotella: for line-clamp it says to act like plaintext, based on content
<TabAtkins> andreubotella: this is a spec diff between the two features
<TabAtkins> andreubotella: is it an okay difference? igalia wants to see if it makes sense to consolidate
<florian> q?
<florian> q+
<TabAtkins> andreubotella: or is the bidi handling difference intentional
<astearns> ack fantasai
<TabAtkins> fantasai: I think the right thing is to do text-overflow, treat it as part of the paragraph the line is attached to
<TabAtkins> fantasai: I don't think treating it as plaintext at the epoint where it's at in the nesting structure makes sense
<TabAtkins> florian: are you talking about both, or...
<TabAtkins> fantasai: issue summary says text-overflow treats it as part of the paragraph for bidi purposes
<TabAtkins> andreubotella: I don't remember exact text
<TabAtkins> fantasai: but I do think that's the correct behavior
<TabAtkins> fantasai: it should be part of the paragraph's embedding level
<TabAtkins> andreubotella: in a separate isolate?
<TabAtkins> fantasai: potentially yes
<astearns> ack florian
<TabAtkins> florian: if we do end up on the same answer that's nice, but the two features are different. the way it's specced for block-ellipsis is deliberate, and I think it's right
<TabAtkins> florian: text-overflow is in a weird state in general. what the spec thinks it does is close to Firefox but not identical, and far from Chrome. in many aspect, not just bidi
<TabAtkins> florian: from a spec pov, this is a paint-time operation, not part of the surrounding text. the surrounding text can be scrolled while the ellipsis is painted on top. the ellipsis isn't "inserted", it's floating on top
<TabAtkins> fantasai: that's why using the paragraph's embedding level is good, that won't change as the insertion point moves
<TabAtkins> florian: right. just explaining why the specs are different. one is clearly part of the layout, the other is less clear and might be painted on top
<TabAtkins> fantasai: the block ellipsis does belong to the paragraph, not the surrounding text. so for bidi it should be treated at the paragraph level.
<TabAtkins> andreubotella: for block-ellipsis it creates an isolate and the content of the ellipsis text determines the direction, not the paragraph's content
<TabAtkins> fantasai: I don't think we want that. the ellipsis is usually neutral characters
<TabAtkins> fantasai: and plaintext defaults to ltr if ther'es no strong characters, so the ellipsis will usually do the wrong thing in rtl text
<TabAtkins> fantasai: so that's why I think it needs to take from the paragraph
<TabAtkins> fantasai: whatever text it is that we're "attaching" to
<TabAtkins> fantasai: the style of the text should come from there, and so should the bidi direction. for bidi purposes it should be at the lowest possible embedding level
<TabAtkins> andreubotella: what if the paragraph has unicode-bidi:plaintext?
<TabAtkins> andreubotella: if the paragraph with the ellipsis has plaintext, the embedding level of the para is based on the content of the para. if the ellipsis inherits bidi direction from the para, then inheriting that won't be the same as inheriting from the paragraph
<TabAtkins> fantasai: the q I have is... does the ellipsis originate from its paragraph or the clamping element?
<TabAtkins> florian: the paragraph I think
<TabAtkins> fantasai: consider an LTR document with an rtl quote
<TabAtkins> florian: the block ellipsis is wrapped in an anonymous inline whose parent is the block container's root inline box
<TabAtkins> florian: not the clamping element
<TabAtkins> fantasai: then in that case we should be applying the direction of... hm...
<TabAtkins> florian: reminder, it's specified currently as unicode-bidi:plaintext because you used to think that's the right thing to do
<TabAtkins> fantasai: if plaintext there's two effects. we determine direction from contents, I think that's wrong, it should be from the element setting the string or applying the line clamp
<TabAtkins> fantasai: the other thing it does is it isolates it; for the paragraph it's treated as neutral char.
<TabAtkins> florian: which we do want
<TabAtkins> fantasai: that's probably okay
<TabAtkins> andreubotella: it should definitely be isolate, yes
<TabAtkins> fantasai: even if it's a neutral char it needs to be outside any embeddings in that paragraph; it needs to be participating in the paragraph's base level
<TabAtkins> astearns: if i'm following, this'll apply to both ellipsises?
<TabAtkins> andreubotella: if it's an isolate that inherits from the para, then... that would match Firefox currently for text-overflow:shrink
<andreubotella> s/text-overflow:shrink/text-overflow: <string>
<TabAtkins> fantasai: seems reasonable
<TabAtkins> fantasai: making sure I understand. So it is isolated. as an isolate it behaves as a neutral char at the paragraph's embedding level. within the isolate it takes the direction of the paragraph...
<TabAtkins> florian: are you distinguishing between para or block container, or just saying para because it's easier?
<TabAtkins> fantasai: para is the bidi term. block container is what I mean
<TabAtkins> fantasai: it just can't be plaintext because it would almost always be ltr
<TabAtkins> florian: I think that works for block-ellipsis. for text-overflow, treating as a neutral char doesn't "really" do anything since it's floating and not in the text, but that depends on impl. we need one understanding of it someday, we have two
<TabAtkins> iank_: we can just set an override direction on it presumably. i'm probably fine with that
<TabAtkins> astearns: objections?
<TabAtkins> astearns: if anyone wants more time to dig into it
<TabAtkins> RESOLVED: both ellipsis are isolates, treated as a neutral char at the paragraph's embedding level, and take their bidi direction from the paragraph
<TabAtkins> florian: I think I agree but have a doubt
<TabAtkins> florian: for ellipsis that are primarily punct, yes. but if you have text like "to be continued...", you might want to key off the text, and have the punct line up with it correctly
<TabAtkins> florian: if you have an Arabic bit of text, ellipsis is "to be continued..." where do you want the dots
<TabAtkins> florian: you could sort of see it both ways. going with Arabic isn't inherently wrong
<TabAtkins> fantasai: do we have a pseudo for this ellipsis?
<TabAtkins> florian: not currently, but have a note we want one later
<TabAtkins> fantasai: when we do you can set direction
<TabAtkins> florian: I think that's probably right. for the main case, just punct, it's definitely right. for text cases, we can deal with it in the future.
<TabAtkins> fantasai: when block ellipsis happens, what element does the ellipsis come from?
<TabAtkins> florian: the most nested block-level element involved
<TabAtkins> fantasai: then yes I think this i sthe best answer we can do