Re: More work on inline bidi article, and an issue to consider

First, some history on this issue.

During the course of the discussion with the HTML WG on the need for bidi
isolation in HTML, before <bdi> as an element for this purpose had been
accepted, it was Hixie (the HTML5 spec editor) who proposed using <output>
for both bidi isolation and auto direction (see
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10807#c13).

I had objected to this being the (sole) vehicle for isolation and
auto-direction (https://www.w3.org/Bugs/Public/show_bug.cgi?id=10807#c14):

"It is not correct to characterize all or even most content that needs
isolation (and/or auto-direction) as "user-provided" or as the "output of a
calculation" or in any way associated with forms (which the output element
seems to be)."

"I do not think that the output element is a good fit for most use
cases - although having isolation on for output element by default (in
addition
to a more general solution) is probably a good idea."

Hixie accepted this objection (
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10807#c17):

"Given the use cases of text that need isolation, I agree that
<output>'s semantic is inappropriate."

"In general, it seems like a <bdi> element is the way to go."

"However, I think it would also make sense to make sure that <output>
elements
are always isolated"

This is in fact the case today: <output>, like <bdi>, has
unicode-bidi:isolate by default. This is the case in the HTML5 spec, and is
actually implemented in both Firefox and WebKit (try data:text/html,<div
dir=rtl><output>output</output> 1</div><div dir=rtl><bdi>bdi</bdi>
1</div><div dir=rtl><span>span</span> 1</div>).

However, unlike <bdi>, <output> does not have auto-direction. This is
arguably due to my objection to giving it auto-direction (
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10807#c26):

"I am not sure I would want the extra expense of dir=auto by
default on output, though, which has lots of use cases where bidi can not
possibly be a concern."

In retrospect, this was probably not a very important objection, and I
would not stand in the way of <output>, like <bdi>, having dir="auto" by
default. I do think that Richard's suggestion would require this.

And if that were to happen, then the definition of dir="auto" itself would
have to be modified to include <output> in the list of elements (alongside
<bdi>) excluded from the dir="auto" estimation of an ancestor (
http://dev.w3.org/html5/spec/global-attributes.html#the-dir-attribute).

But this still leaves the principal objection that <output> is currently
documented as being "the result of a calculation", which covers only a
small part of the cases where isolation is needed. So, indeed, Richard's
synopsis is correct: we would have to "ask the HTML WG to either expand the
role of output so that it's not just for the result of calculations, or
create a new element (that is essentially an alternative to bdi)".

I am not particularly thrilled to broaden the purpose of <output>. The
"output" name is a good one for "the result of a calculation", but is not
very good for an element with semantics something like "inserted text
data". Nor are the form-related attributes specific to <output> at all
relevant to our use case.

So, my preference would be a new element. However, this would immediately
raise the question of whether <bdi> should be kept in the spec - or
completely replaced with the new element. In other words, should <bdi> be
renamed and re-branded? If it should not be renamed, we need a cogent
reason why we need two (or three, counting <output>) such elements. If it
should be renamed, we have the potential problem of <bdi> already being in
the public spec and even in at least one printed book...

Whether <output> is broadened or a new element created, I think there will
also be a problem with stating, reasonably clearly, the purpose of the
element without referring to bidi considerations as being the principal
defining characteristic. But if someone can think of a reasonable
description that has a chance of bidi-unaware people actually starting to
use it, that would be great.

Aharon

On Tue, Apr 24, 2012 at 8:03 PM, Richard Ishida <ishida@w3.org> wrote:

> I have added examples to the article for all use cases and a few more, at
> http://www.w3.org/**International/tutorials/new-**
> bidi-xhtml/Overview-inline.en.**php<http://www.w3.org/International/tutorials/new-bidi-xhtml/Overview-inline.en.php>(no change marks).
>
> As I worked through examples, the following thought kept banging against
> my head...
>
> bdi is fine and dandy for wrestling with your typical inline bidirectional
> text issues, but its use for injected text is a little strange, if you step
> back.
>
> Essentially we are telling developers all around the world that anywhere
> they insert text into their page they have to add some bidi-specific
> markup.  It's not semantically elegant, and it feels a little odd - and I
> guess most people will just not think about the possibility of bidi being
> an issue most of the time.
>
> I suspect that a better approach would be to have an element dedicated to
> marking the location of inserted text, and secretly endow that element with
> the properties we need for bidi support. As such it would be identical to
> using bdi, but it would seem more natural to non-bidi-aware developers.
>
> We already have an element that is close to this: output[1]. I'm thinking
> that we should ask the HTML WG to either expand the role of output so that
> it's not just for the result of calculations, or create a new element (that
> is essentially an alternative to bdi).
>
> What do people think?
>
> RI
>
>
> [1] http://dev.w3.org/html5/**markup/output.html<http://dev.w3.org/html5/markup/output.html>
> --
> Richard Ishida
> Internationalization Activity Lead
> W3C (World Wide Web Consortium)
>
> http://www.w3.org/**International/ <http://www.w3.org/International/>
> http://rishida.net/
>
>