This is as designed.
  1. You should not be using CSS to set bidi properties. Base directionality
     is a content property, not a stylistic one.
  2. The 'direction' property inherits and its computed value must be either
     'ltr' or 'rtl' in order for various layout calculations to be well-defined.

Note: In the future, please file issues against CSS by posting to www-style as requested in the status sections of the drafts.

Why did we add unicode-bidi: isolate, plaintext, etc... then?

(In reply to comment #2)
> Why did we add unicode-bidi: isolate, plaintext, etc... then?

To support the HTML spec's bidi features, because bidi reordering is defined at the CSS layer.

You should not be using CSS to set bidi properties.(In reply to comment #3)
> (In reply to comment #2)
> > Why did we add unicode-bidi: isolate, plaintext, etc... then?
> 
> To support the HTML spec's bidi features, because bidi reordering is defined at
> the CSS layer.

Like Ryosuke, i don't understand this. bidi reordering is defined at the CSS layer, but one should not be using CSS to set bidi properties. Some bidi features are accessible through CSS and some aren't.

I keep hearing the "CSS shouldn't be used for bidi" mantra, but i never heard a proper explanation for it. This bug report is probably a bad place to discuss it, but i couldn't find anything better.

(In reply to comment #3)
> (In reply to comment #2)
> > Why did we add unicode-bidi: isolate, plaintext, etc... then?
> 
> To support the HTML spec's bidi features, because bidi reordering is defined at
> the CSS layer.

But unicode-bidi: isolate and unicode-bidi: plaintext are as semantically important as dir=ltr or dir=rtl. Isn't that precisely why we have bdi? Why did we permit bdi to have a CSS equivalent but not dir=auto? What's the justification for that?

The fact that bidi can be controlled via CSS is a glitch in the way CSS was defined, and it's a result of people in the past wanting to apply bidi controls to arbitrary XML. They should have defined an xml:dir attribute instead.

CSS is for styling, not for defining content. A document should still be understandable if the CSS is turned off, if viewed in a browser that supports HTML but not CSS. By shifting bidi controls into the CSS layer, you lose ordering information that is critical for presenting the text, without which the text itself can be garbled inasmuch as as applying the wrong encoding.

Furthermore, bidi is based on the content, not on the styling intent. If you change the content, the directionality controls need to be updated to match. If you change the styling... the directionality controls need to stay the same. No matter how much you change the styling, the bidi controls always stay the same. But if you change the content, the bidi code might need to change. They are tied to, and therefore belong with, the content, not with the style.

Now, selectors are a very convenient way of tying properties to elements. But the scope of CSS is defined by the scope of styling, not by the scope of things-that-are-conveniently-applied-with-selectors. Otherwise we'd allow binding event handlers in CSS, which would also be conveniently applied with selectors. It might be convenient to bind bidi controls to elements via selectors. But it is not an argument for them belonging in CSS.

> But unicode-bidi: isolate and unicode-bidi: plaintext are as semantically
> important as dir=ltr or dir=rtl.

"unicode-bidi: isolate" does not confer semantics any more than "display: table" does. The semantics are conferred by HTML. The CSS values are only provided so that the HTML definitions can be reflected in the CSS rendering model. The features provided by 'unicode-bidi: isolate' and 'unicode-bidi: plaintext' are important, yes, but that's why the HTML spec has <bdi> and <pre dir=auto>.