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

[andreubotella]

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.

[frivoal]

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.

[andreubotella]

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.

Fixed. I followed the other text-overflow: <string> tests without realizing here, I'll make a follow-up PR to fix them (although the Arabic text, and emojis, make that complicated).