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

Whether to propose expanding output or defining a new element, we have to
try to formulate the exact description we would want for either the
expanded output or the new  element. It has to cover the cases where we
want people to use, but under no circumstances include cases where
isolation is inappropriate. I think that "text that is inserted at run
time" is rather unclear. After some thought (even before I read Richard's
deliberations re Javascript vs PHP), I decided that it must mean "text
inserted by a page script". This, IMO, does not meet either criterion. It
does not cover data inserted into a page on the server side (e.g. by PHP),
which I think is absolutely essential. And when we have a script that
inserts into some element a string like "Purple Pizza (39 Main Street)"
that it first generates from two pieces of data ("Purple Pizza" and "39
Main Street") and a localized format string (or message, something like "$1
($2)"), this description gives no clue that it is the two pieces of data
that each need to go into a separate <output> (or whatever). It is rather
easier to understand it to mean that the formatted string as a whole (which
is what the script actually inserts into thye page) that needs to be put
into a single <output>. This is *not* useful. In fact, with AJAX pages that
are built by script on the basis of data, this description can be taken to
mean that the most of the page needs to be put into a single <output>
element...

I do not have an alternative description ready. My initial guess would be
something in the direction of "an atomic piece of text data potentially in
a different language or script than the context in which it appears, e.g.
the name or description of some item, an address, a model id, etc."

BTW, if the world were all fresh and new and we were only proposing the
addition of a lang attribute now (without having to deal with backward
compatibility), it seems pretty clear to me that we would want any element
with the lang attribute to default the unicode-bidi CSS property to
"isolate" and the dir attribute to a value determined from the language
code, with some special lang value like "?" or "unknown" signifying that
the language of the text in the element is unknown, and defaulting dir to
auto. (This is not a new idea and does not belong to me. It keeps getting
proposed.) The advantages of using lang are easy to explain to users (not
that it means that people would rush out to use it) and are not
bidi-specific. Now, none of this is about to happen now, when we do have
backward compatibility to worry about. But it does raise the question of
whether defining an element that represents "an atomic piece of text data
potentially in a different language or script than the context in which it
appears" is really the right thing to do.

Aharon

On Tue, May 1, 2012 at 6:18 PM, Richard Ishida <ishida@w3.org> wrote:

>  Date: Mon, 30 Apr 2012 16:20:17 +0300
>> From: Aharon (Vladimir) Lanin <aharon@google.com>
>>
>>  ...
>
>
>  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.
>>
>>
>
> I don't think it's a good idea to replace bdi now for two reasons:
>
> 1. it is already being implemented and explained to people (as you
> mentioned)
>
> 2. bdi is still needed for use cases involving non-injected text - ie.
> where you know the direction of the text but want to manage the
> bidirectionality. In these cases, the use of an element called output or
> <injected-text> (or whatever) is not really appropriate there.
>
> I was thinking along the lines of: "The output element represents the
> result of a calculation or other text that is inserted at run time into the
> web page."
>
> I agree that the rationale for using the element needs to stand alone,
> although we should mention in a note or separate paragraph that it has
> significant benefits if the page is likely to contain or be translated into
> a language that uses a right-to-left script.
>
> In some ways I could see it making sense to people to use an output
> element as a placeholder for text that is inserted by JavaScript (such as a
> table of contents). It may be harder to make the case for text that is
> inserted using PHP.  Having said that, if they don't use the element they
> need to use bdi, and I suspect that that is harder for people to grasp.
>
> I suspect that it may be easier to convince people to use output than to
> use a completely new element which is only useful for injected text.
>
> RI
>
>