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

On Wed, Mar 31, 2010 at 8:04 PM, Aharon (Vladimir) Lanin
<aharon@google.com> wrote:
>>> 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 agree wholeheartedly.  However, I think that we can do better here.  :-)

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

I understand the problems here, but specifying things this way will
lead to the same problem which is driving dir="auto" into the spec
(i.e., the dialog text coming from sources on which the web
application doesn't have control).

I definitely think that we should come up with an understandable way
of estimating the direction.  Once we have that, I think the web
authors can apply their knowledge for dir="auto" to this area and
override the UA's decision if they know the actual direction of the
text.

>>> 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.)

I'm not still sure why altdir would be necessary.  Would you mind elaborating?

Thanks!
--
Ehsan
<http://ehsanakhgari.org/>

Received on Friday, 2 April 2010 01:33:21 UTC