1471872 - The <bdo> element should not accept the 'auto' value of the attribute

Status: RESOLVED INVALID

(Core :: Layout: Text and Fonts, defect, P3)

Description

[Jonathan Kew [:jfkthame]]

The spec[1] says:

"Authors must specify the dir attribute on this element, with the value ltr to specify a left-to-right override and with the value rtl to specify a right-to-left override. The auto value must not be specified."

However, currently Gecko implements dir=auto for <bdo> just like it does for other elements, resolving the direction based on the element's contents. This leads to incorrect rendering for content that (incorrectly) uses this value, as seen in bug 1471180.

Testcase:

    data:text/html;charset=utf-8,<bdo dir="auto">د.إ.123.45</bdo>

The expected result should match:

    data:text/html;charset=utf-8,<bdo dir="ltr">د.إ.123.45</bdo>

because the <bdo> element, having an invalid value of the dir attribute, should adopt the directionality of its parent, as per the final step in the algorithm.[2]

The actual result matches:

    data:text/html;charset=utf-8,<bdo dir="rtl">د.إ.123.45</bdo>

because we resolve based on the first strong letter (د), and then override the directionality of all the characters to RTL.

Behavior in other browsers:
* IE11 and Edge match the "expected" behavior above.
* Webkit and Blink have a different behavior: when dir=auto is specified on <bdo>, they do not apply a directional override at all, but use the Unicode bidi algorithm on the contents. I believe this is a bug, and have filed https://bugs.chromium.org/p/chromium/issues/detail?id=857409 to report it.


[1] https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-bdo-element
[2] https://html.spec.whatwg.org/multipage/dom.html#the-directionality

Comment 1

[Jonathan Kew [:jfkthame]]

Attachment: Do not accept dir=auto attribute on the <bdo> element, per HTML spec

This makes our behavior in this case match IE/Edge, and the most reasonable interpretation of the spec I can come up with. The webkit/blink behavior does not seem justifiable at all, IMO (and the Facebook page that depends on it, bug 1471180, is an authoring error that needs to be fixed on their side).

Comment 2

[Jonathan Kew [:jfkthame]]

Attachment: Fix the WPT test selectors/pseudo-classes/dir.html to recognize that di is invalid on <bdo> elements

It turns out there's a WPT test that depends on our (incorrect) existing behavior here, so it will need to be fixed. (Note that no other browser currently passes anyway, according to https://wpt.fyi/results/html/semantics/selectors/pseudo-classes/dir.html.)

Comment 3

[Xidorn Quan [:xidorn] UTC+11]

I don't really buy that spec text. It is a requirement to authors, not to user agents, and I see nothing special for bdo in the sections of handling dir attribute[1][2] so I tend to believe we should not do anything either.

HTML spec has requirements (not uncommon with "must") for authors, while browsers still need to handle the forbidden cases, for example, the HTML spec and Encoding spec require HTML documents to use UTF-8[3][4] while apparently not every HTML document on the web uses that, and thus user agents are contrarily required to support lots of legacy encodings[4].

Given this, I don't think there is anything we need to do from our side, since it's not a requirement for user agents.


[1] https://html.spec.whatwg.org/multipage/dom.html#the-dir-attribute
[2] https://html.spec.whatwg.org/multipage/rendering.html#bidi-rendering
[3] https://html.spec.whatwg.org/multipage/semantics.html#charset
[5] https://encoding.spec.whatwg.org/#names-and-labels

Comment 4

[Jonathan Kew [:jfkthame]]

OK, that seems a workable interpretation; but still leaves a significant interop issue. :\

I opened https://github.com/whatwg/html/issues/3782 to see if we could get some more clarity here.

Comment 5

[Jonathan Kew [:jfkthame]]

Discussion in the WHATWG issue eventually concluded that Firefox's behavior here is correct, so closing this as invalid.

The existing test currently passes in both Firefox and Safari; only the Blink-based browsers are not interoperable on this issue.