Disposition of comments on Last Call WD "CSS3 module: text"

(Note from editor: I have not put email address of private email senders to protect their email address from spam, I have those in file) 

Last modification: Michel Suignard, Monday March  17 2003

# source origin date comment answer
1 (Christoph Päper)  christoph.paeper@tu-clausthal.de www-style 21-Oct http://lists.w3.org/Archives/Public/www-style/2002Oct/0074.html

Is it out of scope of CSS to define how the lines of underline, overline and linethrough are drawn?

 Document updated: New possible values for text-underline-mode, text-overline-mode and text-line-through-mode: continuous, skip-space, skip-glyph and skip-glyph-and-space. ('skip-space' replaces 'words'). Introduction 9.1 modified to summarize this addition.
2       Distinguish <'text-underline'> || <'text-overline'> ... in text-decoration property Not applicable in October 24th document
3       Why isn't text-decoration: blink more configurable...why to keep the blink value. There is a large majority view in the CSS group to keep blink as it is. Note that 'text-blink' is now available as a separate property.
4 (Arthit Suriyawongkul)

Arthit.Suriyawongkul@Sun.COM

 www-style 08-Nov http://lists.w3.org/Archives/Public/www-style/2002Nov/0018.html

Add an 'underline-skipping-mode'

 See comment 1
5 (Paul Grosso)

pgrosso@arbortext.com

 www-style 25-Oct http://lists.w3.org/Archives/Public/www-style/2002Oct/0085.html

word-spacing How is word-spacing="none" different from white-space-treatment="ignore"?

 Document updated: word-spacing="none" removed. From that message and following discussions by Etan Wexler, Ian Hickson, Stuart Ballard and David Woolley, it doesn't appear that the behavior difference in the two cases warrants two separate property-value pairs. Both are presentational and do not (should not) affect the DOM.
6       http://lists.w3.org/Archives/Public/www-style/2002Oct/0086.html

wrap-option What CSS3 value has the semantic of XSL no-wrap? Hard-wrap? Called it no-wrap.

 Document updated: changed wrap-option="hard-wrap" to "no-wrap"
7       http://lists.w3.org/Archives/Public/www-style/2002Oct/0087.html

text-align-last Remove quote from 4.3 title

 Document updated
8       Is text-align-last='relative' the same as the XSL spec value 'relative'? if yes, should have the same name Document updated: 'auto' changed to 'relative'.
9       The justify value says "The last line will be justified like the other lines." Not compatible with XSL model. Document updated: The property 'text-justify' will now explicitly affects both text-align and text-align-last and description of text-align-last=justify' will align more closely with XSL description.
10 (Christoph Päper) christoph.paeper@tu-clausthal.de www-style 25-Oct http://lists.w3.org/Archives/Public/www-style/2002Oct/0092.html

Use a <dl/> for the cell glyphs legend

 Document updated, although not sure it looks better.
11       min- and max-font-size. Not sure "9px" is correct Document updated. Also commented by Bert Bos and Etan Wexler. The px notation was maintained (was intended) but explanation of the values improved and value lowered to 8px
12       Are min- and max-font-size only of use in conjunction with text-align-last: size? Document updated. Also commented by Bert Bos. Yes, the restriction mentioned is valid and made more explicit. Generalizing the effect is beyond the scope of the LC.
13       word-break-CJK, Isn't there a rule to have all CSS properties lowercase? Document updated, use now word-break-cjk.
14       Add a possibility to CSS to allow authors to specify a (custom) cross-browser hyphenation dictionary See answer from Bert Bos http://lists.w3.org/Archives/Public/www-style/2002Oct/0094.html This is being considered, but more work is necessary before including it.
15       line-feed-treatment and white-space-treatment values too long It is true that names are long and shorter names could be used. But there are also many people that favor consistency with XSL whenever possible.
16       Text overflow, clarify the usage of ellipsis Document updated: Also commented by Bert Bos (see comment 14 ref), now says explicitly that the ellipsis is the single Unicode value U+2026, while offering some flexibility to user agents. See also comment 113.
17       In text overflow, example not marked like others, use blockquote instead of div.citation Document updated, additional example sections are now marked as div.example
18       text-underline-position, change the value 'auto-pos' to 'auto'. Document updated
19       text-blink, clause about CSS2 user agents, what about CSS3 user agents Document updated: changed CSS2 to CSS3
20       Improve text-transform to support more capitalization transform Also commented by Bert Bos (see comment 14 ref), seen as a change beyond style
21       Properties index, missing words Document updated, meant to say initial and inherit values.
22       A lot of confusing, uninteresting information for us Latin script writers. UA style sheets aren't anymore useful without support :lang() Also commented by Bert Bos (see comment 14ref), the comment is noted but there is a price to pay to support international typography, furthermore as pointed by Bert, the initial value typically removes the need for an explicit :lang() in most cases.
23       Inconsequencies[sic] in referring to HTML/XHTML and their elements. Document updated (several occurrences)
24 (Bert Bos)

bert@w3.org

 www-style 25-Oct http://lists.w3.org/Archives/Public/www-style/2002Oct/0094.html

use white space="pre-line" instead of "pre-lines"

 Document updated
25 (Simon Montagu)

smontagu@netscape.com

 www-style 25-Oct http://lists.w3.org/Archives/Public/www-style/2002Oct/0095.html

