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

Hi!  I've finally gotten to commenting on the rest of the draft -- 
I know you all are busy right now discussing the comments on bugzilla (I will try to get caught up on those too) -- perhaps thus comments on the draft are not that helpful at this point, but here they are for what they are worth.
 
(NOTE  Although I consider essential to have html display rtl and ltr when mixed together in as correct an order as possible, like fantasai I did think some specifications were out of scope -- that is, in the third section of the draft, I did not think it was within the scope of the html specifications to specify, for example, how JavaScript should be implemented although I felt css attributes that might be used in the implementation of JavaScript could and should be specified;
when it's important to specify how to implement the scripts themselves, I agree contacting the browser makers is the right way to go.)
 
From: CE Whitehead <cewcathar@hotmail.com> 
Date: Sun, 3 Oct 2010 19:40:37 -0400
 
> From: Aharon (Vladimir) Lanin <aharon@google.com> 
> Date: Wed, 29 Sep 2010 12:26:11 +0200 
> . . .
>> 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
 
* * * * * *
 
Here's the rest:
{ Missed the following last time }
3.3, Proposed Solution, par 2, 1rst sentence
"If the display:block element has display:inline ancestors that have bidi properties (e.g. the dir attribute or the <bdo> element), these bidi properties should be applied to the anonymous block boxes created for these ancestors, in accordince with CSS specs for anonymous block boxes."
{ COMMENT:  "accordince" is misspelled; it should be "accordance"m}
=>
"If the display:block element has display:inline ancestors that have bidi properties (e.g. the dir attribute or the <bdo> element), these bidi properties should be applied to the anonymous block boxes created for these ancestors, in accordance with CSS specs for anonymous block boxes."
* * *
3.4 Proposed Solution, par 1, 1rst sentence
"Ideally, functions like Javascript's alert(), confirm and prompt() should take an optional paramter indicating the text's direction."
{ COMMENT:  again a typo/missing vowel; "paramter" should be "parameter." }
=>
"Ideally, functions like Javascript's alert(), confirm and prompt() should take an optional parameter indicating the text's direction."
* * *
3.4 Proposed Solution, par 2
"However, there is also a need for reasonably useful default behavior when the script does not make use of such a parameter, even if and when such parameters in fact become available, and certainly before that blessed day."
{ COMMENT:  "blessed day" -- this usage of "blessed" would not IMO generally occur in a technical report of this formality. }
* * *
3.8  Proposed Solution, par 1
"The HTML specification should state that some way to set the direction of <input type="text"> and <textarea> elements should be exposed to the user, and using it will: "
{ COMMENT:  I did not know the HTML spec could make a statement like this; you would have to specify a css place that dir could be set and then get in touch with the makers of Chrome, Mozilla/Firefox, Safari, IE, and so forth . . . and tell them to make sure that the user can set that property . . . }
* * *
3.9  Proposed Solution, par 1
"The HTML specification should state that whenever a user agent stores a user-provided <input type="text"> or <textarea> value for later use (such as auto-completion), it should also store the nominal direction value the element had when displaying this value. This may be the original direction of the element, or may have been set by the user for that value via keyboard shortcuts, or may have been set for that value by page scripts. If the user agent later displays the value in an auto-completion dropdown, it should be displayed in its stored direction. If the value is assigned to an element, the element's dir value should be set to its stored direction. "
{ COMMENT:  ditto what I said for 3.8.  You can specify a CSS feature for storing a dir value for text input but that's it as far as I know; the w3c won't let you tell the browser makers how to every step }
* * 
3.10 Proposed Solution, pars 1-3; also examples of how things should look
"The HTML specification should state that, by default, the markers of all "list-style-position:outside" items should disregard the list item element's computed direction, using the list element's computed direction instead for the marker's display and positioning. 
CSS will provide means to control this. If the CSS default in this respect must differ, the default stylesheet should achieve the default behavior specified above. 
Furthermore, the list marker text will be directionally isolated from the list item text, appearing in its own UBA paragraph. "
{ COMMENT:  par 1 and 2 you need to specify the css feature that will provide the means to control this I think; par 3 is o.k.
One other note on how things should look; I do think we did discuss the possibility -- but must check -- that the bullet could be displayed on the same side that the element aligned, which of course aligned based on its dir??  Maybe not . . . }
* * *
3.11 The Problem, par 1
"In a browser open on a given page, the UI is made up of two parts: the chrome of the browser itself (e.g. its menus and toolbars), and the page being displayed in the browser. The two parts can be and often are in two different langauges and thus directions. "
{ COMMENT: spelling/typo  "langauges" should be "languages" gauge is that a word?  I think it is check
I cannot comment otherwise on this proposal; again I think this is out of scope; sorry but I do agree it is a nice recommendation; you can send it to the browser makers }
=>
"In a browser open on a given page, the UI is made up of two parts: the chrome of the browser itself (e.g. its menus and toolbars), and the page being displayed in the browser. The two parts can be and often are in two different languages and thus directions. "
* * *
One general comment:  as for plain text, html should properly support rtl and ltr input; that much is clear; both directions, mixed directions, it is the job of html to support.
But details about how an attribute provided for in html is set using scripts -- well I cannot get my very basic scripts to work in all browsers and I do not think the W3C has ever cared to define JavaScript; they have standards for html but no browser maker has to support any JavaScript feature any other maker is supporting, and will not do so unless not supporting that feature/implementation is costing business.
 
This does it through 3.10; still have to go through 3.11 ff carefully
(hope this is formatted o.k.; my email did some strange things when I tried to reply; there were rtl characters at the end of it which I did not insert).
Best,
--C. E. Whitehead
cewcathar@hotmail.com

Received on Sunday, 10 October 2010 19:33:01 UTC