At 2007.03.15-11:29(-0700), Mark Davis wrote:
I don't think that we are yet communicating completely.

The proposal is for some CSS option that causes the directionality of each paragraph of text within the block to depend on the contents of the text in that block. The main usage would be for text entry fields. For each paragraph, it would effectively have the same effect as direction:rtl if the first strong character was R or AL (as per the Unicode BIDI algorithm), and direction:ltr otherwise. However, it must be dynamic; as the user modifies the text in a text input field, the effective direction must change in response.


* A refinement of this would be RTL if the first strong character were R or AL, LTR if the first strong character were L, and otherwise inherit the direction.


I'm responding that I think that is exactly what the existing CSS properties do (with the possible exception of explicitly saying that this is an input field, dynamically re-analyze it if the data changes, though most CSS properties can be animated so most are dynamically applied).

  1.) All paragraphs in CSS should map to display="block", so each paragraph is
      its own block (these may or may not be nested in a parent block).
  2.) For all block-level elements, if no 'unicode-bidi' property is specified,
      it defaults to "normal". This effectively disables the setting of
      'direction', since the Unicode bidi rules are supposed to be applied.
       a.) 'direction' says it "specifies the base writing direction of all
           blocks and the direction of embeddings and overrides (see
           'unicode-bidi') -- what is unclear is whether this is intended to
           set the equivalent of Bidi.DIRECTION_???_TO_??? or
           Bidi.DIRECTION_DEFAULT_???_TO_??? for the bidi iterator's starting
             I have always assumed if unicode-bidi was "normal" this meant
           DIRECTION_DEFAULT_???_??? and if it was "bidi-override that this
           meant DIRECTION_???_???.

       b.) Since the 'unicode-bidi' property describes behaviors for blocks,
           I assume the description in 'direction' is modified by the setting
           of 'unicode-bidi' for both "the base direction for blocks" and
           the "embeddings and overrides".

I would agree the wording in the CSS spec could be clarified to make it absolutely clear that this was the intent.

On 3/15/07, Stephen Deach <> wrote:
At 2007.03.15-06:33(+0200), Simon Montagu wrote:
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.)


This would be resolved as an RTL paragraph and rendered:

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

I am describing what I interpret to be the current behavior.  'unicode-bidi'
    Value:   normal | embed | bidi-override | inherit
    Initial:   normal
    Applies to:   all elements, but see prose
    Inherited:   no
    Percentages:   N/A
    Media:   visual

CSS-2.0 & 2.1 state it applies to all elements (with restrictions noted in the prose).
The restriction is that the embed option applies only to inlines, but the wording explicitly states that the normal & override values apply to the block as a whole (or to inlines when specified on an inline), and goes on to detail specifically how.
It is my interpretation, that applying dir="rtl" and unicode-bidi="normal" (the default) or unicode-bidi="override" to to a block-level element should result in:    TAF TNECREP 3

So, what I'm saying is that you do not need a value of "auto" on the CSS direction property, unless you want to add the ability to force a directional re-evaluation on an inline in mid-paragraph (by inspecting the first character within the inline that has a strong direction). This is something that can't be done using the exiting Unicode directional-control characters today, you can force an explicit direction, but can't force the algorithm to "re-start".  (I can see some cases in forms design where such an option would be useful in CSS [there is a way to do it in XSL by using an fo:inline-container], when fill-in fields are not a separate paragraph. I would probably add it as a new value on unicode-bidi [and possibly a corresponding directionality marker to Unicode], rather than add "auto" to direction; direction is used to control table-layout and other layout stuff and really needs an explicit rtl or ltr value.)

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


On 3/14/07, *Richard Ishida* < <mailto:>> 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.


    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)



    On Behalf Of Mark Davis
            Sent: 11 March 2007 00:03
            To: Simon Montagu
            Cc: Jonathan Rosenne;
    <>; w3c-i18n-ig
            Subject: Re: Invalid relationship between bandwidth and
    spoken language

            that would be really good...

            On 3/10/07, Simon Montagu <
    <>> 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*
    < <>
                    > <mailto:>>    
<>> <>> >>
                    >     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
                    >     Jony
                    >         -----Original Message-----
                    >         *From:*
                    > <>> <>> <>>
    > [mailto:
                    > <>> <>> <>>
    >] *On Behalf Of
                    >         *Richard Ishida
                    >         *Sent:* Friday, March 09, 2007 4:11 PM
                    >         *To:* 'Rotan Hanrahan'
                    >         *Cc:*
    <> <>
                    >         *Subject:* RE: Invalid relationship
    between bandwidth and spoken
                    >         language
                    >         Fixed.
                    >         RI
                    >         ============
                    >         Richard Ishida
                    >         Internationalization Lead
                    >         W3C (World Wide Web Consortium)

                    >             *From:*
    < <mailto:>>

< >>
                    >             <mailto:
    <>> <>>
    >] *On Behalf Of
                    >             *Rotan Hanrahan
                    >             *Sent:* 09 March 2007 12:59
                    >             *To:*
    <> <mailto: <>> < >>
                    >             *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]
                    >         --
                    >         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


    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


---Steve Deach

---Steve Deach 

---Steve Deach


---Steve Deach