In section 3.4, unicode-bidi, description of non-textual entities is not clear, clarify directionality of image

 Document updated, agreed that sentence can be omitted. But added reference to image sin the previous sentence. For 'rtl' direction, the image should be R (conforming to rule X6 of the Unicode algorithm version 3.0)
26 (Mark Davis)

mark.davis@jtcsv.com

 www-style 25-Oct http://lists.w3.org/Archives/Public/www-style/2002Oct/0084.html

line-break property, description of normal needs rewording to say allow a break between any character and a subsequent small katakana or small hiragana

 Document updated, agreed in principle, although the intent was that the 'any character' is itself a kana character, not just any character from the Unicode repertoire.
27       word-break-inside, clarify that 'hyphenate' does not imply the actual use of a visible hyphen glyph. Document updated, added a note that makes clear that a visible hyphen may not be displayed.
28       wrap-option, clarify the description of its values Document updated, 'hard-wrap' has been modified to 'no-wrap' (should make the case clearer), the 'soft-wrap' description has also been reworded.
29       line-feed-treatment, change concerning the note about Unicode Document updated, accepted
30       text-overflow-ellipsis, clarification on the values description Document updated: Apparently, Mark misunderstood the syntax, the syntax allows the uri to be used for the ellipsis-end or ellipsis-after. Changes introduced by comment 113 should clarify matters.
31       letter-spacing, disagree with statement about ligature Document updated, agreed with suggested new text and added a sentence about Arabic ligatures. Also see comment 114.
32 fantasai@escape.com www-style 30-Oct http://lists.w3.org/Archives/Public/www-style/2002Oct/0116.html

white-space control, names too long

 See comment 15
33       white-space="pre-line", replace by "linespecific" Value stays as amended by comment 24, because CSS 2.1 already uses pre-line
34 MINOBE Hiroyuki private email 06-Nov Why the Japanese emphasis mark style is not part of text-decoration? Document updated, the main reason it is no there is because it is already part of the 'font-emphasis' set of properties part of the draft CSS3 font module. However the text module will be edited to mention that point in the text decoration intro section.
35 Jeff Wishnie private email 12-Nov Fix a typo in white-space property description (...Setting a value on the 'white-space' property set the respective values....) Document updated by changing 'set' to 'sets'
36 (Christoph Päper)  christoph.paeper@tu-clausthal.de www-style 08-Nov http://lists.w3.org/Archives/Public/www-style/2002Nov/0020.html

Underline skipping

 See comment 1
37 fantasai@escape.com www-style 24-Nov http://lists.w3.org/Archives/Public/www-style/2002Nov/0148.html

Hanging indent

 Document updated, text-indent become a shorthand of text-first-indent: <length> | <percentage> and text-block-indent: none | auto. Major rewrite of the text indentation section.
38 (Etan Wexler)

ewexler@stickdog.com

 www-style 27-Nov http://lists.w3.org/Archives/Public/www-style/2002Nov/0153.html

2. Introduction, 1st paragraph, change 'character' to 'grapheme cluster'

 Document updated, replaced 'character' by 'letter' which is more ambiguous but also closer to reality. However the term 'grapheme cluster' is too specialized to appear in the opening paragraph of an introduction.
39       2. Introduction, change 'character' to 'glyph' as appropriate Document updated
40       2. Introduction, illustration, change 'Roman' to 'Latin' Document updated for all occurrences. Also added a new paragraph in the intro to describe usage of  the term 'Latin'.
41       3.5 text-script property, why not use 'script'? Was requested by many members of the WG to differentiate from the other usage of the term 'script'
42       3.5 Why quoting 'dominant' in 'dominant' script Document updated, quote replaced by emphasis
43       3.5 Remove "after any reordering...and bi-directionality" fragment Document updated
44       3.5 Issue with using 'Latin' as not being defined by ISO15924 Document updated, 'Latin' changed to 'LATIN', See comment 46
45       3.5, replace 'script definition' by 'script identifier' Document updated
46       3.5, Replace script reference from ISO15924 to Unicode UTR#24 Document updated, UTR#24 is now the reference, therefore 'Latin' (or more exactly LATIN) can be used as a possible computed value for 'text-script: auto' (see comment 44)
47       3.5, What is the lexical form of <script>? Document updated, now says 'identifier'
48       4.1, text-align property, text revision on <string> description Document updated
49       4.2, text-justify property, Why not merge with 'text-align' Comment retracted on 25-Dec after further discussion
50       4.2, What scripts are "Latin-based"? Document updated, replaced "Latin-based" by "Latin, Greek, Cyrillic" which express better the idea
51       4.2, description of the 'auto' value, use 'kashida-space' instead of 'text-kashida-space', or change property name. Document updated, replaced 'kashida-space' by 'text-kashida-space' (see comment 69)
52       4.2, description of the 'inter-word' value, rephrase Document updated as suggested
53       4.2, is justification expected at 'zero-width-space' and 'explicit-width-space'? Document updated, note added to say that zero-width-space is not a white-space and that justification occurs for explicit-width-space
54       4.2, in 'inter-word' example change 'characters' by 'glyphs'
 Document updated as suggested
55       4.2, in 'newspaper' value description, rephrase 'the threshold may be related...' Document updated as suggested
56       4.2, in 'newspaper' example change 'character' by 'glyph' Document updated as suggested
57       4.2, Rationale of 'In CSS3 a value of 'letter-spacing: 0' no longer inhibits spacing-out of words for justification?

