W3C home > Mailing lists > Public > www-style@w3.org > May 2014

RE: [CSSWG][css-text-3] CSS3 Text Last Call Working Draft

From: CE Whitehead <cewcathar@hotmail.com>
Date: Thu, 29 May 2014 00:44:12 -0400
Message-ID: <BLU174-W195A153202BB6B2E8EBDFEB3240@phx.gbl>
To: fantasai <fantasai.lists@inkedblade.net>, Koji Ishii <kojiishi@gluesoft.co.jp>, "www-style@w3.org" <www-style@w3.org>



Hi, Fantasai, I have a few more comments -- mostly proofreading -- on "CSS3 Text" (http://dev.w3.org/csswg/css-text-3/)  
* * *

5, Par 5"CSS does not fully define where soft wrap opportunities occur, however some controls are provided to distinguish common variations. "
{ COMMENT:  should not these two sentences be separated/conjoined by a semi-colon? }=>"CSS does not fully define where soft wrap opportunities occur; however some controls are provided to distinguish common variations. "
* * *
5.2; Under
"break-all"
'In addition to word-break:normal soft wrap opportunities, lines may break between any two semantically-perceived letters (except where forbidden by the line-break property). Hyphenation is not applied. This option is used mostly in a context where the text is predominantly using CJK characters with few non-CJK excerpts and it is desired that the text be better distributed on each line."
{COMMENT: The last sentence is awkward in English; the subject of "using" in "using CJK characters" is "text" but it really does not make sense to have the text using anything; the text is after all passive without someone making it up; also phrase "it is desired that text be better distributed on each line" is kind of vague I think; inserting "where" before this phrase makes it clearer IMO that it follows "this option is used" -- that it says where the option is used. }=>"In addition to word-break:normal soft wrap opportunities, lines may break between any two semantically-perceived letters (except where forbidden by the line-break property). Hyphenation is not applied. This option is used mostly in a context where the text consists predominantly of CJK characters with few non-CJK excerpts, and where it is desired that the text be better distributed on each line."
* * *
5.2
Last par
"When shaping scripts such as Arabic are allowed to break within words due to break-all, the characters must still be shaped as if the word were not broken."{COMMENT:  is shaping scripts" the most commonly used term to describe these types of scripts? If it is not a consistently used term in this context, it would be better if you said "cursive",  "when cursive scripts"
=>"When cursive scripts such as Arabic are allowed to break within words due to break-all, the characters must still be shaped as if the word were not broken."* * *6.1 auto 3rd par
" Such an automatic hyphenation points within a word are ignored when it contains soft hyphens (&shy; or U+00AD.)"{COMMENT:  "an" is never used before a plural noun, such as "points"}=>" Such  automatic hyphenation points within a word are ignored when it contains soft hyphens (&shy; or U+00AD.)"* * *7.4 example{COMMENT: Should you cite 'al-Khansaa as the source for the Arabic lines? I don't know other examples you have cited; I happen to know these lines -- maybe it's best to leave the examples uncited, the way you have them.}

* * *
7.4.4 Cursive Scripts
"Justification must not introduce gaps
 between visually-perceived letters of cursive scripts such as Arabic. 
If it is able, the UA may translate space distributed to justification 
opportunities within a run of such visually-perceived letters into some 
form of cursive elongation for that run. It otherwise must assume that 
no justification opportunity exists between any pair of 
visually-perceived letters in cursive script. "
{COMMENT on CONTENT: 
the traditional way I have seen Arabic letters elongated is that the 
line connecting them has been lengthened; this seems to be quite 
common.}
* * *
8 Example 13
"In the following example, word spacing is halved, but may expand if needed for text justification.
p { word-spacing: -50%; }"

{COMMENT:
 Fine; but I would like a bit more commenting; I assume that the "-" 
before "50%" means "minus";  thus do you insert "+" to indicate 150% 
word spacing?}
* * *

Best, 

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



From: cewcathar@hotmail.com
To: fantasai.lists@inkedblade.net; kojiishi@gluesoft.co.jp; www-style@w3.org
Subject: RE: [CSSWG][css-text-3] CSS3 Text Last Call Working Draft
Date: Fri, 16 May 2014 10:58:24 -0400




Hi, once more fantasai; I do have a bit more feedback -- more comments on:
http://dev.w3.org/csswg/css-text-3/#uax29

2.1 Case Transforms: the 'text-transform' property
following the list of possible values and just above "EXAMPLE 3"

"The definition of “word“ used for capitalize is UA-dependent; [UAX29] is suggested (but not required) for determining such word boundaries. Authors should not expect capitalize to follow language-specific titlecasing conventions (such as skipping articles in English). "

{ COMMENT: I cannot make sense of "used for" here --
do you mean that, 
=>
"for the value, 'capitalize,' what constitutes a "word" is UA-dependent?" 
I assume so; you can of course leave your sentence as is -- nothing wrong with the grammar, but it jolted me reading it }

* * *
4. White Space Processing Details
4th par -- which is note under the 3rd par

"Note that the document parser may have not only normalized any segment breaks, but also collapsed other space characters or otherwise processed white space according to markup rules. Because CSS processing occurs after the parsing stage, it is not possible to restore these characters for styling. Therefore, some of the behavior specified below can be affected by these limitations and may be user agent dependent."

{COMMENT: this sentence is fine; however I would prefer to see the simple present tense here as the present perfect suggests to me that you have just talked about what the document processor did, that is the present perfect usually -- but not always -- needs an antecedent in the past tense. (You are mostly using the present tense in this section.) 

so I want this sentence to read (alas it does not sound right though) =>

"Note that a document parser may not only normalize any segment breaks, but also collapse other space characters or otherwise process white space according to markup rules. Because CSS processing occurs after the parsing stage, it is not possible to restore these characters for styling. Therefore, some of the behavior specified below can be affected by these limitations and may be user agent dependent."

Forget this option, because the verb should go before the not only and there are multiple verbs, 

but here is another attempt; to keep from breaking up the verb I had to get rid of 'maybe':

=>

"Note that the document parser not only normalizes [any] segment breaks, but also often collapses other space characters or otherwise processes white space according to markup rules. Because CSS processing occurs after the parsing stage, it is not possible to restore these characters for styling. Therefore, some of the behavior specified below can be affected by these limitations and may be user agent dependent."
Yes I placed the verb after "not only" and "but also" -- that's because these are different verbs in each case and so no need to place them before;
your sentence was fine; I just could not have discordant verbs following
"not only may" in the present tense.

Anyway your sentence may be best (-:}

* * *
IMPORTANT GRAMMAR
4.1.1 
par 1 1rst bullet 4th item in list

"Any space immediately following another collapsible space—even one outside the boundary of the inline containing that space, provided they are both within the same inline formatting context—is collapsed to have zero advance width."
{COMMENT: IMO "they" has no previous referent;
you have the two spaces but you mention them one at a time; 
so I would say for extra clarity, "both spaces"
}

=>
"Any space immediately following another collapsible space--even one outside the boundary of the inline containing that space, provided both spaces are within the same inline formatting context--is collapsed to have zero advance width."
* * *
IMPORTANT
4.1.1 Example 5, esp last paragraph -- 
"Note that there will be two spaces between A and B, and none between B and C. This is best avoided by putting spaces outside the element instead of just inside the opening and closing tags and, where practical, by relying on implicit bidirectionality instead of explicit embedding levels. "

{COMMENT: I cannot imagine anyone's leaving spaces just inside the span or rtl or whatever tags, flanking the text inside an element. But o.k., someone might do this.
But in your discussion you say, leave the spaces outside the element; well the person did have spaces outside the element, but the trouble was it was collapsed with the spaces inside the element.
So I am a little confused.
Do you mean that the person writing code should not leave spaces inside the element tags that wrap the element text, that spaces should be placed outside the element tags only? If so you could say "only."}

=>?
"Note that there will be two spaces between A and B, and none between B and C. This is best avoided by putting all spaces outside the element, that is by not wrapping the element with spaces just inside the opening and closing tags; and, where practical, by relying on implicit bidirectionality instead of explicit embedding levels. "
* * *


Best,

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

> Date: Sat, 10 May 2014 12:34:13 -0700
> From: fantasai.lists@inkedblade.net
> To: kojiishi@gluesoft.co.jp; cewcathar@hotmail.com; www-style@w3.org
> Subject: Re: [CSSWG][css-text-3] CSS3 Text Last Call Working Draft
> 
> On 11/13/2013 07:55 PM, Koji Ishii wrote:
> > This one is too hard for me to judge, I'll consult with my co-editor and get back to the ML.
> >
> > CE Whitehad wrote:
> >>     4.1.1. Example 4
> >>
> >>     "where the <ltr> element represents a left-to-right embedding and the <rtl> element represents a right-to-left embedding.
> >>     If the ‘white-space’ property is set to ‘normal’, the white-space processing model would result in the following:
> >>
> >>          The space before the B ( ) would collapse with the space after the A ( ).
> >>          The space before the C ( ) would collapse with the space after the B ( ).
> >>     This would leave two spaces, one after the A in the left-to-right embedding level, and one after the B in the
> >>     right-to-left embedding level. This is then ordered according to the Unicode bidirectional algorithm, with the end result
> >>     being:  "
> >>
> >>     { COMMENT: what you have is o.k., but with 'if . . . is . . . ' it is customary to use the future indicative for the
> >>     'then' clause; you have "[i]f the 'white-space' property is set to 'normal',"
> >>     following this it is customary to use the future tense, that is to use "will" instead of "would."
> >>     Later again, if you change these to the future,  use the habitual/scientific present, "leaves," instead of "would leave."
> >>     Also, perhaps because I am a southerner, I would say "[a]ll this is then ordered" instead of "[t]his is then ordered" (for
> >>     clarity).}
> >>     =>
> >>     "where the <ltr> element represents a left-to-right embedding and the <rtl> element represents a right-to-left embedding.
> >>     If the ‘white-space’ property is set to ‘normal’, the white-space processing model would result in the following:
> >>          The space before the B ( ) will collapse with the space after the A ( ).
> >>          The space before the C ( ) will collapse with the space after the B ( ).
> >>     This leaves two spaces, one after the A in the left-to-right embedding level, and one after the B in the right-to-left
> >>     embedding level. All this is then ordered according to the Unicode bidirectional algorithm, with the end result being:  "
> >>
> >>     (I'll try to proofread the rest of this later today. I do not believe I will have comments on the content.)
> 
> Ok, fixed.
> 
> ~fantasai
 		 	   		  
 		 	   		  
Received on Thursday, 29 May 2014 04:44:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:27 UTC