[Bug 23260] Make the dir attribute use isolation instead of embedding

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23260

--- Comment #4 from Aharon Lanin <aharon.lists.lanin@gmail.com> ---
> What problem is it solving?

If you ask someone who uses the dir attribute what it does, they will answer
(correctly) that it sets the direction of the stuff inside the element. What
not one in a hundred will realize is that, as currently specified, it also
affects the ordering of the content outside as would a strong character of that
direction. Most of the time, this does not have a visible effect. But not
infrequently, it has a disastrous effect. For example, in an LTR page,

<a dir="rtl">HEBREW ARTICLE NAME</a> - 27 september 2013

is displayed unreadably:

27 - EMAN ELCITRA WERBEH september 2013

No one expects it, but it happens.

This is why a couple of years ago we asked for directionality isolation
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=10807). And we got it - as the
<bdi> element. The idea was that when you want it, you use it. Thus,

<a><bdi dir="rtl">HEBREW ARTICLE NAME</bdi></a> - 27 september 2013

displays as expected:

EMAN ELCITRA WERBEH - 27 september 2013

Now, the problem, as fully explained in
http://www.w3.org/International/wiki/Html-bidi-isolation:

Non-isolation is almost never intended and usually only causes problems. As
Unicode admitted, isolation should have been the way that embedding was defined
when UAX#9 first came out all those years ago. LRE and RLE are deprecated in
favor of LRI and RLI. Thus, in HTML, isolation should be the default.

<bdi> can not continue to be the only or even the primary way to achieve
isolation in markup, since it relegates isolation to being a little-known power
tool instead of the default for bidi content, and since using a special element
for this purpose is impractical in some scenarios.

- As long as isolates are more difficult to set up than embeddings, embeddings
will be the default, and isolates the exception; the use of isolates will not
replace the use of embeddings.

- A single attribute has historically been and should continue to be sufficient
to do all the bidi in HTML. Why should the preferred way to embed
opposite-direction content inline now require the use of both a special-purpose
element (<bdi>) and a special attribute (dir)?

- HTML document authors must be instructed that when a “block” element like <p>
gets opposite-direction content, they should indicate it by putting a dir
attribute on that element. For “inline” elements, however, it depends. An
element like <textarea> or <input> or <option> whose content is inherently
“out-of-flow” and thus directionally isolated can also get the dir attribute
directly on it. However, when an “ordinary” “inline” element like <cite> gets
opposite-direction content, they should not just put the dir attribute directly
on it, but on a special <bdi> element especially inserted for that purpose
either within the <cite> or around it. (Which, by the way?) The distinctions
are impossible to justify or explain!

- When an HTML or XHTML document tags a data item with microformatting or some
other form of data export, it makes good sense to also indicate the data item’s
direction using an attribute on the tagged element, so that consumers of the
data will know how to display it properly. It makes little sense to put it on a
surrounding element, where consumers of the data will ignore it (unless they
bother to ask for the tagged element’s computed direction style) or on an
element especially introduced within the tagged element for the purpose of
carrying the attribute, suddenly turning what had been a nice plain-text data
item into HTML. If the attribute goes on the tagged element, and it happens to
be inline, we want it to be isolated, so now the tagged element suddenly has to
be <bdi>. Do we need to update the RFCs on microformatting to require the use
of <bdi> for all microformatting (except where a “block” element is used)?

In brief, we must make it possible to set up bidi isolates by using the dir
attribute alone.

> Can't we leave it for a few years?

No.

> What's the back-compat impact?

Overall, good, for two reasons:

- We believe it will fix more problems in existing pages than it will create.

- There is no browser interoperability in this respect anyway because IE8-10
does not follow the current spec. It displays an inline element with a dir
attribute as if that element were followed by an LRM or an RLM, whichever fits
the directionality of the parent. Thus, the example above is displayed as
intended - and as it would display if dir were defined as isolating.

> Why are we changing this stuff _again_?

Actually, we aren't changing *this* stuff again. The effect of the basic dir
attribute was not changed in the last go-around. We added a new value, auto,
which is great and which the current proposal is not touching in any way. And
we added the <bdi> element, which we are now not asking to change in any way
either - it remains handy in some situations. In hindsight, we should have
asked for this in the last go-around. We didn't because we were afraid of
backward compatibility issues, and because we were not aware that IE had
silently changed the semantics of dir to something that usually has the same
effect as isolation. I guess they had more chutzpah than we did - and should
have had.

> There's so much churn in this part of the spec that I'd be surprised if any
> browser vendor even looked at the spec any more.

They do. Mozilla and WebKit and Blink implemented dir=auto and <bdi>. IE hasn't
yet, whcih I very much hope will no longer be the case in IE11 (anyone
listening? :-), but as evidenced by what they changed in IE8, it seems that
they weren't looking at this part of the spec anyway.

> Are browsers planning on changing to this?

I don't know about IE - I don't have any contacts there. I have every reason
that Mozilla will change this if the spec changes; I have discussed this with
Fatasai and Simon. I believe I can also vouch for Blink (once the spec
changes). I have not discussed this with anyone at WebKit, but I have no reason
to think that they won't change it. But the best thing would be if the various
representatives responded on this bug.

> If we assume that the default stylesheet part trumps the definition in the
> 'dir' attribute section, then Aharon's tweak in comment #1 doesn't change
> anything.

It does trump it, the change would be mandatory, browsers would not have
leeway, and the tweak doesn't change anything. It just makes things clearer in
the part of the spec that humans read.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 18 September 2013 14:38:23 UTC