Stephen Deach wrote:
>
> [Whoops, hit reply vs reply-all; resending to the list]
>
> At 2007.03.14-20:23(+0200), you wrote:
>> Stephen Deach wrote:
>>> I thought that the CSS property setting of unicode-bidi="normal" had
>>> the effect of saying that the normal Unicode bidi rules were applied
>>> to text, and that the direction property text was effectively ignored
>>> (or treated as if it were what is being suggested as "auto").
>>> To force a text direction in CSS, you must set direction and set the
>>> unicode-bidi property to "embed" or "override".
>>
>> This is partly true for inline elements, but not for block elements,
>> which is where the "auto" value would be most useful. Even for inline
>> elements with "unicode-bidi: normal", the direction is not determined
>> by the first strongly directional character (as in the proposed
>> "auto") but by the Bidi algorithm as applied to the paragraph as a
>> whole. Example:
>>
>> <p style="direction: auto">3 PERCENT FAT</p>
>
> (I assume you are using the notational convention that ALLCAPS is RTL
> and lowercase/Mixed-case is ltr.)
Yes
>> This would be resolved as an RTL paragraph and rendered:
>>
>> TAF TNECREP 3
>
> But so would: <p style="direction:ltr; unidode-bidi:normal">3 PERCENT
> FAT</p>
> As would: <p style="direction:rtl; unidode-bidi:normal">3 PERCENT
> FAT</p>
>
> To force this to be interpreted as totally RTL, you would need to force
> the direction by setting the direction property to "RTL" and the
> unicode-bidi property to "override" or "embed".
I'm not clear what you are saying here. Are you describing the current
behaviour or making an alternative proposal? As I understand the CSS
spec, "unicode-bidi: normal" currently has no effect on block elements,
so <p style="direction:ltr; unicode-bidi:normal">3 PERCENT FAT</p> will
be rendered
3 TAF CNETREP
>
>> <p>The label said <span style="unicode-bidi: normal">3 PERCENT
>> FAT</span>.</p>
>>
>> Because the numeral follows LTR text, this would be rendered:
>>
>> The label said 3 TAF TNECREP.
>
> Yes, but how would "auto" differ in this case, since "auto" would say to
> evaluate it using the Unicode bidi algorithm, which says to apply the
> directionality rules to the whole paragraph; is shouldn't restart the
> evaluation for the span. (If that is not what you wish, I would suggest
> you find a better value name than "auto". For almost all CSS properties
> "auto" simply means "use the preferred behavior", this would clearly
> mean "do something different from the preferred behavior".)
I think the usage of "auto" is comparable to that for properties
connected to the size of replaced elements, where "auto" means "use the
intrinsic size of the element", but I'm not wedded to it. "contextual"
or "implicit" would be possible alternatives.
>
> How would one force your desired behavior using the Unicode
> directionality markers?
The best one could do would be to enclose the text in <RLE>...<PDF>, but
as far as I know there is no way to capture all of the desired behaviour
using Unicode directional markers. To recap, in the case that Mark
describes below of entering a RTL search term in an input field at a LTR
search engine, the ideal desired behaviour would be that when the user
begins to type RTL characters, the text would be aligned to the right
and ordered RTL. With <RLE>...<PDF> there would be no right-alignment,
and trailing whitespace would still be to the right of entered text. The
last is not a minor consideration when entering text: spaces between
words are "trailing whitespace" until the next word is entered, and the
net effect is that the inter-word spaces and the text caret jump about
from one end of the line to the other, which is distracting for the user
>
>
>
>>> At 2007.03.14-09:08(-0700), Mark Davis wrote:
>>>> The key issue is when users are keying in text in a text entry box.
>>>> It is quite common with websites in a RTL language for people to be
>>>> entering in basically LTR text; and also not uncommon for those
>>>> users to make use of LTR websites (like google.com
>>>> <http://google.com>), and enter in RTL text, say to search for. If
>>>> the text entry box is in the "wrong" direction for the text, it is
>>>> very hard to read and edit. By having an "auto" option that uses the
>>>> Unicode BIDI algorithm's default for setting the text direction
>>>> (keying off the first strong direction character of each paragraph),
>>>> it makes it much easier for users to read and edit the text that
>>>> they are typing in.
>>>>
>>>> Mark
>>>>
>>>> On 3/14/07, *Richard Ishida* <ishida@w3.org <mailto:ishida@w3.org>>
>>>> wrote:
>>>>
>>>> Mark, Simon,
>>>>
>>>> Could you put a few more words around this, explaining why it is
>>>> needed and how you think it could be addressed? Then we can
>>>> discuss the proposal in the i18n core WG and, if agreed, forward
>>>> to CSS and any other WGs for consideration.
>>>>
>>>> Cheers,
>>>> RI
>>>>
>>>> PS: Note that w3c-i18n-ig@w3 is no longer in use. If you are in
>>>> the Core WG, you can use public-i18n-core@w3.
>>>>
>>>> ============
>>>> Richard Ishida
>>>> Internationalization Lead
>>>> W3C (World Wide Web Consortium)
>>>>
>>>> http://www.w3.org/People/Ishida/
>>>> http://www.w3.org/International/
>>>> http://people.w3.org/rishida/blog/
>>>> <http://people.w3.org/rishida/blog/>
>>>> http://www.flickr.com/photos/ishida/
>>>>
>>>>
>>>>
>>>>
>>>> ________________________________
>>>>
>>>> From: www-international-request@w3.org
>>>>
>>>> <mailto:www-international-request@w3.org>[mailto:www-international-request@w3.org]
>>>>
>>>> On Behalf Of Mark Davis
>>>> Sent: 11 March 2007 00:03
>>>> To: Simon Montagu
>>>> Cc: Jonathan Rosenne; www-international@w3.org
>>>> <mailto:www-international@w3.org>; w3c-i18n-ig
>>>> Subject: Re: Invalid relationship between bandwidth and
>>>> spoken language
>>>>
>>>>
>>>> that would be really good...
>>>>
>>>>
>>>> On 3/10/07, Simon Montagu <smontagu@smontagu.org
>>>> <mailto:smontagu@smontagu.org>> wrote:
>>>>
>>>> I proposed some time ago adding a value "auto" to
>>>> the css "direction"
>>>> property to achieve this result.
>>>>
>>>> Mark Davis wrote:
>>>> > Side issue: Interestingly, we've found that the
>>>> ltr/rtl options are
>>>> > insufficient. What people want in many cases in
>>>> input fields is the
>>>> > "default" algorithm, whereby even on a generally
>>>> rtl page, the field
>>>> > becomes ltr if the first strong character is
>>>> ltr. Right now we are
>>>> > simulating that with JavaScript (but it is a
>>>> pain to do so).
>>>> >
>>>> > Mark
>>>> >
>>>> > On 3/9/07, *Jonathan Rosenne*
>>>> <rosennej@qsm.co.il <mailto:rosennej@qsm.co.il>
>>>> > <mailto: rosennej@qsm.co.il>>
>>>> <mailto:rosennej@qsm.co.il>>
>>>> <mailto:%20rosennej@qsm.co.il%20%3Cmailto:rosennej@qsm.co.il>> >>
>>>> wrote:
>>>> >
>>>> > This was a strange remark. For Arabic or
>>>> Hebrew texts, little if any
>>>> > bidi markup is needed. dir="rtl" on the HTML
>>>> will do the work. As
>>>> > the referenced article says, it is only
>>>> needed for mixed content.
>>>> > And then there is no difference between LTR
>>>> text contained in an RTL
>>>> > document and RTL text contained in an LTR
>>>> document.
>>>> >
>>>> > Jony
>>>> >
>>>> > -----Original Message-----
>>>> > *From:* www-international-request@w3.org
>>>> <mailto:www-international-request@w3.org>
>>>> > <mailto:www-international-request@w3.org>>
>>>> <mailto:www-international-request@w3.org>>
>>>> <mailto:www-international-request@w3.org%20%3Cmailto:www-international-request@w3.org>>
>>>>
>>>> > [mailto:
>>>> > www-international-request@w3.org
>>>> <mailto:www-international-request@w3.org>
>>>> > <mailto:www-international-request@w3.org>>
>>>> <mailto:www-international-request@w3.org>>
>>>> <mailto:www-international-request@w3.org%20%3Cmailto:www-international-request@w3.org>>
>>>>
>>>> >] *On Behalf Of
>>>> > *Richard Ishida
>>>> > *Sent:* Friday, March 09, 2007 4:11 PM
>>>> > *To:* 'Rotan Hanrahan'
>>>> > *Cc:* www-international@w3.org
>>>> <mailto:www-international@w3.org> <mailto:www-international@w3.org>
>>>> > *Subject:* RE: Invalid relationship
>>>> between bandwidth and spoken
>>>> > language
>>>> >
>>>> > Fixed.
>>>> >
>>>> > RI
>>>> >
>>>> > ============
>>>> > Richard Ishida
>>>> > Internationalization Lead
>>>> > W3C (World Wide Web Consortium)
>>>> >
>>>> > http://www.w3.org/People/Ishida/
>>>> > http://www.w3.org/International/
>>>> > http://people.w3.org/rishida/blog/
>>>> > http://www.flickr.com/photos/ishida/
>>>> >
>>>> >
>>>> >
>>>> >
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> > *From:*
>>>> www-international-request@w3.org
>>>> <mailto:www-international-request@w3.org>
>>>> >
>>>> <mailto:www-international-request@w3.org <mailto:>>
>>>> www-international-request@w3.org
>>>>
>>>> <mailto:www-international-request@w3.org%20%3Cmailto:%20www-international-request@w3.org>>
>>>>
>>>> >
>>>> >
>>>> [mailto:www-international-request@w3.org
>>>> <mailto:www-international-request@w3.org>
>>>> > <mailto:
>>>> www-international-request@w3.org
>>>> <mailto:www-international-request@w3.org>>
>>>> <mailto:%20www-international-request@w3.org%20%3Cmailto:www-international-request@w3.org>>
>>>>
>>>> >] *On Behalf Of
>>>> > *Rotan Hanrahan
>>>> > *Sent:* 09 March 2007 12:59
>>>> > *To:* www-international@w3.org
>>>> <mailto:www-international@w3.org> <mailto:
>>>> www-international@w3.org <mailto:www-international@w3.org>>
>>>> <mailto:%20www-international@w3.org%20%3Cmailto:www-international@w3.org>>
>>>>
>>>> >
>>>> > *Subject:* Invalid relationship
>>>> between bandwidth and spoken
>>>> > language
>>>> >
>>>> > A colleague of mine, working in an
>>>> Arabic speaking region of
>>>> > the world has pointed out a comment
>>>> [1] regarding the use of
>>>> > bidi markup, in which it is stated:
>>>> >
>>>> > "Removing them will significantly
>>>> simplify the document, and
>>>> > reduce bandwidth - which may be an
>>>> important consideration
>>>> > in countries where Arabic is spoken."
>>>> >
>>>> > This line seems to suggest that
>>>> there is an association
>>>> > between lack of adequate network
>>>> bandwidth and the speaking
>>>> > of Arabic, an implication I am sure
>>>> was not intended.
>>>> > Firstly, the effect of bidi markup
>>>> on bandwidth consumption
>>>> > is negligible compared to the
>>>> accompanying graphics.
>>>> > Secondly, any saving on payload size
>>>> should be seen as
>>>> > universally beneficial, not just for
>>>> countries characterised
>>>> > by the language they speak.
>>>> >
>>>> > I suggest that the closing part of
>>>> that statement ("in
>>>> > countries where Arabic is spoken")
>>>> be removed from future
>>>> > revisions, as it is unnecessary and
>>>> open to misinterpretation.
>>>> >
>>>> > ---Rotan.
>>>> >
>>>> > [1]
>>>> >
>>>> _http://www.w3.org/International/geo/html-tech/tech-
>>>> bidi.html#ri20030726.132037950_
>>>> >
>>>> >
>>>> > --
>>>> > No virus found in this outgoing message.
>>>> > Checked by AVG Free Edition.
>>>> > Version: 7.5.446 / Virus Database:
>>>> 268.18.8 /714 - Release Date:
>>>> > 08/03/2007 10:58
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Mark
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Mark
>>>>
>>>>
>>>> --
>>>> No virus found in this outgoing message.
>>>> Checked by AVG Free Edition.
>>>> Version: 7.5.446 / Virus Database: 268.18.11/721 - Release Date:
>>>> 13/03/2007 16:51
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Mark
>>>
>>> ---Steve Deach
>>> sdeach@adobe.com
>>
>>
>> ---Steve Deach
>> sdeach@adobe.com
>
>