Document slighted updated (added 'strictly' in front of 'inhibit') The main reason is that there may be no other alternative for justifying the line. The 'letter-spacing' property section describes this in more details
58       4.2, in 'distribute' description, Hindi is not a script group or script Document updated, replaced 'Hindi' by 'Devanagari group', as the intent was effectively to represent the baseline-connected Indic scripts.
59       4.2, in 'distribute' example change 'character' by 'glyph' Document updated as suggested
60       4.2, 'inter-cluster' value, rephrase and add a reference to UTR#29 Document updated as suggested with a slight change to narrow the grapheme cluster scope to Southeast Asian ones.
61       4.2, 'kashida' value, rephrase Document updated as suggested
62       4.2, table, change Latin to make a more inclusive term Document updated with a note concerning Latin that it covers more than just Latin script (as one of the alternate suggestion from Etan)
63       4.3, text-align-last, the 'auto' value should allow the user agent to justify the last line if it passes a threshold determined by the user agent Document updated, however because 'auto' has now being aligned with the value 'relative' used in XSL, this comment is not really applicable. In 'relative' mode the last line is never justified. See comment 8.
64       4.4, min-font-size and max-font-size, in this case <font-size> must be absolute, what would 'smaller' mean? Don't see the point, even a relative value will result in an absolute computed value. There is no major difference between <absolute-size> and <relative-size> apart the parent dependency.
65       4.4, capitalize 'auto' in both descriptions. Not applicable anymore, the value descriptions have been reformatted in a  standard 'dl' structure.
66       4.4, change to 'a value of '9px' is recommended for the Latin script Document updated, mostly as suggested, also see comment 11
67       4.5, text-justify-trim, rephrase 2nd sentence about blank space Document updated as suggested
68       4.5, change in last example description 'character' by 'glyph' Document updated as suggested
69       4.6, text-kashida-space, rename 'kashida-space' This property has been already implemented by a browser, so it seems just as well to keep as it is.
70       4.6, change description of 'kashida' effect and interaction with justification Document updated as [mostly] suggested
71       5, text-indent, no graceful way to achieve hanging Document updated, see comment 37
72       6.1, Types of line breaking, 3rd paragraph, change the sentence 'Finally, the Unicode character...' Document updated as suggested
73       6.1, why is 'strictness' quoted? Document updated, removed quotes
74       6.1, concerning "In addition, hyphenation is controlled by 'word-break-inside'.", how does this relate to the XSL hyphenation model. It is equivalent to the XSL 'hyphenate' property, however there is strong opposition in CSS to have 'false/true' value. Based on that it seemed more important to keep it part of the 'word-break-xx' family of properties
75       6.1, rephrase sentence about 'word-break' shorthand Document updated as suggested
76       6.2, 'line-break' property, change to 'kana' The relevant section has been rewritten following comment 26, so this is not relevant anymore.
77       6.2, simplify paragraph starting by "In Japanese, a set of line breaking..." Document updated as [mostly] suggested. Also made it a note instead of main text.
78       6.3, 'word-break-cjk', add "ideographs" after "Hangul and CJK" Document updated as suggested
79       6.3, what determines whether 'line-break' is obeyed? Document updated, 'line-break' is always obeyed for CJK, the fragment 'everywhere or' was removed from the 1st sentence describing the 'normal' value.
80       6,3, description of 'break-all' and 'keep-all', add 'ideographs' after "CJK" Document updated as suggested
81       6.3, 'word-break', change sentence "All word-break related..." as suggested Document updated as suggested
82       7. The focus on line feed (U+000A) as the only line break character is specific to XML, to the detriment of CSS. Document updated. A new paragraph is added in the introduction to indicate that other contexts may use different character. Furthermore the reference to 000A was removed in section 7 when mentioning 'line feed character' to make it more generic. It is nevertheless the case that the vast majority of CSS usage will be in XML context.
83       7.1, 'wrap-option', in 'emergency' value description, replace 'word-break' by its individual properties Document updated as suggested
84       7.2, White-space control, binding to XML 1.0 detrimental to CSS White-space control is not a simple subject and is better handled by an exact description, binding it to a version of XML makes it easier to implement. It does not prevent the section to be updated when XML 1.1 or future versions are created.
85       7.2, 2nd bullet of first list: "Line Feed characters are rendered..." change as suggested Document updated as suggested
86       7.2, 2nd bullet of first list, add a reference to UTR#24 after "property" Document updated with a link to the 'text-script' property which has already that link to UTR#24.
87       7.2, 3rd bullet of first list, change to "A sequence of white-space without any line feed characters is rendered as a single space character (U+0020) Document updated as suggested
88       7.2, 4th bullet of first list, change to "A sequence of white-space with one or more line feed is rendered as a single line feed character Document updated: The suggested change modifies entirely the meaning of the bullet which was part of the result of long discussion between Unicode and W3C experts and is not accepted. What is meant is that the sequence renders similarly to the rendering of a line feed, text made clearer.
89       7.2, 4th note, replace the 1st sentence by "In determining how to..." Document updated as suggested
90       7.2, 1st bullet of 2nd list, replace the 1st sentence by "If the character preceding and following..." Document updated as suggested
91       7.2, 4th bullet of 2nd list, replace the sentence by "If none of the conditions...." Document updated as suggested
92       7.2, 2nd paragraph after 2nd list, replace by "When white-space characters are collapsed..." Document updated as suggested
93       7.2, 'line-feed-treatment', 'auto' value description, replace first sentence by "The user agent either transforms each line..." Document updated as suggested, however because the mention 'for rendering purpose' is removed in the value description it is now added with emphasis in the general description.
94       7.2, line-feed-treatment, 'auto' value description, replace 2nd sentence by a reference to the previously defined algorithm and clean up the end of the sentence, which makes no sense Document updated, the intended sense of the sentence end is to specify that only inflow characters participate in the algorithm.
95       7.2, line-feed-treatment, 'ignore' value description, replace by new text Document updated as suggested
96       7.2, 'white-space-treatment', replace 2nd sentence of general description by new text Document updated as suggested with a small addition ('empty' in front of 'glyph')
97       7.2, 'white-space-treatment', 'ignore' value description, replace by new text Document updated as suggested
98       7.2, 'white-space-treatment', 'preserve' value description, replace by new text Document updated as suggested
99       7.2, 'all-space-treatment', 'preserve' value description, replace by new text Document updated but with tab rendering description removed, instead linked to a new 'white-space-processing' section, see comment #159
100       7.2, 'white-space', replace last sentence of general description by new text Document updated as suggested
101       7.3, Text overflow, first paragraph, replace 'text advance direction' by 'inline progression direction' Document updated as suggested
102       7.3, Text overflow, first paragraph, replace 2nd sentence by new text Document updated as suggested
103       7.3, Text overflow, 2nd paragraph, replace 2nd and 3rd sentence by a single new sentence Document updated as suggested
104       7.3, Text overflow, 2nd paragraph, next to last sentence, replace 'should appear' by 'are enabled' Document updated as suggested
105       7.3, Text overflow, 3rd paragraph, replace by new text Document updated as suggested
106       7.3, 'text-overflow-mode', apply only to block-level, what about inline-block? Document updated, added inline-block elements to the apply category to all block-level, probably need a new terminology to designate these elements.
107       7.3, 'text-overflow-mode', replace the first 2 sentences of the 'ellipsis' value description by new text Document updated as suggested
108       7.3, 'text-overflow-mode', clarify last sentence of the 'ellipsis' value description: "The insertions take place at the boundary of the last full glyph representation of a line of text." Document updated: the intent is to mean that the last letter preceding the hint is fully represented graphically. Sentence rewritten.
109       7.3, 'text-overflow-mode', replace description of the 'ellipsis-word' value description by new text Document updated as suggested
110       7.3, 'text-overflow-mode', 1st paragraph after value description, replace "The hint characters only replace.." by new text Document updated as suggested
111       7.3, 'text-overflow-mode', in example description, replace "will result on no ellipsis..." Document updated as suggested
112       7.3, 'text-overflow-mode', in example description, clarify last sentence: "In other words, the text-overflow-mode only affects..." Document updated: sentence removed.
113       7.3, 'text-overflow-ellipsis', change production to "<ellipsis>{1,2}, change the following prose as appropriate Document updated
114       8.1, 'letter-spacing', change text as suggested (many replacements to introduce grapheme clusters) Document updated as suggested with minor change due to comment 31.
115       8.2, 'word-spacing', description of 'normal' value, replace last sentence by new text Document updated as suggested
116       8.2, 'word-spacing', description of 'none' value, replace description by new text Not applicable, value deleted, see comment 5.
117 (Gabriele Fava) gabriele.fava@tiscalinet.it www-style 27 Nov http://lists.w3.org/Archives/Public/www-style/2002Nov/0154.html

