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

On Wed, Mar 24, 2010 at 5:47 AM, Aharon (Vladimir) Lanin
<aharon@google.com> wrote:
>> We discussed how we can support section 2.2 with David Baron,
>> Johnathan Kew and fantasai during the work week.  Fantasai had a nice idea
>> of a heuristic algorithm considering the first N words in a text node
>> (let's say N=63) and trying to find if there is an RTL word among
>> them.  This is very similar to the second estimation algorithm
>> proposed in that document, but I believe that it's going to be much
>> more accurate than the other two for real-world usages.  Perhaps this
>> algorithm could be mentioned in this draft?
>
> This is basically the any-rtl algorithm mentioned in the FPWD ("Does the
> string contain any RTL characters?"). Real-world scenarios it fails on are:
> - Informal LTR text with a little bit of RTL, e.g. "they had grapes and
> cheese (YUM!)"
> - Scholarly LTR text quoting words and phrases from RTL sources, e.g. "the
> word usually translated as neighbor (FELLOW) is unusual."

Not really.  The difference here is only checking a limited subset of
the text, for performance reasons.  But as far as false positives go,
that's right, it shares the same set of false positives.

> Scenarios where it is more reliable than word-count are few and far-between.

I think the real point behind this suggestion is its efficiency, not
its accuracy, which is not better than any-rtl.

>> The proposal in Section 2.3 is probably useful too.  Although I
>> think the spec should also specify what happens if there is an actual
>> element with name="[input/textarea-name]_dir".  It may be as simple as
>> the latest such element overrides the values submitted for previous
>> elements, but it's still something which should be declared in the
>> spec, so that we don't end up with different browsers choosing to
>> implement it differently.
>
> You are right, it should be specified. BTW, what happens if you have two
> inputs with the same name in the same form? It would be best if the two
> cases were treated the same way.

What happens in practice is the latter element takes precedence.  I
haven't checked the HTML5 spec to see how it's specified there though,
but I think this is a reasonable behavior.

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

That's right.  My viewpoint is, however, fixing the issue completely,
not merely improving the status quo.

>> Also,
>> what happens if the alert is being triggered from a LTR document which
>> is being included in an RTL document?
>
> According to the current proposal, its text will be assumed to be LTR, and I
> think that's fine.

It will be, but I don't think that it's what the author/user expects
in every case.

>>  Such iframed documents might
>> not always have a clear mapping to a visible element as far as the end
>> user is concerned.
>
> I don't understand. What relevance does any element have here?

I meant this as an elaboration over the previous point.

>> and provide a way in the DOM API to
>> override it (although the latter falls outside of the scope of this
>> document.)
>
> Do you mean an optional dir parameter to Javascript's alert(), confirm(),
> and prompt(), and recommend a similar change in all other script languages /
> APIs? I agree it would be best, but as you said, it is outside the scope of
> this proposal.

Yes, that's what I had in mind.  But this forum is not the proper
place to discuss that anyway.

>> 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 using the text's estimated direction, as opposed to the element
> direction, this would be a non-backwards-compatible change. I say this
> because currently there *is* browser consensus on how to treat tooltip text.
> (This is not the case for dialog text, which is why I am more open to the
> same suggestion in 3.4.) My preference would be not to break backwards
> compatibility.

It will break backwards compatibility, but (if I'm not mistaken) only
in cases where the current behavior is not the desired one.

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

With regard to the counterexample, you're right.  I'm not very eager
to add new attributes either, that was just the only solution which
came to my mind.

And with regard to alt values, an altdir attribute would not be
necessary since the alt text can take the direction of the img element
itself.

>> In fact I read this section several times, and it
>> seems paradoxical to me, because the proposed solution seems to fail
>> in the example given in the first paragraph.
>
> Although, as the document states, the counterexample is not a common one, I
> included it in order not to hide the problem, and to illustrate why I
> believe the spec should say something explicit on the subject.
>
> Under the proposal, the counterexample would be handled by putting the
> tooltip on an extra element wrapping the original one, i.e.:
>
> <span title="THE ADDRESS"><span dir="ltr">10 Downing Street</span></span>
>
> Yes, I know that this is not perfect. But in a tradeoff with lack of
> backward compatibility, I think it is the right thing to do.

I agree with you.  This seems to be a better solution.

>> The only thing that I would change about Section 3.8 is actually
>> recommending UAs to expose alternate ways of setting the direction
>> besides the keyboard shortcuts.  In practice, only a minority of users
>> know about the keyboard shortcuts, in my experience.
>
> Basically, I agree. The only method besides keyboard shortcuts of which I am
> aware, though, is via a right-click menu in Safari. It is not
> extraordinarily discoverable either, but it is better than keyboard
> shortcuts.

The same kind of user interface is also available on Windows for
native text entry widgets if an RTL keyboard layout is available on
the system.  I'm not sure what the best UI choice would be though, but
I'm sure that UI folks can come up with good ways of designing this
interface.  I don't think that the HTML spec should suggest a
particular UI choice.

> I guess it will be up to the HTML folks to decide whether the spec can make
> such a recommendation (as is the case for the recommendation the proposal
> already suggests - to support the method commonly used on a given OS, if
> any.)

The problem in my opinion is that some operating systems do not
provide any means for doing that.

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

Received on Friday, 2 April 2010 01:28:24 UTC