"Authors must specify the dir attribute on this ..."

[jfkthame]

https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-bdo-element

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.

While the spec says that "authors must specify...", it doesn't appear to make it clear how the UA behaves if the author fails to specify the dir attribute, or specifies it with an invalid value.

While the auto value is explicitly prohibited here, it is not clear what a UA should do if the author (incorrectly) specifies it.

Testing (with https://jfkthame.github.io/test/bdo.html) indicates that existing UAs have incompatible behaviors in this case, with three different results for a <bdo dir="auto"> element:

(1) ignore the invalid attribute, apply LTR override (Microsoft)
(2) resolve dir=auto based on content, apply RTL override (Mozilla)
(3) apply Unicode bidi, ignoring the override altogether (Webkit, Blink)

I believe (1) is most consistent with the spec as it stands, though clarification would be useful to confirm this. A case could be made for (2), but this would require a spec change to allow it. I cannot see a justification for (3); this makes no sense for an element that is by definition a bidi override. (Authors wanting such behavior should probably be using <bdi> or similar.)

[domenic]

Hmm. I'm having trouble understanding what's unclear about the specification here, although I'm far from an expert in these areas, and the fact that you've found an interop problem is worth investigating in and of itself.

As far as I can tell, the UA requirements on bdo and dir are entirely contained in the rendering section, specifically the UA stylesheet for bidirectional text.

From what I can see adding dir="auto" is the same as adding dir="asdf"; there are no rules in that section that apply to either dir="auto" or dir="asdf". Is that your reading too?

[jfkthame]

I think that's the most reasonable interpretation; i.e. saying that "the 'auto' value must not be used" means that if it is used it will simply be regarded as invalid, just like any other unrecognized value. Perhaps this could be stated more explicitly, along the lines of "Note that the 'auto' value is not valid for the dir attribute on this element".

(I have a patch for Gecko awaiting review in https://bugzilla.mozilla.org/show_bug.cgi?id=1471872 to fix this, and have filed https://bugs.chromium.org/p/chromium/issues/detail?id=857409 to raise the issue in Blink.)

[domenic]

"The 'auto' value must not be used" is a web-developer conformance requirement, and doesn't impact UAs at all. This is similar to many other restrictions in the spec, e.g. "there must be no more than one title element per document" or "the value must be a string that matches the CSS <color> production" or "the value must be a valid media query list".

We've historically been hesitant to add Note: the above is an authoring conformance requirement; UA conformance requirements are stated elsewhere sprinkled throughout the spec, because we'd have to do so hundreds (thousands?) of times. But without that, we do end up with confusion of the sort you ran into :(. I'm not sure whether stating something about "valid values" would help the situation much either, unfortunately.

Good to hear about the patch/bug, in any case! Hopefully the patch will come with web platform tests?

[jfkthame]

Yes; there's an existing WPT test that was based on the current (incorrect) gecko behavior, so the mozilla bug includes an update to fix this test and add a couple more cases to it.

[jfkthame]

@domenic In response to the proposed Gecko patch, @upsuper suggests[1] that as the authoring requirement that "auto must not be used" doesn't impose any rendering requirement on UAs, and nothing else requires bdo to be handled differently from other elements with regard to dir-attribute handling, the existing behavior is correct and doesn't need any change.

WDYT? Given that this can affect, for example, the display of currency values (see [2] for the real-world example that brought it up) it's an interop problem that we need to figure out one way or another.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1471872#c3
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1471180

[domenic]

the authoring requirement that "auto must not be used" doesn't impose any rendering requirement on UAs,

Yes, that's what I was saying in all my previous comments... I'm sorry if that wasn't clear. See especially my first comment: #3782 (comment) which I thought you agreed with.

nothing else requires bdo to be handled differently from other elements with regard to dir-attribute handling

I'm not sure that's correct. https://html.spec.whatwg.org/multipage/rendering.html#bidi-rendering seems to have specific rules for bdo.

[jfkthame]

nothing else requires bdo to be handled differently from other elements with regard to dir-attribute handling

I'm not sure that's correct. https://html.spec.whatwg.org/multipage/rendering.html#bidi-rendering seems to have specific rules for bdo.

Yes, that was too sweeping a statement, sorry. The rendering rules include:

bdo, bdo[dir] { unicode-bidi: isolate-override; } 

which is obviously specific to bdo. But it doesn't address the issue here. What I don't see is anything about how dir=auto should be resolved to determine the directionality of the bdo element, which will then be imposed on its text (overriding Unicode directionality).

So authors aren't supposed to use auto, per the requirement we've noted, but if they nevertheless do use it, how should the UA render the content? That's the issue on which browsers currently disagree, with three significantly different, non-interoperable results.

You suggested that

dir="auto" is the same as adding dir="asdf"

which seemed reasonable to me on the grounds that auto is not supposed to be used here. But if that's purely an authoring requirement, and does not impose any rendering requirement on the UA, perhaps the correct answer (as @upsuper suggests, IIUC) is that auto should be resolved to LTR or RTL directionality for the bdo element just as it would be for other elements. In that case, it's not at all the same as adding dir="asdf", and Firefox's current behavior would be correct.

Of the three options noted in #3782 (comment), which do you consider the spec to support as the expected rendering behavior?

[domenic]

No, the reason I drew that equivalence is not because of the irrelevant authoring requirement. It's because the UA rendering rules specify nothing, for either dir=auto or for dir=asdf, besides the bdo[dir] rule.

[jfkthame]

Yes, but in general dir=auto is not equivalent to dir=asdf, because of the rules in https://html.spec.whatwg.org/multipage/dom.html#the-dir-attribute for determining the directionality of the element.

So my question remains, is it correct for the browser to apply those rules to a bdo element with dir=auto (as Firefox does), resulting in RTL directionality for the example in https://jfkthame.github.io/test/bdo.html and overriding the normal LTR-ness of the digits there?

Or is it correct for the browser to ignore dir=auto on a bdo element (as MS Edge does), on the grounds that authors were explicitly told it must not be used, resulting in LTR directionality and overriding the normal RTL-ness of the Arabic letters there?

(I can't think of a way to read the spec such that bidi overriding doesn't apply to the bdo element at all, though that seems to be what Webkit and Blink currently do.)

[aphillips]

bdo with dir=auto is semantically unintelligible. It's probably reasonable to think that the user intended to use bdi or to apply unicode-bidi because that is a reasonably common mistake. But the normal effect of bdo is so potentially damaging to the text that ignoring the override might actually be the best thing (even if forcing LTR might help people understand that they are doing it wrong... ;-))

[jfkthame]

What about bdo with dir=asdf or any other "junk" value -- how should browsers render that?

What about bdo without any dir attribute? Does the spec make it clear what to do in this case?

[domenic]

Sorry for dropping this for a bit. Getting back to it...

because of the rules in html.spec.whatwg.org/multipage/dom.html#the-dir-attribute for determining the directionality of the element.

Thank you, I missed those! I was just looking at the UA stylesheet section. Finally my original statement that "I'm far from an expert in these areas" is revealed as extremely true.

As far as I can tell, per spec at least there's no spec treatment of bdo vs. dir. Firefox's behavior thus is correct.

Or is it correct for the browser to ignore dir=auto on a bdo element (as MS Edge does), on the grounds that authors were explicitly told it must not be used

This is not correct, because what authors are told to do has no impact on what browsers must do. Authoring conformance requirements are disconnected from UA implementation requirements. UA implementation requirements are given, for this case, by the UA stylesheet and by the section above.

What about bdo with dir=asdf or any other "junk" value -- how should browsers render that?

In that case the UA requirements appear to be:

• The CSS rule bdo, bdo[dir] { unicode-bidi: isolate-override; }
• The attribute is in no state (because it has no invalid value default), so we fall into "If the element has a parent element and the dir attribute is not in a defined state (i.e. it is not present or has an invalid value): The directionality of the element is the same as the element's parent element's directionality."

What about bdo without any dir attribute? Does the spec make it clear what to do in this case?

Same UA requirements apply as dir=asdf, as far as I can tell.

[r12a]

Wouldn't it make sense to add a sentence to the spec to clarify the expected behaviour, given that we have three incompatible interpretations of the spec intent so far?

[domenic]

I think our best effort in that direction is web platform tests and browser bugs. The spec is fairly clear, if a bit spread out. There's also the persistent problem where browser vendors are interpreting authoring guidance as having some impact on implementation, but that's a much larger issue, that we shouldn't tackle in a one-off fashion.

[domenic]

That said, perhaps once we have tests we could add them as an example in the spec; that feels like a good path to me.