RE: Need to clarify the effects of bidi paragraph breaks

Hi, Aharon, Fantasai:
 
I do after all have a few comments on the draft
(http://www.w3.org/TR/html-bidi/), through sections 2.3 so far.
 
First,
Proofreading Nits
{ As usual my own comments are inserted between curly brackets {} 
Incidentally this document reads really well; thanks. }

* * *
2.1  The Problem, Example 2 last par, 3rd sentence

"If the context had been RTL and the entity LTR, the same magic would be worked by the RLM character (U+200F, ‏). "
{ COMMENT:  the grammar for a past unfulfilled condition (past time and the past perfect forms are used) is:
"if X had been Y then Z would have been . . ."
the grammar for an unreal condition (present time but the past tense forms are used):
"if X were Y then Z would be . . . "
native speakers frequently use the simple past tense for the "then clause" of a past unfulfilled condition statement;
maybe the rules in grammar books will eventually change and allow this;
in the meantime, technically, you should choose either all past perfect verb forms or all past verb forms. }

=>

"If the context had been RTL and the entity LTR, the same magic would have been worked by the RLM character (U+200F, ‏). "
OR { put this sentence in the present time by changing "had been" to "were" }
=>
"If the context were RTL and the entity LTR, the same magic would be worked by the RLM character (U+200F, ‏)."
* * *
2.1 The Problem Example 3
"The entity here is a code snippet ("position:relative"), marked with a span and its LTR direction, to be displayed in an RTL context."
{ COMMENT:  the above sentence would be clearer for me [that is, I could make sense of it faster skimming], and only slightly longer, if you
inserted a verb clause -- "and is" or "which is" or "and is intended" -- after the first clause about the entity, just before the phrase "to be displayed . . ." }
=>
"The entity here is a code snippet ("position:relative"), marked with a span and its LTR direction, and is intended to be displayed in an RTL context."

* * *

2.1 The Problem Example 4  { Important }
 
"The entities here are folder names displayed in "breadcrumbs" in an LTR context, where two of the folder names happen to be RTL. The intent is to have it displayed as"
 
{ COMMENT:  pronoun agreement; the "it" in the second sentence does not go with a plural subject;
I think you intended "it" to refer back to the text segment but you've never mentioned explicitly that you are talking about a text segment -- you are obviously of course
but in written English when you do not point to something, you've got to state what you are talking about explicitly at least once;
that's really important here as the immediately preceding reference, "folder names" is plural;
just a note: human readers normally look back in the text at most a clause or so for the item a pronoun is referring to;
so your best bet is probably to say "these" or "those" to refer to the plural noun "folders" }
=>
"The entities here are folder names displayed in "breadcrumbs" in an LTR context, where two of the folder names happen to be RTL. The intent is to have these displayed as . . ."
* * *
2.1 The Problem Example 5
"The entity here is the name of a user, as chosen by a malicious user to include the invisible RLO character (U+202E), followed by a status string. "
{ COMMENT:  sounds o.k. grammatically but . . . 
I am having problems with the connections, maybe because "as chosen" is sort of passive }
=>

"The entity here is the name of a user, in which a malicious user has included the invisible RLO character (U+202E), followed by a status string."

* * *

2.1 The Problem Example 5  { Important }

"The outcome is that this is displayed as 
joe hacker: nwardrevowhere the entity influenced the display of what follows it, reversing its characters."
{ COMMENT:  verb tense; everything but the word "influenced" is in the present tense;
you can have the entire clause in the present tense (since it's a statement of a fact about the entity;
facts are always true; we use the present tense in most cases). }
=>
"The outcome is that this is displayed as 
joe hacker: nwardrevowhere the entity influences the display of what follows it, reversing its characters."
* * *
2.1 The Problem 4th major par { 1rst par located below the examples }
"Currently, there is no reliable way to deal with Example 1 to Example 4 using mark-up, except by redundantly marking an entity's surroundings with the base direction, which is counterintuitive and painful to implement."
{ COMMENT:  for grammatical parallelism, you can replace the "by" clause, "except by redundantly marking . . ."  with a "to" clause,
"except to redundantly mark . . . " { this would make the clause parallel with "to deal with"  }
=>
"Currently, there is no reliable way to deal with Example 1 to Example 4 using mark-up, except to redundantly mark an entity's surroundings with the base direction, which is counterintuitive and painful to implement."

* * *
2.1 Proposed Solution last par  { Important in my opinion }

"The use of "imaginary" characters by higher level protocols such as HTML is explicitly allowed by the UBA's section 4.3, HL5 ("Provide artificial context")."
{ COMMENT:  I think this last paragraph seems "tagged on;" the text would read better for me 
if this paragraph were introduced with the heading, "Note:" }
=>
"Note:  The use of "imaginary" characters by higher level protocols such as HTML is explicitly allowed by the UBA's section 4.3, HL5 ("Provide artificial context")."
* * *
2.2 The Problem 1rst Par  { Important }

"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:  "cannot" is 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 Not the Problem
{ COMMENT:  O.k.; I still don't find this to be the clearest title . . .
perhaps:
"Other Issues with Mixing Text (Not Addressed Here)"
or 
"Inferring Base Direction of Text Versus Formatting Poorly Marked Up Text"
or 
"The Issue:  Inferring Base Direction of Text, Not Resolving All Problems With Poorly Marked Up Text" ?? 
}
* * *
2.2 Not the Problem 2nd to last par
"Such text does not include the Unicode formatting characters that could fix its display either because it must conform to a syntax that would misinterpret such characters, or simply because it was created by a human user that does not know such characters exist, much less how to enter or use them."
{ COMMENT:  for consistency the whole clause beginning "or simply because" should be in the past tense; however because this expresses a "general truth" (about users), many native speakers don't put the stuff about the user in the past;
so it's not an essential change,
but technically,
"that does not know such characters exist"
should be =>
"that did not know such characters existed" }
=>
"Such text does not include the Unicode formatting characters that could fix its display either because it must conform to a syntax that would misinterpret such characters, or simply because it was created by a human user that did not know such characters existed, much less how to enter or use them."

* * *
2.2 Estimation Algorithms 3rd Par 1rst two bullets  { Important for me }
" * Sometimes, there may be good reason to want to bias the estimation to a particular direction unless the actual value clearly indicates otherwise. For example, the value may be one title from a feed whose contents are, generally speaking, in a particular known language. 
" * When the value contains no strong-directional characters, it usually seems best to display it in the same direction as its surroundings, i.e. inherit the direction."

{ COMMENT:  sorry to ask a stupid question,
but why do you say "data string" and then suddenly say "value"?;
I expect "value" to refer to the value calculated by the heuristic so its use here confuses me;
sorry to ask a dumb question however, but I would like "value" defined here;
alternately I might replace it with "data" which would make sense to me personally. }
* * *
2.2 Estimation Algorithms 3rd par 1rst bullet  { Important? }
" * Sometimes, there may be good reason to want to bias the estimation to a particular direction unless the actual value clearly indicates otherwise. For example, the value may be one title from a feed whose contents are, generally speaking, in a particular known language. "
{ COMMENT:  the preposition "to" in "bias to a particular direction" sounds awkward in American/U.S. English; 
"toward" might work better }
" * Sometimes, there may be good reason to want to bias the estimation toward a particular direction unless the actual value clearly indicates otherwise. For example, the value may be one title from a feed whose contents are, generally speaking, in a particular known language. "
* * *
2.2. Proposed Solution, par 3
"It is meaningless to use an estimation algorithm on content mixed to the extent that it is unintelligible in both LTR and RTL (when displayed by standard UBA rules). "

{ COMMENT:  for cohesion with your section entitled "Not the Problem,"
you might insert here,
"As noted above" }

=>
"As noted above, it is meaningless to use an estimation algorithm on content mixed to the extent that it is unintelligible in both LTR and RTL (when displayed by standard UBA rules). "
* * *

* * *  Comments on Content . . . which -- except for my one comment on "Open Issues" -- I suppose are Useless * * *
2.1 Proposed Solution 1rst par bullets

"* bdi, a synonym for yes. Allows specifying the attribute without a value for conciseness, e.g. <span dir="rtl" bdi>. "

{ COMMENT: I still want also a 
bdi="" to mean yes . . . ;
that's my two cents; it's too late for this however }
* * *

2.2 Proposed Solution par 6 ("Further details:"), 2nd bullet:
" * No attempt will be made to exclude "hidden" content, whether using display:none style or any other invisibility technique."
{ COMMENT:  I am not sure about including "hidden" content . . . but it's again too late to change this. }

* * *
2.2 Open Issues  { These issues at least I can discuss }
{ I like having the algorithm exposed, but, in any case, even if the algorithm is not exposed, and you use "auto" for the value of "dir"
I do believe that implementations will estimate direction as they wish;
I am not an expert but I do like your comment that we might discuss specific examples where estimation might prove harmful . . . that's a good idea in my opinion }

* * * 

2.3 Proposed Solution par 3

"The new attribute could be called submit_dir, and would take three values: "yes", "no", and "submit_dir". The last would be a synonym for "yes", and would allow using the attribute without an explicit value, for short. The default would be "no". For example, let's assume that a dir attribute value to indicate direction estimation is "auto", and an RTL page contains the following form: "
{ COMMENT:  again I would like to have: submit_dir=""
which again would be a synonym for "yes."  But I know this is all past. }
 



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


From: cewcathar@hotmail.com
To: aharon@google.com; public-i18n-bidi@w3.org
CC: www-style@w3.org; fantasai.lists@inkedblade.net
Date: Wed, 23 Feb 2011 16:44:20 -0500
Subject: RE: Need to clarify the effects of bidi paragraph breaks





Hi.
 


From: aharon@google.com
Date: Wed, 23 Feb 2011 11:50:30 -0800
CC: www-style@w3.org; fantasai.lists@inkedblade.net; public-i18n-bidi@w3.org
Subject: Re: Need to clarify the effects of bidi paragraph breaks
To: public-i18n-bidi@w3.org


> I think that this thread needs the input of the Writing Modes editor. Fantasai, could you please
>  respond?
Hmm.  
 
(Aharon, for my part in this discourse, I was just trying to clarify text in response to questions on the list, not to ambiguities in the text; and thus in none of my comments in this email did I correct any of the draft or seek to -- .)
Best,
 
--C. E. Whitehead
cewcathar@hotmail.com 

 
> On Mon, Dec 20, 2010 at 10:17 AM, CE Whitehead <cewcathar@hotmail.com> wrote:




> Date: Thu, 16 Dec 2010 16:43:21 +1100
>>> From: alan@css-class.com
>> To: aharon@google.com
>> CC: www-style@w3.org; fantasai.lists@inkedblade.net; public-i18n-bidi@w3.org

>> Subject: Re: Need to clarify the effects of bidi paragraph breaks
>> 

>> On 16/12/2010 4:01 PM, Alan Gresley wrote:
>> > On 16/12/2010 9:11 AM, Aharon (Vladimir) Lanin wrote:
>> [snip]
>> >> Further down in the same major section, the definition of
>> >> unicode-bidi:plaintext<http://dev.w3.org/csswg/css3-writing-modes/#unicode-bidi
>> >>
>> >> states:
>> >>
>> >> "For the purposes of the Unicode bidirectional algorithm, the base
>> >> directionality of each "paragraph" for which the element is the
>> >> containing
>> >> block element is determined not by the element's computed ‘direction’ as
>> >> usual, but by following rules P1, P2, and P3 of the Unicode bidirectional
>> >> algorithm."
>> >
>> >
>> > Above I see "which the element." I have know idea what element is being
> > referred to here. 

> Any element that contains the current and that thus effects its computed direction -- or > is this confusing?

>> > This paragraph also seems to suggest an added meaning
>> > of a containing block. What is a containing block element?
 

> See the definition below of a containing block -- but I am guessing you already have
> this.

>> 
>> 
>> Should this read *containing block-level element*? I was thinking that 
>> it was referring to the CSS term, *containing block*.
>> 
 

> Hmm yes but in this case it's definitely an element that's been defined as the 
> containing block
 
> A containing block also can be a "viewport"; see:
 
> http://reference.sitepoint.com/css/containingblock
> "the value of the position property for that element.
> If the value of the position property is static (the default) or relative, the containing 
> block is formed by the edge of the content box of the nearest ancestor element whose > display property value is one of:
> * block *inline-block *list-item *run-in (only in a block formatting context; see 
> Formatting Concepts *table *table-cell
> If the value of the position property is absolute, the containing block is the nearest 
> positioned ancestor—in other words, the nearest ancestor whose position property has > one of the values absolute, fixed, or relative. The containing block is formed by the 
> padding edge of that ancestor.
> If the value of the position property is fixed, the containing block is the viewport (for > continuous media) or the page box (for paged media)."
 
> Hope this helps.
 
Best,
 
--C. E. Whitehead
cewcathar@hotmail.com 
> 

> -- 
> Alan http://css-class.com/
> 
> Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo
>