A Few Proofreading Comments/Corrections (mainly trivial; was: Re: new draft, list of bugs to be filed)

Re: new draft, list of bugs to be filed
From: Aharon (Vladimir) Lanin <aharon@google.com> 
Date: Wed, 29 Sep 2010 12:26:11 +0200 
To: 
> I have sent to Richard Ishida of the i18n WG the bugs to be filed on HTML5,
> so the i18n WG can track them. Sometime today, they will become visible on
> http://www.w3.org/International/reviews/0802-html5/ (it's numbers 9 through
> 30), and Richard will mass-upload them to the HTML WG database
Hi, here are a few very trivial proofreading corrections (through part 3.3 and maybe 3.4 ) of the draft at:
http://www.w3.org/International/docs/html-bidi-requirements/
(I will try to comb through the rest ASAP; sorry)

2.1  The Problem
par 3 last sentence

"However, when an inline entity is allowed to contain text of arbitrary direction, bad things start happening, and existing HTML mark-up is powerless to stop it"
{ COMMENT:  "bad things" is a bit vague.  No change is needed but it seems to be punctuation and numbers that get messed up, as well as text from another source where the direction has to be guessed.  And finally of course rlo and other such characters can be maliciously used.  Don't know if you want to be this explicit here or not. }

* * *
2.1 Proposed Solution, part 2, first par, second bullet:
 
"* empty string, specifying isolation just like the "ubi" value. The empty string value allows specifying the attribute without a value for conciseness, e.g. <span dir="rtl" ubi>. "
 
{ COMMENT on CONTENT ONLY:  I would think that "" or the empty string would specify a default value; but the default value is "off;" and ubi="" makes sdoes seem to be saying specifying value as "on" or "ubi"  Thus I could not decide whether ubi="" should specify the default value or should specify on. }
* * *
2.2

first section "The Problem" par 1
 
"Many web applications with an RTL-language interface or an RTL-language data source need to display and accept as input both LTR and RTL data. Furthermore, the application often does not know and can not control the direction of the data."
 
{ COMMENT:  typo?  Change "can not" to "cannot" ("cannot" is normally one word!) }
=>
"Many web applications with an RTL-language interface or an RTL-language data source need to display and accept as input both LTR and RTL data. Furthermore, the application often does not know and cannot control the direction of the data."

* * *
2.2, second section "Not the problem"
 
{ COMMENT:  cute subheading -- what does it mean? A different subheading --  "A Clarification" or "Notes" -- would be prosaic and less-than-witty but would say exactly what you want to say I think . . . 
Another possibility:  "Discerning base directionality of input is distinct from displaying inadequate markup" -- plus a note to see section 2.1 for problems with markup; or perhaps "Clarifications:  Problems discerning base direction versus problems with markup;" both are closer to your topic is }

* * * 
2.2, second section "Not the problem," par 2 ff

"This is distinct from a different, harder issue: text mixing LTR and RTL without using the formatting characters necessary to display it intelligibly using standard UBA rules."
 
{ COMMENT: a reference back to section 2.1 would be nice . . . or are these not really the issues discussed in section 2.1? }
* * * 
2.2, Proposed Solution, Par 6
 
"Note that this last case includes "formatted numbers", e.g. "(617) 987-6543" and "-15.2%". "
 
{ COMMENT on CONTENT ONLY:  Obviously I am still having problems with Arabic numbers in some cases . . . but this is not my lang.  But I know in dates they are rtl.  And the plus goes on the right side of the phone number in letterhead with the phone number displayed at the base in both English and Arabic -- in my experience; dashes however might mean ltr  ;
See also, par 9 (second to last par):
"Please note that the direction that any direction estimation algorithm will assign to text mixing LTR and RTL characters, although well-defined, may not always be correct as judged by a human user. " }
* * * 
 
3.1, Background, par 5 

"The former usage needs a UBA paragraph break, while the latter usage wants no more bidi separation than other kinds of whitespace. The UBA resolves this ambiguity in favor of the paragraph break because of its importance. All common UBA implementations for plain text treat line breaks as a UBA paragraph break, in accordance with the UBA specification. 
The UBA leaves the definition of a "paragraph" in higher-level protocols like HTML up to the protocol. "
 
{ COMMENT:  "The UBA resolves this ambiguity in favor of the paragraph break because of its importance" seems confusing to me.  First the pronoun reference -- what does "its importance" refer to?  To the importance of the paragraph break or the UBA or the ambiguity?  Second -- what does this sentence mean exactly? I'm not even sure you need this sentence, that it adds anything here.  (Maybe I don't understand something, of course.) }
 
=> 
"The former usage needs a UBA paragraph break, while the latter usage wants no more bidi separation than other kinds of whitespace. 
All common UBA implementations for plain text treat line breaks as a UBA paragraph break, in accordance with the UBA specification. 
The UBA leaves the definition of a "paragraph" in higher-level protocols like HTML up to the protocol. "

{ COMMENT on CONTENT:  The default you are proposing may not work for stanzas of poetry . . . however most poetry is written in one language so it's not applicable perhaps.  Also I am afraid content authors will not like the fancy markup or being forced to select by applications -- but we can wait and see.  Sorry I did not get this comment to you sooner.  I needed to see this whole finalized text to finally think, "What if I were writing something using these proposed features?"  But I would like for css stuff to be reopened -- the current default behavior with IE (does this mean we should have bidi br= soft||hard||ie-style ???) }
 * * *
3.1 Proposed Solution, last par, last sentence
 
"Furthermore, for every element between there and the <br> that results in the creation of an embedding or override level, e.g. a <bdo> element or any element with a dir attribute or a value other than "normal" for the unicode-bidi CSS property, the correspondeng embedding or override level is re-introduced at the start of the new UBA paragraph (to be closed at the end of the element or the UBA paragraph, whichever comes first). "
 
{ COMMENT -- IMPORTANT:  typo:  "correspondeng" should be "corresponding" }
 
"Furthermore, for every element between there and the <br> that results in the creation of an embedding or override level, e.g. a <bdo> element or any element with a dir attribute or a value other than "normal" for the unicode-bidi CSS property, the corresponding embedding or override level is re-introduced at the start of the new UBA paragraph (to be closed at the end of the element or the UBA paragraph, whichever comes first). "
* * *
3.3  The Problem, last par, last 3 sentences
 
"This was done to prevent the bidi ordering within such an element from being affected by the element's surroundings, as it would not be affected if it still had block display. To date, the only browser to implement this specification is Firefox. And, as we have seen in Section 2.1 , this specification does not go far enough, since adding a dir attribute to an inline element does not prevent it from affecting the bidi ordering of its surroundings in ways that a separate block would not. So, should we now also start treating block elements with inline display as UBA paragraph breaks? "

{COMMENT/REQUEST for CLARIFICATION:  regarding the block element with display set to inline:  do you mean to prevent it from being affected by the element's surroundings or from affecting them or both?; first you seem tosay from being affected by its surroundings, then you seem to say from affecting its surroundings.  }
* * *
3.4 The Problem, first par
 
"Services like Javascript's alert() and confirm() fnctions"
 
{ COMMENT:  isn't this a typo?  Don't you mean "functions?" Or should the vowel be mssing here? }
=>
"Services like Javascript's alert() and confirm() functions"
* * *
This does it through 3.3 (and part of 3.4); still have to go through 3.4 ff carefully.  (And yes, regarding the comments on content, I know I must now get an account at bugzilla and send these sorts of comments to that list.)

Best,
--C. E. Whitehead
cewcathar@hotmail.com

Received on Sunday, 3 October 2010 23:41:12 UTC