Re: [html-bidi] Feedback on Additional Requirements for Bidi in HTML

I gave a bit more thought to a couple of the items.

>> Section 3.4 is also a real-world problem, but I think the solution
>> proposed is really bad.  It's in fact as bad as the current practical
>> workaround which web authors would need to do (wrapping paragraphs
>> with bidi control chars); in fact it only changes when that workaround
>> is necessary (from when the displayed text is RTL to when the
>> displayed text is in the reverse direction of the document.)

> I believe that the vast majority of dialog texts are in the language (and
> thus the direction) of the document, so I think that this is still a
> substantial improvement.

I missed another important way that the proposed solution is an improvement
over the status quo. The statement that currently workarounds are necessary
"when the displayed text is RTL" is not really true (not even for non-IE
browsers). If the browser chrome and the OS are both RTL, I believe that
Firefox and Chrome will display dialog text as RTL. It is the LTR dialog
text that will be garbled and thus will need a workaround. And the worst
part is that the page has no way to determine which way the dialog text will
be displayed, either on the server nor on the client side, so it does not
really know when it needs to employ a workaround and when it shouldn't.

The deterministic (and easily determined) default direction provided by the
proposal is in itself an important advantage.

>> I think a much better solution would be to change the default behavior
>> to something similar to the dir=auto proposal (with a heuristic
>> similar to fantasai's suggestion),

> Leaving the specific estimation algorithm out of it, I think your
> suggestion does have merit. The counter-argument, of course, is that
> estimation is not foolproof, and most dialogs should be in the language
> of the page. I am not sure which way I like better. Let's see what others
> have to say.

After further consideration along the same lines as above, my inclination is
against direction estimation for dialog text, because it once again makes
the default direction something that the page can not easily determine (thus
making it very difficult to know whether a workaround is necessary). And a
workaround will sometimes be necessary, since estimation is not perfect.

>> Section 3.6 presents a bad solution IMO.  Like Section 3.4, I think
>> the default behavior should be similar to dir=auto with an optional
>> method for overriding it (like a titledir attribute, which would
>> default to "auto").

> Re titledir, I am not overly eager to add an attribute where it is not
> absolutely necessary, especially for such an out-of-the-way corner as
> this. And as the handling of the counterexample below shows, it is not
> absolutely necessary. Also, would titledir apply to the alt value? Or do
> we need an altdir too? It's messy.

After further consideration, I no longer think that titledir would be all
that terrible. We would also want altdir for alt - if one can be added then
so can two. So, if the HTML folks have no problem adding titledir and
altdir, they would be nice to have. (I still want the default to be the
element's direction, though.)

Aharon