This idea came to me while editing Wikipedia, which is a massively multilingual site.
An element that has an explicitly defined lang attribute can also have different directionality from the enclosing element. Even more so for any element that has an explicit dir attribute. It is also likely that an element with a different directionality should be bidi-isolated using <bdi> or "unicode-bidi: isolate".
Therefore, bidi isolation should be the default for such elements. Of course, it should be possible to override it if that's what the user wants.
IMO, this is the correct approach for new pages. (In fact, I would even say unicode-bidi:isolate for elements with the dir attribute, and unicode-bidi:plaintext for elements with the lang attribute but lacking dir.) And in fact it is easy to do that in your (new) page's own CSS. However, one has to keep in mind that isolation is not implemented in IE9, and may or may not be implemented in the final release of IE10. So, if you need to have your page work bidi-wise for a high percentage of users, this just isn't good enough, not for a long while yet. :-(
The other major concern here is backward compatibility. That is why I said above "new" pages. Applying bidi isolation to all elements with the dir attribute *will* break some existing pages.
On the other hand, my guess is that applying bidi isolation to something with the lang attribute (and lacking a dir attribute) is unlikely to break existing pages, so it is probably a good idea.
Mass move to "HTML WG"
Recently I investigated the effects of the dir attribute in IE, and discovered some significant new information (at least it was new to me) that affects the conclusions I reached as described in comment 1.
It is true that no existing version of IE, including IE10, implements isolation (i.e. unicode-bidi:isolate). However, it turns out that IE8 and up, unless it is in IE7 compatibility or quirks mode, has modified the behavior of unicode-bidi:embed that is non-standard and not interoperable with other browsers, and in most cases acts similar to isolation.
This behavior appears to be that an inline element bearing the dir attribute affects the visual ordering of its surroundings as if it were immediately preceded by an invisible character of the element's directionality, but immediately followed by an invisible character of the parent element's directionality. Thus,
<div dir="ltr">א ==> <span dir="rtl">*</span></div>
is displayed as
* <== א
which is as specified and the same as FF, WebKit, and IE7 and below, but
<div dir="ltr"><span dir="rtl">*</span> ==> ב</div>
<div dir="ltr"><span dir="rtl">*</span> ==> 123</div>
is displayed as
* ==> ב
* ==> 123
which is the opposite ordering from IE7, the spec, and from all other major browsers.
This unusual approach cannot be said to approximate the standard embedding semantics. While it certainly is not isolation either, its effects are actually the same as isolation when both of the following conditions are satisfied:
- The dir attribute value assigned to the inline element is the opposite of its parent element's directionality.
- If the first strong character preceding an inline element with a dir attribute has the same directionality as that element, it too is inside an inline element with a dir attribute.
These conditions are actually more commonly satisfied than not, because:
- It is usually redundant to put a dir attribute on an element if its parent already has that directionality.
- If a software application creating a web page bothers to declare the directionality of one piece of opposite-direction text that it needs to display inline, it is likely to do the same for another.
Thus, once could say that under the most common circumstances, the behavior of IE8 and up (when acting as IE8 and up) is closer to isolation than to embedding. But even if that seems like a stretch, it is quite safe to say that currently there is a lack of interoperability in the behavior of the dir attribute between the current versions of IE and of the other major browsers (which continue to follow the current HTML specification and give the dir attribute embedding semantics).
FWIW, one thing to consider here is how implementors perceive this part of the spec. If we keep changing it, they'll start to think of it as unstable and not worth their attention, and it'll slow down the rate at which existing features are implemented.
Also, we should be really careful to avoid "magic", especially with something as complicated as bidi. We've done that pretty well so far by having things happen when explicitly invoked, e.g. with <bdo>, <bdi>, and dir="". We're moving a little away from this with things like dir=auto. I would advise caution when it comes to making elements have "magical", or "do what I mean", behaviour when using apparently unrelated attributes like lang="".
So, let's separate the two proposals. This bug can remain the home of the lang proposal. I have filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=22326 to proceed with using isolation for the dir attribute.
Please note that the IE8+ behavior described above for <span dir="ltr|rtl"> also applies for <bdo dir="ltr|rtl">.
Aharon — those bugs are on the HTMLWG spec. Let me know if you'd like me to clone them into WHATWG bugs as well so that they end up on my pile of things to look at.
(In reply to comment #7)
It sounds good, but I don't really understand the implications of cloning. Robin had counseled us to file on the HTMLWG spec, and he would clone as necessary. I obviously want both the HTMLWG and WHATWG specs to change in this regard.
(In reply to comment #8)
> (In reply to comment #7)
> It sounds good, but I don't really understand the implications of cloning.
> Robin had counseled us to file on the HTMLWG spec, and he would clone as
> necessary. I obviously want both the HTMLWG and WHATWG specs to change in
> this regard.
Sorry if I was unclear, that's not what I meant. I meant to indicate that you should clone as you feel is needed, and that others (myself included) could do it for you if they felt it necessary — not that I'd handle it in all cases.
Ideally, I'd prefer to have just one bug list for every one and on occasion split some bugs when there's disagreement. For most parts it would be a lot simpler. But I guess that ship has sailed.
Ok, let's please clone https://www.w3.org/Bugs/Public/show_bug.cgi?id=22326 to WHATWG. I am not sure how to do that.
(Off topic) (In reply to Robin Berjon from comment #9)
> Ideally, I'd prefer to have just one bug list for every one and on occasion
> split some bugs when there's disagreement. For most parts it would be a lot
> simpler. But I guess that ship has sailed.
I'm happy to do that if we can avoid the problems that led to the forking in the first place -- feel free to mail me about it or catch me on IRC to discuss it.
Ping? This is gating approval of the HTML5 overview of testing in view of permissive CR exit criteria:
AFAICT this bug was tagged as CR blocking (when Robin did that first-pass audit of HTML5 bugs during the San Jose F2F in April), but its dir="" counterpart  (the one which would fulfill the i18n WG proposal) was not.
Changing the default bidi behavior for elements with lang="" specifically *in time for the HTML5.0 CR spec* doesn't seem to be an explicit ask coming from the bug filer or the i18n WG. If this is indeed the case, it seems to me like this bug should instead be considered alongside the larger issue (with greater potential back-compat impact) of changing the bidi default for dir="" during the HTML5.1 timeframe, and the CR keyword be removed.
Unless I hear reasons otherwise in the next couple days, I will be removing the CR keyword.
Removing CR keyword per confirmation from i18n WG that they are not requesting this to be marked such: http://lists.w3.org/Archives/Public/public-html-admin/2013Oct/0015.html
The related bug 22326 (for dir) however, should (and will) be marked with the CR keyword.