Proposal for new text-underline-image, text-underline-fit and similar for line-through and overline

 These seem good input for further discussion, but due to lack of additional discussion and because some additional work has to be done on the inheritance aspect it did not seem to be a good idea to include them in the next revision.
118 fantasai@escape.com www-style 28 Nov http://lists.w3.org/Archives/Public/www-style/2002Nov/0155.html

3.1, Text layout introduction, consider formatting 3rd paragraph as a list, or add a comma after 'font'.

 Document updated, added the comma. Didn't do the list because the enumeration is not exhaustive.
119       3.1, Text layout introduction, clarify and combine 4th and 5th paragraph Document updated, this led to a major rewrite of the introduction to streamline the text.
120       3.1, Text layout introduction, rewrite first sentence of the paragraph mentioning CSS2 Document updated as [mostly] suggested
121       3.2, 'writing-mode', description of 'bt-lr', change direction property to 'ltr'. If the block progression is left to right then any horizontal script going down will be doing right to left on its side. See answer below
122       3.2, 'writing-mode', text 'An inline-level element that has a different writing-mode value than its parent becomes an inline-block element' is not correct Document updated as suggested
123       3.2, 'writing-mode', what 1, 2, 3 labeling, why 2 turns Document updated, 2 is not turned, but shows a different image in the vertical flows, could be better, but I don't have access to the original pictures.
124       3.2, 'writing-mode', add "In Japanese" to the description of "tate chu yoko" Document updated as suggested
125       3.2, 'writing-mode', ".hinv", is the "display: inline-block" necessary? Document updated, value removed
126       3.2, 'writing-mode', disabling line-break for the ".hinv" element, are inline-blocks constrained by the line-height? Not for some line-stacking strategy (see CSS3 line module)
127       3.2, 'direction', description of the 'direction' property, what does glyph orientation have to do with the direction of character flow It just means that you only apply any sort of embedding and direction override to characters that are laid out 'upright' in horizontal flow or 'on the side' in vertical flows. (Note that similar text exists for writing-mode)
128       3.2, 'direction', Please clarify 'modifying direction after writing-mode changes effectively the 'writing-mode' value to the opposite inline progression Document updated, was not intended, it is only true of course if they represent opposite inline progression direction.
129       3.3, 'glyph-orientation-vertical', in <angle> value description, replace text about 'conforming user agent' by new text. Document updated, however it is a clarification, not the substantive requested change. The CSS WG felt strongly that the conformance rule should stay as it is (in substance)
130       3.3, 'glyph-orientation-vertical', take out the enumeration list for conforming user agent statement Document updated, also see disposition to comment 129. It is true that the minimal conformance value (90deg) is not very useful for CJK characters, but it is sufficient for other characters that don't need to be kept upright. The new text includes 'auto' in the second list item and above which implies font and platform support (typical for a CJK support scenario).
131       3.3, 'glyph-orientation-vertical', description of <angle> value, make value independent of inline own orientation, make it related to block instead It is generally preferred to have glyph orientation related to inline orientation, and it also keeps the notation consistent with SVG which use the same properties and has no concept of 'block'.
132       3.3, 'glyph-orientation-vertical', description of 'auto' value, concerning 'Hebrew and Arabic text are also rotated 90 degree clockwise', rotated 90 degrees clockwise would be inappropriate for 'tb-lr' text. There is no such a thing as 'tb-lr' text, only elements have that property. Characters have an inherent inline directionality which can be superseded. The statement just indicates a default behavior for rtl characters in the 'auto' context: they behave as usual relatively to the inline orientation.
133       3.3, 'glyph-orientation-vertical', example, make clear that the Roman text is encased in an element Document updated, changed 'half-width Latin' to 'normal-width Latin' and added a note about 'full-width Latin' behavior.
134       3.3, 'glyph-orientation-horizontal', description of <angle>, wouldn't that result in upside down Arabic Document updated, very good catch, it was an error to try to use a right edge as a reference as you found out. The text has been changed to be better in sync with SVG.
135       3.3, 'glyph-orientation-horizontal', paragraph "The value of this property affects both the alignment and..." is confusing, nothing comparable in the vertical glyph orientation section. Document updated, there was in fact a similar text in the vertical glyph orientation section. But both were confusing, they are now both rewritten, using text much more similar to SVG 1.1.
136       3.4, 'unicode-bidi', in the example, why not use lang attribute instead of using 'hebrew' and 'english' element? Document updated, using the xml:lang attribute
137 fantasai@escape.com www-style 28-Nov http://lists.w3.org/Archives/Public/www-style/2002Nov/0156.html

3.5, 'script' property, how can 'auto' and <script> act differently on a run of non-dominant-script when 'auto' computes to a <script> and this computed value is what's inherited?

 Document updated, along with comment #151 it induces a complete change of the 'text-script' property and its effect on other text process (note that that makes this property different from XSL, but this is probably fine as the name is different anyway), see comments 41-47 and 151
138 (Christoph Päper)  christoph.paeper@tu-clausthal.de www-style 12-Dec http://lists.w3.org/Archives/Public/www-style/2002Dec/0019.html

11.1 'text-transform', add a 'title-case' value

 Document slightly updated by replacing 'first character' by 'first letter' in the description of the 'capitalize' value, which takes better account of grapheme clusters. Adding a new value would require more justification and sample cases.
139 fantasai@escape.com www-style 15-Dec http://lists.w3.org/Archives/Public/www-style/2002Dec/0061.html

7. Intro about line feed, An implementation may internally convert all newlines to linefeeds if it chooses to, but there's no reason for CSS to mandate this.
Why not use newline?

 See also comment 82, the intro was changed and the rest of that section as well to generalize the concept of 'linefeed'.
140 fantasai@escape.com www-style 15-Dec http://lists.w3.org/Archives/Public/www-style/2002Dec/0062.html

4.2, 'text-justify', clarify first paragraph about interaction with 'text-align'. Parenthesize the 2nd sentence.

 Document updated as disposition of comment #9 which also address this comment. 2nd sentence removed.
141       4.2, 'text-justify', intro, replace paragraph after list "The text-justification behavior..." by new text Document updated as [mostly] suggested, minor edit to link to the 'text-scrip' property.
142       4.2, 'text-justify', description of the 'newspaper' value, what is the meaning of the last 'This'? Document updated, the sentence starting with that 'This' is replaced by "Inter-letter spacing is not applied to Devanagari and other South Asian writing systems using baseline connectors."
143       4.2, 'text-justify', description of the 'newspaper' value, correct the reference to CSS3 Multi-column layout module Document updated as suggested
144       4.2, 'text-justify', description of the 'kashida' value, should mention dependency on 'text-kashida-space' Document updated as [mostly] suggested, added '%' to '0'
145       4.3, 'text-align-last', description of 'justify' value, what happens if the other lines are not justified Document updated, same point as comment #9
146       7.1, 'wrap-option', why is this not called 'wrap' or 'text-wrap'? Because XSL uses that name and we tend to use the same name when XSL precedes CSS for a similar property.
147       7.1, 'wrap-option', what about U+2028 and U+2029? Document updated, also see comment #82, the value (U+000A) has been removed to all references to linefeed characters. In addition a new note has been added in 7.2 to reflect that XML1.1 CR filters out U+2028 when normalizing line feed. And U+2029 is notably absent from the white-space set (also mentioned in the new note).
148       7.1, 'wrap-option', description of 'emergency', 'ending-edge' of the line is not defined. Document updated to say "ending edge of the line box" instead of "ending-edge of the line". The ending edge of the line box is the 'end side' of the line from a inline progression point of view. No need to redefine it.
149       7.1, 'wrap-option', description of 'emergency', what happens for fixed-width container if scrolling is allowed? Not sure to understand the point. The point of 'emergency' is to avoid text clipping. If scrolling is allowed, clipping won't really occur.
150       7.2, white-space control, concerning sentence about inserting '\A' string, what about inserting carriage return, CRLF sequences? These are all white-space characters with LF having the linefeed role. This is already covered by the spec.
151       7.2, white-space control, second item in bulleted list "The choice of the resulting character is conditioned by the script property of the characters preceding and following the line feed character." This implies that the choice of character is determined by the CSS script property's value for the element(s)? If so, how does it interact with 'auto' text-script? See answer below
152       7.2, white-space control, 4th item in bulleted list, why the use of 'similarly to'? What is the difference Document already updated per comment #88.
153       7.2, white-space control, 2nd paragraph after numbered list, what kind of style is applied to the collapsed set? Document updated, the expression 'text decoration' added in front of 'style'.
154       7.2, 'line-feed-treatment', description of 'auto' value, clarify last sentence, Document updated, sentence removed, didn't make much sense.
155       7.2, 'line-feed-treatment', description of 'ignore-if-after-linefeed', replace last sentence by new text Document updated as suggested
156       7.2,'line-feed-treatment', value names not optimal It is true that names are long and shorter names could be used. But there are also many people that favor consistency with XSL whenever possible.
157       7.2, 'white-space-treatment', property description, put part of first sentence in parentheses, fix typo ('determined' instead of 'determine') Document updated as suggested
158 fantasai@escape.com www-style 16-Dec http://lists.w3.org/Archives/Public/www-style/2002Dec/0069.html

7.2, 'white-space-treatment' and 'all-space-treatement' should be merged into a single property

 There are two issues with this: 1) the new property should also be described in term of the white-space behavior as the latter is to be a shorthand including this new property, 2) the two existing properties have more flexibility. It isn't clear that the additional flexibility is required (could be pathological cases), but still it seems risky to loose XSL-FO compatibility without further study.
159 fantasai@escape.com www-style 18-Dec http://lists.w3.org/Archives/Public/www-style/2002Dec/0149.html

7.2, White-space processing, synchronize with CSS2.1 description of white-space processing

 Document updated as [mostly] suggested. As a consequence the description of tab character processing was removed from 'all-space-treatment: preserve', and replaced by a link to the new section.
160       7.2, White-space processing, adding note "auto-transformed linefeeds are still break points" Don't agree with that. Although it gives a hint of line breaking opportunity, it is not an absolute requirement. There are many cases where a line breaking opportunity is not automatically created for a white-space character.
161 fantasai@escape.com www-style 18-Dec http://lists.w3.org/Archives/Public/www-style/2002Dec/0150.html

7.2, Change white-space property/value names

 In essence same comment as before (see comments #156, 158), same answer
162       7.2, 'line-feed-treatment', remove the value: 'ignore-if-after-linefeed' (aka no-double) This value was explicitly requested by a CSS WG member (Håkon Wium Lie) with a good rationale for it. (from memory as I can't find the message: two br elements separated by a block element with display:none, the 2 br should collapse into one)
163 fantasai@escape.com www-style 19-Dec http://lists.w3.org/Archives/Public/www-style/2002Dec/0159.html

9. Text decoration, underline, overline, and line-through don't seem to be defined anywhere.

 Their names are pretty self-explanatory, and the concepts well known. The spec shouldn't be a tutorial on typography (it is already verbose)
164       9. Text decoration, no good way to underline chemical formulas (underline would cut through the subscript) Document updated, see comment #1, there is now a way to skip 'glyph ink'.
165       9. Text decoration, please assign some syntax for ignoring ancestors' text decoration in CSS3 Out of scope for this module. Also see comment #192
166       9. Text decoration, 6th paragraph, make clear that empty and replaced descendant boxes really /don't/ break the text-decoration line. Document updated, see comment #192
167       9. Text decoration, 6th paragraph, fix 'affects', remove 'also' in last sentence, 7th paragraph: remove 'All these' Document updated as suggested
168       9. Text decoration, is averaging done by line, element, or per block? Document updated, typically per line
169       9. Text decoration, averaging, clarify role of vertical-align and size of superscript on averaging. Document updated, the root of the problem is that for many typography experts superscript and subscript are not a mix of baseline-shift and resizing but instead a font-style w/o resizing or baseline shifting. I don't want to go there at this point in the document. Just added a small sentence about baseline-shift in the note.
170       9.5, 'text-underline-position', reference CSS3 line, clarify EM box and 'after-baseline' Document updated, added a reference to CSS3 line, replace 'EM box' by references to the before-edge and after-edge baselines of the line box. See comment #200
171       9.5, 'text-underline-position', is 'auto-pos' specific to Japanese? Document updated, added reference to Korean as well (not the case for Chinese)
172 Jan Egil Kristiansen private email 08-Jan 7.2 White-space control, what to do with U+16EB which is a Runic space character. It is a 'space' character, ie it delimits line breaking opportunities, but it is rendered with a glyph. Unless a space character has to be part of the space-collapsing process, it does not have to be not part of the white-space set (many space characters are not). However it appears that the Unicode UTR#14 should be modified to change the classification of this character (currently 'AL') . Not so sure we should add a property just for this case concerning its end of line rendering peculiarity.
173 (Arthit Suriyawongkul)

Arthit.Suriyawongkul@Sun.COM

 www-style 16-Jan http://lists.w3.org/Archives/Public/www-style/2003Jan/0245.html

Line skipping over glyph

 See comment #1
174 (Etan Wexler) ewexler@stickdog.com www-style 30-Jan http://lists.w3.org/Archives/Public/www-style/2003Jan/0289.html

3.1. Text layout introduction, change 'Roman' to 'Latin'

 Document updated as suggested
175       3.2, 'writing-mode: lr-tb', change first sentence of value description Document updated as suggested
176       3.2, 'writing-mode: tb-lr', change first sentence of value description Document updated, inserted 'some East' in front of 'Asian scripts.
177       3.2, 'writing-mode: tb-lr', why is direction set to 'ltr'? Document updated, changed direction to 'rtl', this reflects the fact that the main usage for this writing mode is Mongolian with the top of character toward the 'before' edge.
178       3.2, 'writing-mode: bt-lr', why is direction set to 'rtl' Document updated, changed direction to 'ltr', derived from the change induced by comment 177.
179       3.2, example with 'hinv' class name, change to date Document updated as suggested
180       3.2, 'direction', first note, replace 'since columns don't exist in the document tree' by 'since column elements are never the ancestors of their constituent cell elements' Document updated as suggested
181       3.3 'glyph-orientation-vertical,' description of 'auto' value. It is the width property of the character that determines the orientation of the character's glyph. Document updated. The width is a tightly correlated but there are few exceptions (brackets, parenthesis, punctuation). The text mentioning exceptions now cites bracket symbols as well.
182       3.3, 'glyph-orientation-vertical', propose glyph-orientation-vertical-wide and glyph-orientation-vertical-narrow Because the correlation is not strict (see comment 181) and also because other text styling (XSL and SVG) don't do this, it does not seem wise at this point to split this property.
183       3.3.'glyph-orientation-vertical', 1st sentence of '<angle.' description, does the user agent rounding of the value angle affect the computed value Document updated, the computed value is not affected.
184       3.3, 'glyph-orientation-horizontal', why does it apply to only 'inline-elements'? Document updated, applies now to all elements.
185       4.5, 'text-justify-trim', change 'character' to 'glyph' in description. Document updated as suggested
186       5. 'text-indent', interaction with 'text-align: center' needs clarification Document updated. Indent is a minimum indent, but center still occurs within the whole line box width, just a new constraint.
187       7.1 'wrap-option', the focus on line feed characters (U+000A) is very tied to XML. Document updated as a result of comment #82 (you already made a similar comment there)
188       8.5 'text-kerning-threshold', value: auto and <length>, shouldn't length be <'font-size'> Document updated with <length> replaced by <'font-size'>
189       8.5, 'text-kerning-threshold', clarify threshold Document updated to clarify that at the threshold value (equal), pair kerning is active.
190       9. Text decoration, why all properties start by 'text-' Originally because of 'text-decoration', true that it could be removed, however the document has been this way now for a while
191       9.1, Text decoration introduction, replace 1st  and 4th paragraph by new text Document updated as suggested
192       9.1, Text decoration introduction, 6th paragraph, replace 2nd and 3rd sentence by new text clarifying the 'ignore' intent. Document updated as suggested
193       9.1, Text decoration introduction, 7th paragraph, why are these suggestions ('should') and not requirements ('must')? Document updated, 'should' replaced by 'must'.
194       9.1, Text decoration introduction, 8th paragraph, replace 1st sentence by new text Document updated as suggested
195       9.1, Text decoration introduction, Note, replace content Document updated as suggested
196       9.2, text decoration style, the value 'thick' is inadvisable. New properties to control line width Document updated as suggested (significant change, 3 new properties added)
197       9.3, text decoration color, 'auto' should compute to a <color>, and replace 'underline' in description of the 'auto' value by 'text decoration' Document updated, computed value is <color>, other updates as suggested
198       9.4, text decoration mode, is white-space the same for these properties as for other CSS constructs? What about U+3000 (ideographic space) Document updated, remove white-space denomination and replaced by a connection to the Unicode 'Zs' category which includes, among others, the ideographic space (U+3000)
199       9. Text decoration, introduce a text decoration skip Document updated, but only as extension to text decoration mode, was the way suggested by other comments and should suffice. See comment #1.
200       9. 5 text decoration, generalize text-underline-position to a text decoration position Document updated. At this point, this looks more than what should be done. Only underline have this feature of switching between alphabetic baseline to before edge depending on language. However the text-underline-position has been rewritten to be a subset of what is proposed.
201       9.5, text-blink, why not inherited? Because it is part of a shorthand which is not inheriting itself. And there is really no consensus to improve blink in CSS (against accessibility guidelines)
202       9.5, text-blink, no text about CSS3 user agent conformance clause Document updated to be in sync with CSS2.1 (i.e. user agent may simply not blink)
203       9.6, text decoration shorthand, additional text about constituent properties taking their initial values. Document updated as suggested
204       9.7, 'text-shadow' property should be deprecated Document updated, the note at the end mentions that there are better way to do this in SVG.
205       9.7, 'text-shadow', fix grammar to use a <shadow> value (2nd suggestion) and various fixes Document updated as suggested
206       9.7, 'text-shadow', why is it not inherited No reason to update the functionality of a deprecated (in effect) property
207       10.1 Line grid introduction, various text replacements Document updated as suggested
208       10.2, 'line-grid-mode', various text replacements Document [mostly] updated as suggested, the notable exception is that the algorithm to fill in strip into the grid is rewritten in a way closer to the original text than suggested.
209       10.3, 'line-grid-progression', initial value not defined Document updated, initial value is
210       10.3, 'line-grid-progression', clarify 1st sentence of description Document updated, written as "This property affects the inline-progression dimension of characters which are subject to the fixed advance width as determined by the 'line-grid-mode' property."
211       10.3, 'line-grid-progression', what is 'text-height' Document updated with placeholders to link to the CSS3 line module where the 'text-height' property is specified. The 'text-height' property controls the inline box block progression dimension and is typically content based.
212       10.3, 'line-grid-progression', example clarification Document updated as suggested
213       11.1, 'text-transform', add explicit link to the Unicode Document updated as suggested
214       11.2, 'hanging-punctuation', remove 'in the padding or margin area' from description in 1st paragraph Document updated as suggested
215       11.2, 'hanging-punctuation', if the hanging punctuation would be placed outside the margin area, is the punctuation still rendered Document updated, saying that the answer is no.
216       11.2, 'hanging-punctuation', clarification in example and note Document updated as suggested
217       11.3, 'text-combine', overhaul example in the 'letters' description Document updated, not an overhaul as suggested but a clarification of the current example.
218       11.3, 'text-combine', clarify "the combined lines appear inline with the surrounding text" Document updated, now 'text-combine' only apply to inline and inline-block elements.
219       11.3, 'text-combine', clarify description of multi-line box of combined text Document updated, description updated, a new example also added.
220       11.3, 'text-combine', overhaul example in the 'lines' description Document updated, not an overhaul as suggested but a clarification of the current example.
221       12, Properties index, clarify 'inherited: no (see prose)' for 'text-shadow' Document updated, removed the '(see prose)' fragment.
222       14, Profiles, various clarifications and suggestions Document updated as suggested
223       15, Glossary, replacement for Hangul, Kashida and Kana Document updated as suggested
224       15, Glossary, replacement for Kumimoji Document updated [mostly] as suggested, added a clarification that Kumimoji can also be encoded as it in Unicode.
225       15, Glossary, replacement for Logograph, Logogram Document updated as [mostly] suggested, used a more neutral stance for usage of the Han script.
226       Appendix A, vertical layout effect on CSS properties, clarify text about 'text-decoration' Document updated, removed that row as it is no longer correct.
227       Normative references, add ISO15924, UAX-11 and XML1.0 Document updated, added UTR-24 (instead of ISO15924), Unicode casing and XML1.0. But UAX-11 is not added as it is not strictly normative for glyph orientation, see comment #181
228       Other references, add 4 new references Typically we reference only other working groups documents standardized, or in the process to be. Individual contributions are not.
229 (Etan Wexler) ewexler@stickdog.com www-style 30-Jan http://lists.w3.org/Archives/Public/www-style/2003Jan/0290.html

Editorial comments

 Document updated as [mostly] suggested. The only ones that were not taken into account were the request to add 'abbr' to all acronyms. Few were added, but it isn't clear that at this stage of the document all of them should be noted that way. Furthermore, other modules do not follow [yet] that practice.

Answer to comment 121 concerning "writing-mode: bt-rl":

The direction of the block progression dimension has nothing to do with the direction of the inline progression. In fact in 'tb-lr', the inline progression is 'ltr', western characters go top to bottom on their side, and Hebrew/Arabic characters go bottom to top and the block direction is 'top' to 'bottom'. If you apply 'direction=rtl' to that element on top of the current writing-mode, the inherent directionality isn't changed, but all block properties that are related to block inline progression change behavior as in a 'rtl' block. When you apply direction 'rtl' to a 'tb-lr' block, the only perceived change is the alignment, characters direction and ordering are still governed by the standard Unicode algorithm.

The 'writing-mode:bt-lr' is just there to capture the scenario mentioned above, that is the typically layout used in vertical ideographic mode in East Asian on which a change of direction from 'ltr' to 'rtl' is applied.

Answer to comment 151 concerning "text-script: auto"

This comment along with comment #137 were key in finding a major issue with the 'text-script' property as it was originally specified in the Last Call version of the document. In it, 'text-script' was always computing to an explicit and unique script value for the whole element, even when it was set to 'auto'. This was in contradiction with many other parts of the specification which implied that the script value of each character (not the script of the element) was considered for process like text justification and white space processing. Part of the issue originates from the fact that 'text-script' originates from the XSL-FO 'script' property which can be applied to fo:character, construct which doesn't exist in CSS. In addition, the current specification of 'text-script' made its inheritance unmanageable.

The solution is to maintain 'auto' as a computed value for 'text-script', and introduce more formally the concept of a dominant script for an element. When 'text-script' is set to auto, all processes that require a script value for each character (such as white-space handling, justification) can just use the inherent script value of each Unicode character as determined by the UTR24: Script names. All processes that may require a script value for the element (such as alignment) use the dominant script of the element which is the first character descendant which has an unambiguous script value. This new behavior can be inherited without any issues even if it requires a bit more explanation wherever the 'text-script' and another CSS property interact. It is also noted that, unlike what was said before, line-breaking and word-breaking are not formally related to the script value of characters.