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

The W3C CSS Working Group has published a Last Call Working Draft of the CSS Text Module Level 3: http://www.w3.org/TR/css-text-3/ This module covers various aspects of text layout including white space processing, text transformations, line breaking, justification, and indentation, including additions to level 2 to address internationalization concerns, allowing better typography in non-Western (and Western) scripts. Significant changes since the previous CSS3 Text WD are listed at: http://www.w3.org/TR/2013/WD-css-text-3-20131010/#changes The deadline for comments is ** Thursday 7 November 2013 ** If you need more time, please request an extension before the deadline so that we know to wait for your comments. We plan to process the bulk of the LC comments that weekend and during TPAC the week after. It's okay if you need more time, we just need to know about it. :) Please send any comments to the <www-style@w3.org> mailing list http://lists.w3.org/Archives/Public/www-style/ and please, prefix the subject line with [css-text] as I did on this message so that we don't lose track of your feedback. Alternately, you may ask one of the editors (myself or Koji Ishii) to forward your comments. We would especially appreciate a detailed review from the following typographic communities, particularly on the topics of line-breaking and justification: * Korean * Southeast Asian * Indic Please forward this announcement as appropriate; we really need a worldwide review on this one. ~fantasai

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

On 7/11/13 15:20, CE Whitehead wrote: > 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; I think you're mis-parsing this sentence. To clarify, "transforms" is the main verb in this clause, not part of a "‘full-width’ transforms" noun phrase; and "preserved" is used as a participial adjective describing those U+0020 spaces that were not removed during white space processing. But IMO it might be easier to understand if this were spelled out a little more fully, perhaps like: "Text transformation happens after white space processing, which means that ‘full-width’ only transforms U+0020 spaces to U+3000 within preserved white space." JK

Thanks for the reply. From: Jonathan Kew <jfkthame@googlemail.com> Date: Thu, 07 Nov 2013 16:27:08 +0000 Message-ID: <527BBF5C.7090900@gmail.com> To: www-style@w3.org On 7/11/13 15:20, CE Whitehead wrote: >> 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; > I think you're mis-parsing this sentence. To clarify, "transforms" is > the main verb in this clause, not part of a "‘full-width’ transforms" > noun phrase; and "preserved" is used as a participial adjective > describing those U+0020 spaces that were not removed during white space > processing. Yes, you are right; I did mis-parse this sentence! Sorry. > But IMO it might be easier to understand if this were spelled out a > little more fully, perhaps like: > "Text transformation happens after white space processing, which means > that ‘full-width’ only transforms U+0020 spaces to U+3000 within > preserved white space." Yes this is nice! > JK Thanks, Jonathan. Best, --C. E. Whitehead cewcathar@hotmail.com

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

Updated as proposed by Jonathan, thank you both. From: CE Whitehead <cewcathar@hotmail.com<mailto:cewcathar@hotmail.com>> Date: Friday, November 8, 2013 11:43 AM To: "jfkthame@googlemail.com<mailto:jfkthame@googlemail.com>" <jfkthame@googlemail.com<mailto:jfkthame@googlemail.com>>, "www-style@w3.org<mailto:www-style@w3.org>" <www-style@w3.org<mailto:www-style@w3.org>> Subject: Re: [CSSWG][css-text-3] CSS3 Text Last Call Working Draft Resent-From: <www-style@w3.org<mailto:www-style@w3.org>> Resent-Date: Friday, November 8, 2013 11:43 AM Thanks for the reply. From: Jonathan Kew <jfkthame@googlemail.com<mailto:jfkthame@googlemail.com?Subject=Re%3A%20%5BCSSWG%5D%5Bcss-text-3%5D%20CSS3%20Text%20Last%20Call%20Working%20Draft&In-Reply-To=%3C527BBF5C.7090900%40gmail.com%3E&References=%3C527BBF5C.7090900%40gmail.com%3E>> Date: Thu, 07 Nov 2013 16:27:08 +0000 Message-ID: <527BBF5C.7090900@gmail.com<mailto:527BBF5C.7090900@gmail.com>> To: www-style@w3.org<mailto:www-style@w3.org?Subject=Re%3A%20%5BCSSWG%5D%5Bcss-text-3%5D%20CSS3%20Text%20Last%20Call%20Working%20Draft&In-Reply-To=%3C527BBF5C.7090900%40gmail.com%3E&References=%3C527BBF5C.7090900%40gmail.com%3E> On 7/11/13 15:20, CE Whitehead wrote: >> 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; > I think you're mis-parsing this sentence. To clarify, "transforms" is > the main verb in this clause, not part of a "‘full-width’ transforms" > noun phrase; and "preserved" is used as a participial adjective > describing those U+0020 spaces that were not removed during white space > processing. Yes, you are right; I did mis-parse this sentence! Sorry. > But IMO it might be easier to understand if this were spelled out a > little more fully, perhaps like: > "Text transformation happens after white space processing, which means > that ‘full-width’ only transforms U+0020 spaces to U+3000 within > preserved white space." Yes this is nice! > JK Thanks, Jonathan. Best, --C. E. Whitehead cewcathar@hotmail.com<mailto:cewcathar@hotmail.com>

Took the proposed changes for the section 4. Thank you for the feedback. From: CE Whitehead <cewcathar@hotmail.com<mailto:cewcathar@hotmail.com>> Date: Thursday, November 7, 2013 11:20 PM To: fantasai <fantasai.lists@inkedblade.net<mailto:fantasai.lists@inkedblade.net>>, "www-style@w3.org<mailto:www-style@w3.org>" <www-style@w3.org<mailto:www-style@w3.org>> Subject: [CSSWG][css-text-3] CSS3 Text Last Call Working Draft Resent-From: <www-style@w3.org<mailto:www-style@w3.org>> Resent-Date: Thursday, November 7, 2013 11:21 PM 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. "

