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

Hi, once more; here are my additional comments on the draft (http://www.w3.org/TR/css-text-3/) .
(I hope I have made the deadline.)  As noted, most are proofreading comments:  I think you omitted a couple of definite articles and one preposition.  I do have one comment on content, on 5.1.


5.1, par 1, 3rd bullet

"As long as care is taken to avoid such awkward breaks, allowing breaks at appropriate punctuation other than spaces is recommended, as it results in more even-looking margins, particularly in narrow measures. "
{ COMMENT on Content:  "recommended"? I am not sure that this practice is always "recommended" in languages such as English and French,  when the column width/text box width is not narrow; however breaking longer urls at slashes might be recommended in most every language (you do not mention urls; but that's a common instance where text  is broken where there are no spaces). But I am not sure that you should use the word "recommended" when talking about breaking of standard written prose. Also I am confused about the word "such." What "such awkward breaks" are you referring to?

=>
"As long as care is taken to avoid awkward breaks (such as ?), allowing breaks 
at appropriate punctuation other than spaces is acceptable in some cases, particularly when the text must fit into a narrow width, as it 
results in more even-looking margins."


5.2 2nd or 3rd par? 1rst bulleted item
 "Following breaks be forbidden in ‘strict’ line breaking and allowed in ‘normal’ and ‘loose’:

    breaks before Japanese small kana or the Katakana-Hiragana prolonged sound mark: i.e. characters with the Unicode Line Break property CJ. (See LineBreak.txt in [UNICODE].) "

{ COMMENT/QUESTION: Don't you mean, "The following breaks . . . ??" I think you have omitted the definite article here.    I have the same comment on the second bulleted item, "Following breaks be forbidden in ‘normal’
    and ‘strict’ line breaking and allowed in
    ‘loose’" => "The following breaks be forbidden in . . . "; in any case, I think this whole set of bulleted items might benefit from rewording; I particularly did not like breaking up "that" and "be forbidden"; in my rewrite, I've used * to indicate the outer bullet and + to indicate the inner one }

"However, this specification does require that:

  *  Following breaks be forbidden in ‘strict’ line breaking and allowed in ‘normal’ and ‘loose’:
      +  breaks before Japanese small kana or the Katakana-Hiragana prolonged sound mark: i.e. characters with the Unicode Line Break property CJ. (See LineBreak.txt in [UNICODE].) 
     If the content language is Chinese or Japanese, then additionally allow (but otherwise forbid) for ‘normal’ and ‘loose’:
      +  breaks before hyphens:
        ‐ U+2010, – U+2013, 〜 U+301C, ゠ U+30A0 
  *  Following breaks be forbidden in ‘normal’ and ‘strict’ line breaking and allowed in ‘loose’:
      +   breaks before iteration marks:
        々 U+3005, 〻 U+303B, ゝ U+309D, ゞ U+309E, ヽ U+30FD, ヾ U+30FE
      +  breaks between inseparable characters such as ‥ U+2025, … U+2026 i.e. characters with the Unicode Line Break property IN. (See LineBreak.txt in [UNICODE].) 
     If the content language is Chinese or Japanese, then additionally allow (but otherwise forbid) for ‘loose’:
       +  breaks before certain centered punctuation marks:
          : U+003A, ; U+003B, ・ U+30FB, ： U+FF1A, ； U+FF1B, ･ U+FF65, ! U+0021, ? U+003F, ‼ U+203C, ⁇ U+2047, ⁈ U+2048, ⁉ U+2049, ！ U+FF01, ？ U+FF1F
      +  breaks before suffixes:
        % U+0025, ¢ U+00A2, ° U+00B0, ‰ U+2030, ′ U+2032, ″ U+2033, ℃ U+2103, ％ U+FF05, ￠ U+FFE0
      +  breaks after prefixes:
        № U+2116 and all currency symbols (Unicode general category Sc) other than ¢ U+00A2 and ￠ U+FFE0 "

=>

"However, this specification requires the  following:

  *  The following breaks are/must be forbidden in ‘strict’ line breaking and allowed in ‘normal’ and ‘loose’:
       + breaks before Japanese small kana or the Katakana-Hiragana prolonged sound mark: i.e. characters with the Unicode Line Break property CJ. (See LineBreak.txt in [UNICODE].) 
    If the content language is Chinese or Japanese, then additionally allow (but otherwise forbid) for ‘normal’ and ‘loose’:
       + breaks before hyphens:
        ‐ U+2010, – U+2013, 〜 U+301C, ゠ U+30A0 
 * The following breaks are/must be forbidden in ‘normal’ and ‘strict’ line breaking and allowed in ‘loose’:
       + breaks before iteration marks:
        々 U+3005, 〻 U+303B, ゝ U+309D, ゞ U+309E, ヽ U+30FD, ヾ U+30FE
       + breaks between inseparable characters such as ‥ U+2025, … U+2026 i.e. characters with the Unicode Line Break property IN. (See LineBreak.txt in [UNICODE].) 
    If the content language is Chinese or Japanese, then additionally allow (but otherwise forbid) for ‘loose’:
       + breaks before certain centered punctuation marks:
        : U+003A, ; U+003B, ・ U+30FB, ： U+FF1A, ； U+FF1B, ･ U+FF65, ! U+0021, ? U+003F, ‼ U+203C, ⁇ U+2047, ⁈ U+2048, ⁉ U+2049, ！ U+FF01, ？ U+FF1F
       + breaks before suffixes:
        % U+0025, ¢ U+00A2, ° U+00B0, ‰ U+2030, ′ U+2032, ″ U+2033, ℃ U+2103, ％ U+FF05, ￠ U+FFE0
       + breaks after prefixes:
        № U+2116 and all currency symbols (Unicode general category Sc) other than ¢ U+00A2 and ￠ U+FFE0 "

7.3.1 par 2

"Similarly, when space is distributed an expansion opportunity between two characters, it is applied under the same rules as for ‘letter-spacing’. "

{ COMMENT: I think you have omitted a preposition here? Do you mean, "distributed TO an expansion opportunity"?}

=>
"Similarly, when space is distributed to an expansion opportunity between two characters, it is applied under the same rules as for ‘letter-spacing’. "

7.3.2 par 1

"When determining expansion opportunities, characters from the Unicode Symbols (S*) and Punctuation (P*) classes are generally treated the same as a letter:"
{ COMMENT: "characters" is a plural noun; "letter" is a singular; this sentence would read better if both were either singular or plural; so you have two options -- either make "letter" plural or somehow make "characters" singular. }
=>
"When determining expansion opportunities, characters from the Unicode Symbols (S*) and Punctuation (P*) classes are generally treated the same as letters:"
OR =>
"When determining expansion opportunities, a character from the Unicode Symbols (S*) or Punctuation (P*) classes are generally treated the same as a letter:"


Best,

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





From: cewcathar@hotmail.com
To: fantasai.lists@inkedblade.net; www-style@w3.org
Subject: [CSSWG][css-text-3] CSS3 Text Last Call Working Draft
Date: Thu, 7 Nov 2013 10:20:31 -0500




Hi.
I have not read all of your document (http://www.w3.org/TR/css-text-3/ ), but have a few proofreading comments (most concerned with sentences that in English normally take the present indicative, sentences that describe a fact or habitual action, what we call the "scientific or habitual present" I think).

2.1 Example 3 Discussion final paragraph

"Text transformation happens after white space processing, which means that ‘full-width’ transforms only preserved U+0020 spaces to U+3000. "
{ COMMENT: use the habitual/scientific present with "preserved" here, not the past tense; also I am confused by "only preserve U+0020 spaces to U+3000" -- do you mean that one of these is transformed into the other? Sorry to not be that familiar with what text transformation does. }
=>

"Text transformation happens after white space processing, which means that ‘full-width’ transforms only preserve?? U+0020 spaces to U+3000. "

4. 1rst paragraph
" CSS white space processing allows the author to control interpretation of such formatting: to preserve or collapse it away when rendering the document."

{ COMMENT: I would not use a colon after "formatting" but rather would use a comma. }

=>
" CSS white space processing allows the author to control interpretation of such formatting, to preserve or collapse it away when rendering the document."

4. 3rd paragraph

"CSS does not define document segmentation rules. Segments could be separated by a particular newline seqence (such as a line feed or CRLF pair), or delimited by some other mechanism, such as the SGML RECORD-START and RECORD-END tokens. "

{ COMMENT: "could" is not the right tense in English; again use the habitual or scientific present of the verb; that is, use "can" here instead of "could."}

=>
"CSS does not define document segmentation rules. Segments can be separated by a particular newline seqence (such as a line feed or CRLF pair), or delimited by some other mechanism, such as the SGML RECORD-START and RECORD-END tokens. "

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.)

--Best,

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