Skip to content

Test text-overflow's bidi handling with unicode-bidi: plaintext#60367

Open
andreubotella wants to merge 1 commit into
masterfrom
text-overflow-bidi-plaintext
Open

Test text-overflow's bidi handling with unicode-bidi: plaintext#60367
andreubotella wants to merge 1 commit into
masterfrom
text-overflow-bidi-plaintext

Conversation

@andreubotella
Copy link
Copy Markdown
Member

In w3c/csswg-drafts#12617 it was resolved that the text-overflow ellipsis text is treated as a bidi isolate, with the same directionality as the containing bidi paragraph. There were previously WPT tests for this, added in #57478.

However, although a bidi paragraph's directionality tends to be the same as its value of the direction property, this is not the case with unicode-bidi: plaintext, in which case the directionality is determined by the the paragraph's context. This patch adds a test for this.

In w3c/csswg-drafts#12617 it was resolved that the `text-overflow`
ellipsis text is treated as a bidi isolate, with the same
directionality as the containing bidi paragraph. There were previously
WPT tests for this, added in #57478.

However, although a bidi paragraph's directionality tends to be the
same as its value of the `direction` property, this is not the case
with `unicode-bidi: plaintext`, in which case the directionality is
determined by the the paragraph's context. This patch adds a test for
this.
Copy link
Copy Markdown
Contributor

@frivoal frivoal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.
One minor nit: the width of the ellipsis, measured in px is not fully predictable, so while setting the div's width to 130px will generally work, it could happen that the specific monospaced font picked has very narrow or very wide characters, which leaves room for a different number of Ahem characters in the line before the ellipsis. A width of calc(90px + 4ch) would be more reliable (or maybe calc(90px + 4.1ch), to allow for rounding mistakes).

Not blocking because of that, because in practice, with a 10px monospace font, having 4 characters measure more than 40px or less than 10px is unlikely (on my machine I get 24.03px), so it'll still work out to having room 3 Ahem characters. But ideally, making the test more robust would be preferable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants