Re: Comments on "Additional Requirements for Bidi in HTML"

> I was very pleased with the suggested changes

Thanks, that's great!

> The idea is basically to exclude a section from being used to for
determining the base direction.

I guess this is for dir=auto, and at one time I was going to suggest
something like this, since I very much sympathize with the use case (and
others like it). But then I realized that there is a serious problem, and
that once one deals with it, the new feature is no longer necessary. The
problem is that if one leaves the direction of the part to be ignored for
the estimation (e.g. the chat user name in your use case) unspecified, it
will take on the direction of the dir=auto ancestor, which may not be
appropriate. For example, if the chat user name is "aharon (VLADIMIR)
lanin", and the chat message is "HELLO", giving the overall line RTL
direction, it will come out as:

OLLEH :lanin (RIMIDALV) aharon

when what one wants is:

OLLEH :aharon (RIMIDALV) lanin

To deal with the problem, one simply puts a separate dir on the char user
name, e.g.:

<div dir="auto"><span dir="auto">aharon (VLADIMIR) lanin</span>: HELLO</div>

And then not only is the user name displayed correctly, but it is excluded
from the estimation algorithm by the already-specified rules, quote:

The content to be examined by a direction estimation algorithm is all
descendant text nodes, visited in "in-fix" order, *except for those under a
descendant element with a unicode-bidi style other than "normal", e.g. a
<bdo> element or an element with a dir attribute (whatever the value)*.

> Another issue that is not dealt with, which is probably ok,
> is how the underlying system allows bidi interaction.
> Are selections logical or visual? How is the cursor moved?
> How do you enter a new embedding level? How does the
> cursor change according to language?
> The advantage of having this specified in HTML spec would
> be better consistancy. On the other hand, this is already
> too far removed from the concept of a "markup language"?

I do not think that the current state of the art in all of these issues has
reached anything approaching perfection. In other words, I think that
creativity in devising new approaches to bidi editing should be encouraged.
Thus, even if these issues were in the proper purview of HTML, I would not
want want to canonize any of the current approaches. And I agree with you
that this stuff is too far removed from what HTML should be specifying.

Aharon

On Wed, Mar 31, 2010 at 4:36 PM, Dov Grobgeld <dov.grobgeld@gmail.com>wrote:

> I have today with interest read the article Additional Requirements for
> Bidi in HTML, and I was very pleased with the suggested changes.
>
> Here is an suplemantary idea that I did not see mentioned:
>
> The idea is basically to exclude a section from being used to for
> determining the base direction. E.g.:
>
> MOSHE: yes
>
> which in a conversation should be rendered:
>
> EHSOM: yes
>
> But:
>
> MOSHE: KN
>
> should be rendered:
>
> NK :MOSHE
>
> This can be achieved by wrapping "MOSHE:" in a tag that indicate that it's
> context is not to be used for either of the two mentioned auto bidi
> determination algorithms. The syntax for this tag needs to be determined of
> course.
>
> The spec also suggests something that Amit Aronovitch has been saying for
> years, and to which I have been hesitant but am now convinced, namely that
> gtk should have a way for the user to explicitely set the text entry
> basedirection. Perhaps I'll implement this if I get too much free time on my
> hands in the near future. There are some remarks in the text that are
> applicable for such an implementation, like the fact that the implementation
> should be using the typical system interaction for such a change.
>
> Another issue that is not dealt with, which is probably ok, is how the
> underlying system allows bidi interaction. Are selections logical or visual?
> How is the cursor moved? How do you enter a new embedding level? How does
> the cursor change according to language.  The advantage of having this
> specified in HTML spec would be better consistancy. On the other hand, this
> is already too far removed from the concept of a "markup language"?
>
> Regards,
> Dov
>