RE: comments on chapter 2 (bidi) in CSS Writing Modes

 
Hi, Mati, all.  
(I "+ 1"ed to most of Mati's comments.)
 
> Below are comments to the bidi chapter of "CSS Writing Modes Module Level 
> 3" (http://www.w3.org/TR/2011/WD-css3-writing-modes-20110201/#text-direction) that I propose > to send to the mailing list dealing with this document. 

> 1) In section 2, the example should use upper case for RTL and lower case for Latin. 
>      Rationale: this is the convention used in Unicode documents like UAX#9. This is also the
> convention used in the example in section 2.3. 
> In the same example, the pseudo-bidi words seem meaningless. I suggest to use English words 
> written backwards, like "SDROW EMOS ERA EREH". 
{ COMMENT:  I don't object to the sequency, "man ba (W3C) kar mikonam,"
albeit written rtl; however I agree that the convention is to have the rtl text upper-case and the ltr lower-case and it should be adhered to here for consistency, so perhaps -- }
=>.MANOKIM RAK w3c AB NAM
{ Or go ahead and change this to rtl English as Mati suggests if you like.}
 
> 2) Section 2, "User agents that support bidirectional text must apply the Unicode bidirectional 
> algorithm to every sequence of inline boxes uninterrupted by a forced (bidi class B) line break or
> block boundary." 
> should be "User agents that support bidirectional text must apply the Unicode bidirectional 
> algorithm to every sequence of inline boxes uninterrupted by a forced (bidi class B) paragraph
> break or block boundary." 
>     Rationale: the status of line breaks, in particular the <br> tag, re bidi isolation is blurry. > Paragraphs are unequivocal bidi isolators.
{ COMMENT:  Yes it seems too that the <br /> tag in non-quirks mode will now act as white space in terms of its effects on bidi text.
The <br /> tag in quirks mode will be a paragraph separator (for Microsoft) but not otherwise it seems. }
=> "User agents that support bidirectional text must apply the Unicode bidirectional algorithm to every sequence of inline boxes uninterrupted by a forced (bidi class B) paragraph break or block boundary or by any break treated as a paragraph break."
 
> 3) In section 2.1, the sentence "The ‘direction’ property has no reordering in inline-level elements
> whose ‘unicode-bidi’ property's value is ‘normal’." is not clear to me. 
{ COMMENT:  this text is somewhat comprehensible for me; 
however, you might insert, "since no additional level of embedding is opened . . . . ;" 
if you do, I suggest inserting this at the front of the sentence so as to avoid confusion about whether the "since" clause modifies the property's value's being set to normal, or the resulting lack of reordering. }
=> "Since no additional level of embedding is opened when an element's "unicode-bidi" property's value is set to "normal,"  the direction property in this case does not reorder inline-level elements."

> 4) Section 2.2, in the paragraph explaining "embed": there is no need for a semicolon after
> Unicode values U+202A and U+202B. 
>     Rationale: they are not entities. 
{ COMMENT:  I thought that in html documents 
all characters' codes were finished with a semi-colon --
however these are not used for these in tr9 at unicode
(http://www.unicode.org/reports/tr9/#Directional_Formatting_Codes).
In any case, if you do keep them, then U+202C needs one for consistency here. }
"at the start of the element and a PDF (U+202C) at the end of the element. "
=>
"at the start of the element and a PDF (U+202C;) at the end of the element."

> 5) Ibidem: the description does not explain what "embed" would mean for block-level elements. 
I disagree here; I think "embed" is sufficiently explained.
 
> 6) Section 2.2, in the paragraph explaining "bidi-override": there is no need for a semicolon after
> Unicode values U+202D and U+202E. 
>    Rationale: they are not entities. 
{ Ditto here what I said for comment (4);
again you would need a semi-colon after U+202C for consistency if you leave the semi-colons intact elsewhere. }
"at the start of the element and a PDF (U+202C) at the end of the element. "
=>
"at the start of the element and a PDF (U+202C;) at the end of the element. "
> 7) In section 2.2, the order of the explanations for the values should rather be: normal, embed,
> isolate, plaintext, bidi-override, like in the prototype. 
> The current order does not seem to correspond to anything.

I agree:  "isolate" not "bidi-override" should follow embed.  (I am an order freak anyway C:   .)
> 8) In section 2.2, the text says: "Because the Unicode algorithm has a limit of 61 levels of
> embedding, care should be taken not to use ‘unicode-bidi’ with a value other than ‘normal’ unless
> appropriate. In particular, a value of ‘inherit’ should be used with extreme caution." 
> The value "inherit" has not been mentioned above as valid for the unicode-bidi property. 
Yes, it should be defined, albeit with a caution note.
Best,
 
--C. E. Whitehead
cewcathar@hotmail.com 
 
  
> <end of comments> 
> Shalom (Regards),  Mati
>         Bidi Architect
>          Globalization Center Of Competency - Bidirectional Scripts
>         IBM Israel
>          Fax: +972 2 5870333    Mobile: +972 52 2554160