This one is too hard for me to judge, I'll consult with my co-editor and get back to the ML. From: CE Whitehead <cewcathar@hotmail.com<mailto:cewcathar@hotmail.com>> Date: Thursday, November 7, 2013 11:20 PM 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<mailto:cewcathar@hotmail.com>

Fixed as you suggested, thank you for the feedback. From: CE Whitehead <cewcathar@hotmail.com<mailto:cewcathar@hotmail.com>> Date: Friday, November 8, 2013 12:21 PM To: fantasai <fantasai.lists@inkedblade.net<mailto:fantasai.lists@inkedblade.net>>, "www-style@w3.org<mailto:www-style@w3.org>" <www-style@w3.org<mailto:www-style@w3.org>> Subject: RE: [CSSWG][css-text-3] CSS3 Text Last Call Working Draft Resent-From: <www-style@w3.org<mailto:www-style@w3.org>> Resent-Date: Friday, November 8, 2013 12:21 PM 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:"

These are beyond my English capability, I'll consult with someone to get back to you. From: CE Whitehead <cewcathar@hotmail.com<mailto:cewcathar@hotmail.com>> Date: Friday, November 8, 2013 12:21 PM To: fantasai <fantasai.lists@inkedblade.net<mailto:fantasai.lists@inkedblade.net>>, "www-style@w3.org<mailto:www-style@w3.org>" <www-style@w3.org<mailto:www-style@w3.org>> Subject: RE: [CSSWG][css-text-3] CSS3 Text Last Call Working Draft Resent-From: <www-style@w3.org<mailto:www-style@w3.org>> Resent-Date: Friday, November 8, 2013 12:21 PM 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’. "

On 11/07/2013 07:20 AM, CE Whitehead wrote: > > 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. } I disagree with changing this, because the phrase after the colon is a strict expansion of "such formatting". Prefer therefore to leave it as a colon. ~fantasai

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

On 11/07/2013 08:21 PM, CE Whitehead wrote: > > 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. I think the recommendation is fine; as long there is a reasonable minimum length before breaking at a non-space (and that minimum could vary by the measure), it is definitely better to allow breaks at punctuation such as slashes. And there are other characters, such as em dashes, for which breaking at punctuation is pretty much always better than disallowing such breaks. > Also I am confused about the word "such." What "such awkward breaks" > are you referring to? "such" is referring to the example in the previous sentence. I've swapped out the order of sentences so that it is now in the immediately-previous sentence. > > 5.2 2nd or 3rd par? 1rst bulleted item > "Following breaks be forbidden in ‘strict’ line breaking and allowed in > ‘normal’ and ‘loose’: > > { COMMENT/QUESTION: Don't you mean, "The following breaks . . . ??" > I think you have omitted the definite article here. I Yes. Fixed. > 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 } I've reworded the section. Hopefully it's acceptable now. > "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"?} Yes, fixed. > 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. } Also fixed. ~fantasai

> Date: Sat, 10 May 2014 12:26:08 -0700 > From: fantasai.lists@inkedblade.net > To: cewcathar@hotmail.com; www-style@w3.org > Subject: Re: [CSSWG][css-text-3] CSS3 Text Last Call Working Draft > > On 11/07/2013 07:20 AM, CE Whitehead wrote: > > > > 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. } > > I disagree with changing this, because the phrase after the colon is a strict > expansion of "such formatting". Prefer therefore to leave it as a colon. > > ~fantasai You are correct in disagreeing as the : (colon) is consistent with how you punctuate this sort of sentence elsewhere; so leave it as is here. My mistake. Best, --C. E. Whitehead cewcathar@hotmail.com

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

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

On 05/16/2014 07:58 AM, CE Whitehead wrote: > 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 } Fair enough. Fixed as you suggest. :) > > * * * > 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.) Fixed. > * * * > 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" > } Done. > * * * > 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."} I think the "instead" covers this. Closing no change, if that's alright with you. --- Btw, might I beg you to use an email-quoting mechanism for your spec quotes? I'm happy to receive plaintext email with > or # quote marks or HTML email with appropriate use of <blockquote> or some other formatting convention (such as italics). It's hard for me to pick out your comments with the current formatting: it all flows together, and I must confess to procrastinating on my response because of this visual-parsing frustration... (Fwiw, I typically #-quote spec prose, |-quote proposed text, and >-quote the message I'm replying to. But you don't have to be so specific... as long as I can visually distinguish your comments from the quoted text, it's fine.) Thanks! ~fantasai p.s. Also, please don't tag your messages with [CSSWG]. All of www-style is for CSSWG discussion -- the [CSSWG] tag is just for official CSSWG announcements and minutes. :)

On 05/28/2014 09:44 PM, CE Whitehead wrote: > 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. " Done. > * * * > > 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." I took the first change. The second seemed a bit awkward to me. > * * * > 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." I'm doubtful that cursive is a superset of shaping, so leaving it as-is. They are technically independent phenomena: for example, Greek Final Sigma could have been a shaped glyph form of Greek Sigma. It simply wasn't encoded that way in Unicode. > * * * > 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.)" Good catch. Fixed. > * * * > 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.} I think I agree with leaving them uncited. :) The content is not important to us here, only the typography is. > 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.} Indeed, it is quite common for "newspaper-printing" fonts such as those used to typeset most books. For more calligraphic styles, it's a bit more complicated, as the the Tasmeem example shows. > * * * > 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?} You can, if you want. In CSS negative numbers are represented with a minus sign, and positive numbers are indicated with either no sign or a plus sign. This does not need to be called out here. Let me know if these responses are acceptable! ~fantasai