W3C home > Mailing lists > Public > public-i18n-bidi@w3.org > January to March 2010

Re: bidi proposal

From: Ehsan Akhgari <ehsan@mozilla.com>
Date: Wed, 17 Mar 2010 18:16:59 -0400
Message-ID: <dbd3aaef1003171516y21ecccdbw6f403e2c59aa0dd6@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: "Aharon (Vladimir) Lanin" <aharon@google.com>, public-i18n-bidi@w3.org
On Wed, Mar 17, 2010 at 5:32 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
>> >  and for when there are DOM mutations involved.
>> The estimation only needs to be done when the browser decides to render
>> the page.
> The browser has to render the page live. If JavaScript is manipulating
> the DOM as the user interacts with the page, then the browser is
> deciding to render the page very frequently.

Also, the case of using dir=auto on editable elements where the
rendering might need to change based on user's input should be

>> - The syntax for the dir value is "ltr|rtl|auto[0-9]*" or some more
>> palatable version.
>> - All the auto values always use word-count - but stop after scanning
>> the first n strongly-directional words. Thus, by using a number, the
>> page author specifies how thorough a job the estimation should do.
>> - As a result, "auto1" is almost exactly identical to first-strong! The
>> exception is that "weak ltr" values, e.g. "(212) 123 4567", wind up
>> being treated as LTR, which is a good thing. Thus, we wind up exposing
>> first-strong as well as word-count.
>> - Plain "auto" is a synonym for either "auto1" or some likely
>> word-county value, e.g. "auto64" - TBD.
> That's an interesting approach. I'll take it back and ask the Mozilla
> folks what they think.
> My only comment atm is "define word". I think it would be much less
> ambiguous to count by character.

Seems good to me.

Received on Wednesday, 17 March 2010 22:18:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:24:37 UTC