Re: I18N-ISSUE-159: Extend output or create a new element for injected text [.prep-HTML5]

[copying Aharon's earlier message to this thread, so it's visible in the 
issue tracker]

-------- Original Message --------
Subject:  Re: More work on inline bidi article, and an issue to consider
Date:  Mon, 30 Apr 2012 16:20:17 +0300
From:  Aharon (Vladimir) Lanin <>
To:  Richard Ishida <>
CC: <>

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

I had objected to this being the (sole) vehicle for isolation and
auto-direction (

"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
to a more general solution) is probably a good idea."

Hixie accepted this objection

"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>
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

"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

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

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.


Received on Tuesday, 1 May 2012 14:37:10 UTC