CSS2.1 Second Last Call Issues List =================================== This list covers issues raised on the Last Call Working Draft http://www.w3.org/TR/2005/WD-CSS21-20050613/ and the interim Working Draft http://www.w3.org/TR/2006/WD-CSS21-20060411/ TO RESOLVE AN ISSUE add the line "Resolution:" followed by the description of the resolution, and then a line on its own with either one of "=Bert= Edit.", "=howcome= Edit.", and "=Tantek= Edit.", if an edit is to be made, or just the line "Issue closed." if the issue is closed. See other issues for examples. Editors: 1-about = Bert, 2-intro = howcome, 3-conformance = howcome, 4-syndata = Tantek, 5-selector = Bert, 6-cascade = howcome, 7-media = howcome, 8-box = Bert, 9-visuren = Tantek, 10-visudet = Bert, 11-visufx = Tantek, 12-generate = howcome, 13-page = howcome, 14-colors = Tantek, 15-fonts = Tantek, 16-text = Tantek, 17-tables = Bert, 18-ui = Tantek, A-aural = Bert, C-changes = Bert, D-sample = howcome, G-grammar = Bert, F-propix = auto OUTSTANDING ISSUES: Hixie has 2 actions David has 1 action ------------------------------------------------------------------------ Issue 1. URI: http://lists.w3.org/Archives/Public/www-style/2005Jun/0034.html URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2004JulSep/0062 Description: img:before not defined Resolution: img:before explicitly not defined in CSS2.1 because we are looking for implementation and author feedback and will define this in more detail in CSS3. We never actually put our resolution in the spec, though. Add the following sentence to the end of section 12.1 "The :before and :after pseudo-elements": This specification does not fully define the interaction of :before and :after with replaced elements (such as IMG in HTML). This will be defined in more detail in CSS3. Issue closed. ------------------------------------------------------------------------ Issue 2. URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0157.html Description: > Hyatt wrote: > > I definitely think CSS 2.1 should not be dictating the precise position of > > the tab stops. I would prefer it be reworded as a guideline/advisory. How > > about changing the text at > > http://www.w3.org/Style/Group/css2-src/text.html#q8 > > > > to: > > > > "All tabs (U+0009) are rendered as a horizontal shift that lines up the > > start edge of the next glyph with the next tab stop. Tab stops occur at > > points determined by the user agent. One possible algorithm for user agents > > to use when determining tab stops is at multiples of 8 times the width of a > > space (U+0020) rendered in the block's font from the block's starting > > content edge." Resolution: No change. Issue closed. ------------------------------------------------------------------------ Issue 3. URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0165.html Description: Unclear that word-spacing applies to NBSP characters. Proposed changes (text.html, section "Letter and word spacing"): change "When white space is preserved, e.g. with 'white-space:pre', all space characters are affected by word-spacing." to "Word spacing affects each space (U+0020), non-breaking space (U+00A0), and ideographic space (U+3000) left in the text after the white space processing rules have been applied." Resolution: Apply change described above. Issue closed. ------------------------------------------------------------------------ Issue 4. URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0175.html Description: I was just looking at the HTML diffs, and noticed that the computed value for 'content' probably needs to reflect what is stated in the definition of the 'normal' value: that a specified value of 'normal' computes to 'none' for pseudo-elements: http://www.w3.org/TR/2005/WD-CSS21-20050613/generate.html#content (Should it also say that the computed value for elements is always normal? Are we consistent about how we describe computed values in cases where a property doesn't apply?) Proposal: Change the 'computed value' line to: On elements, always computes to 'normal'. On :before and :after, if 'normal' is specified, computes to 'none'. Otherwise, for URI values, the absolute URI; for attr() values, the resulting string; for other keywords, as specified. Resolution: Apply change described above. Issue closed. ------------------------------------------------------------------------ Issue 5. URI: http://weblogs.mozillazine.org/roc/archives/2005/06/displayinline_a.html Description: Authors use 'display:inline' on elements to make inline tables, which works in IE but breaks in compliant UAs. Proposal: Add the following statement in 17.2.1 in points 2, 3, and 4 after the sentences ending in "P and T": If P is an 'inline' box, then the generated box must be an 'inline-table' box instead of a 'table' box. Resolution: Accept proposal. Issue closed. ------------------------------------------------------------------------ Issue 6. Description: (o173071) The grammar definition of an identifier differs from the prose definition. The prose, in fact, has two separate definitions for different things. Resolution: Issue became moot due to later resolution of issue 167. Issue closed. ------------------------------------------------------------------------ Issue 7. Description: The following note is repeated twice in the current draft. (Section 5.8.3) # Note: If an element has multiple class attributes, their values must # be concatenated with spaces between the values before searching for # the class. As of this time the working group is not aware of any # manner in which this situation can be reached, however, so this # behavior is explicitly non-normative in this specification. At least a bazillion people reported this duplicate paragraph. Resolution: Assumed editorial. Issue closed. ------------------------------------------------------------------------ Issue 8. URI: http://www.w3.org/mid/Pine.GSO.3.96.1050615183256.27687C-100000@rmi-sun.rmi.acnet.ge Description: Request for CSS2.1 to address namespaced selectors. Resolution: Rejected, too late. Proposed text already in CR. Issue closed. ------------------------------------------------------------------------ Issue 9. URI: http://www.w3.org/mid/Pine.GSO.3.96.1050615185433.27687D-100000@rmi-sun.rmi.acnet.ge Description: Interaction of lists and counters. Resolution: Response: http://www.w3.org/mid/20050615164224.GA29310@ridley.dbaron.org Issue closed. ------------------------------------------------------------------------ Issue 10. URI: http://www.w3.org/mid/42B07254.6039.F863E@localhost URI: http://www.w3.org/mid/42FA474B.6855.268DB0@localhost Response: http://www.w3.org/mid/200509131657.33583.bert@w3.org URI: http://www.w3.org/mid/43296F0E.3000507@comhem.se Response: http://lists.w3.org/Archives/Public/www-style/2005Sep/0135.html URI: http://lists.w3.org/Archives/Public/www-style/2005Sep/0178.html Description: Discussion about the replaced element intrinsic sizing rules, concluding with the following question: "does the table under 'max-width' still work when the replaced elements use the intrinsic ratio?" Resolution: Replace "In this table, w and h stand for the intrinsic width and height, respectively." with: "In this table w and h stand for the results of the width and height computations ignoring the 'min-width', 'min-height', 'max-width' and 'max-height' properties. Normally these are the intrinsic width and height, but they may not be in the case of replaced elements with intrinsic ratios." Issue closed. ------------------------------------------------------------------------ Issue 11. Description: It was pointed out in [1] that there is an error in the first example in section 12.4 [2]. The simplest fix is to add a style rule to the example: body { counter-reset: chapter; } /* create a chapter counter scope */ so that the implicit counter creation rules don't create a separate counter for each header. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=288946 [2] http://www.w3.org/TR/2005/WD-CSS21-20050613/generate.html#counters Resolution: Make edit as suggested. Issue closed. ------------------------------------------------------------------------ Issue 12. URI: http://www.w3.org/mid/Pine.LNX.4.61.0506181311570.32467@tuomi.oulu.fi Description: http://www.w3.org/TR/CSS21/conform.html#x22 | For example, table-column-group elements cannot have borders around | them, so the border properties must be ignored. As table-column-group can have borders around them in collapsed border Better example might be: table-column elements can't affect to font of column, so the font properties must be ignored. Resolution: Make edit as suggested. Issue closed. ------------------------------------------------------------------------ Issue 13. URI: http://www.w3.org/mid/op.sskju0zvk4suho@briann.wlfdle.phub.net.cable.rogers.com Description: The note near the end of the section is not closed. This has the unfortunate side-effect of propagating the element's green styling to the rest of the document in some agents. :( Resolution: Fix markup. Issue closed. ------------------------------------------------------------------------ Issue 14. URI: http://www.w3.org/mid/20050623172020.GA5947@ridley.dbaron.org Description: On Thursday 2005-06-23 21:05 +1000, Michael Day wrote: > Can pseudo-elements that are not generated still affect counters? > > For example: > > h1::before { > content: normal; > counter-increment: heading; > } I think not. I thought 12.4.3 said so explicitly, but apparently it doesn't. It probably should. Resolution: Make edit as suggested. Issue closed. ------------------------------------------------------------------------ Issue 15. URI: http://www.w3.org/mid/ef5d0f2f05062802487bdc96da@mail.gmail.com Description: 'Implementors are urged to implement these features, or correct bugs in their implementations, if they wish to see thsse features remain in this specification.' 'thsse' should be 'these', I believe. Resolution: Fix typo. Issue closed. ------------------------------------------------------------------------ Issue 16. URI: http://www.w3.org/mid/42C69AC2.4050504@lachy.id.au Description: While attempting to greatly improve upon some CSS tests I had written previously for the border collapse conflict resolution algorithm, I've come across an issue in the spec. Step 4 of the conflict resolution algorithm states [1]: 4. If border styles differ only in color, then a style set on a cell wins over one on a row, which wins over a row group, column, column group and, lastly, table. It is undefined which color is used when two elements of the same type disagree. It needs to be defined which border of two elements of the same type takes precedence when they only differ by colour. Both Firefox and Opera take a completely different approach, yet because the behaviour is undefined, both are correct. See the test case [2]. Firefox seems to apply the border colour from the cell above or the left, while Opera seems to apply the border colour from the cell below or to the right. I think it makes more sense the way Firefox implements it, but either way, I think it should be defined. [1] http://www.w3.org/TR/CSS21/tables.html#border-conflict-resolution [2] http://lachy.id.au/dev/css/tests/bordercollapse/012 Testcase demo: http://junkyard.damowmow.com/207 Resolution: In 17.6.2.1: Change 4. If border styles differ only in color, then a style set on a cell wins over one on a row, which wins over a row group, column, column group and, lastly, table. It is undefined which color is used when two elements of the same type disagree. ...to: 4. If border styles differ only in color, then a style set on a cell wins over one on a row, which wins over a row group, column, column group and, lastly, table. When two elements of the same type conflict, then the one further to the left (if the table's 'direction' is 'ltr'; right, if it is 'rtl') and further to the top wins. Issue closed. ------------------------------------------------------------------------ Issue 17. URI: http://www.w3.org/mid/Pine.LNX.4.61.0507022020550.11931@dhalsim.dreamhost.com Description: 9.4.2, para 4: > "If that property has the value 'justify', the user agent may stretch > the inline boxes as well." > > Does UA allowed to stretch *all* inline boxes (including inline blocks) ? Resolution: inline-blocks and inline-tables and their contents shouldn't be affected here, only actual display:inlines. In 9.4.2, change "the user agent may stretch the inline boxes as well." to "the user agent may stretch spaces and words in display:inline boxes as well." In 16.2, change "the UA may stretch the inline boxes in addition to adjusting their positions" to "this property specifies that the inline boxes are to be made flush with both sides of the block". Further discussion at: http://www.w3.org/mid/43271016.6010701@inkedblade.net http://www.w3.org/mid/200509141456.08425.bert@w3.org ...which may suggest better text. Issue closed. ------------------------------------------------------------------------ Issue 18. URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0034.html URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0038.html URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0039.html Description: Proposal to use 'padding edge' not 'content edge' in 10.1, for inlines. Resolution: Specifically, the three occurances of "content" in 10.1 list item 4 should be changed to "padding" (and then change "right edges" to "right padding edges" in the second sub-list item). Issue closed. ------------------------------------------------------------------------ Issue 19. URI: http://www.w3.org/mid/8E265F97-14C9-44D0-9BF5-37D4E8377447@w3.org Response: http://lists.w3.org/Archives/Public/www-style/2005Jul/0329.html Description: Versioning information story. Resolution: Assumed by Bert, Ian: Do nothing as per Sophia F2F. Issue closed. ------------------------------------------------------------------------ Issue 20. URI: http://www.w3.org/mid/A0700B54-BD9F-4C0A-BDE0-D5C3A64B707C@w3.org Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0171.html Description: Request for implementation report of CSS2 in terms of CSS2.1. Resolution: Assumed by Ian that this would be WAY too much work and that we don't want to do it. Asked Karl if Appendix C is enough. Issue closed. ------------------------------------------------------------------------ Issue 21. URI: http://www.w3.org/mid/20050712214143.GB671@ridley.dbaron.org Description: I just noticed one more change that I think we need to make in section 10.4. We should change the sentence: However, for replaced elements with both 'width' and 'height' specified as 'auto', the algorithm is as follows: to be: However, for replaced elements with an intrinsic ratio and both 'width' and 'height' specified as 'auto', the algorithm is as follows: because I don't think these rules are intended to apply to IFRAMEs or OBJECTs that embed HTML documents. (It was clearer that they didn't make sense before the change we agreed to this morning that made them work for the intrinsic-ratio-but-no-intrinsic-size case.) -David Resolution: Agreed. Issue closed. ------------------------------------------------------------------------ Issue 22. URI: http://www.w3.org/mid/EDECFB54-2989-465B-AA38-088DD3F5011C@w3.org Description: It is said that [[[ Conforming user agents must correctly map to Unicode all characters in any character encodings that they recognize (or they must behave as if they did). ]]] - http://www.w3.org/TR/2005/WD-CSS21-20050613/syndata.html The way you define references is very important. The sentence is a bit vague here with regards to Unicode. See http://www.w3.org/TR/qaframe-spec/#ref-define-practice For unicode specifically, the specification Charmod explains how to reference Unicode. http://www.w3.org/TR/2005/REC-charmod-20050215/#sec-RefUnicode -Karl Resolution: Editorial. For Unicode, resolution is to refer to latest (dynamic). Issue closed. ------------------------------------------------------------------------ Issue 23. URI: http://www.w3.org/mid/AAAB784B-9C78-4C1C-9403-092E7BA57916@w3.org URI: http://www.w3.org/mid/i51ekacjbi2.wl@w3.mag.keio.ac.jp URI: http://www.w3.org/mid/9750588.1121456022734.JavaMail.servlet@kundenserver URI: http://www.w3.org/mid/op.svanzwqtsmjzpq@r600 Description: Request to update HTML4.0 references to HTML4.01. Resolution: Done. Issue closed. ------------------------------------------------------------------------ Issue 24. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > Use of terms: "version" vs. "level" vs. "revision" > > For me, the use of terms "version" and "level" is confusing, especially > since "version" is not defined in the specification. Is "version" to > mean ("level"|"revision")? Resolution: Change "any version of CSS" to "any level of CSS". syndata: 4.1, 4.1.4 Change "future version of CSS" to "future update of CSS". syndata: 4.1, 4.1.7, 4.2 (twice) media: 7.3 visfx: 11.1.2 tables: 17.5, 17.5.2, 17.5.3 Change "a previous version of this specification" to "a previous revision of this specification". visfx: 11.1.2 Change "updated version" to "updated revision". changes: C Issue closed. ------------------------------------------------------------------------ Issue 25. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > Missing: List of special CSS characters > > The specification refers to "special CSS characters" that e.g. need > escaping. I haven't found a list of these special characters. Have these > to be inferred from parsing context and the core grammar? > (third bullet) Resolution: You have to derive it. In practice you don't need it; as an implementor you just implement the grammar and make "\" skip past the part of the code that looks for special characters. As an author you just stick a "\" in when things don't work. Issue closed. ------------------------------------------------------------------------ Issue 26. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > Missing: Resolving escapes > > Though probably not absolutely required, it would be helpful to have it > explained that character escapes in tokens must be resolved before > performing any (mostly: comparison-) operation, so that i.e. an > identifier written as "te\st" is considered the same as if it had been > written as "test". This would complement the already existing note that > pre-processors must not resolve quotes. > (third bullet) Resolution: At the end of 4.1.3, add a sentence saying something like "The identifier "te\st" is exactly the same identifier as "test".". Issue closed. ------------------------------------------------------------------------ Issue 27. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > Use of terms: "ISO 10646" vs. "Unicode" > > In most places in chapter 4, ISO 10646 is referenced for character set. > However, in two places the term "Unicode" is used (4.3.7 and 4.4.1). For > consistency reasons, ISO 10646 should be used in those two places instead. > > Resolution: Editorial. Issue closed. ------------------------------------------------------------------------ Issue 28. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > Inconsistent spelling > > Throughout chapter 4, spelling of the following terms is changes randomly: > > style sheet <--> stylesheet > CSS2.1 <--> CSS 2.1 > declaration block <--> declaration-block > > I suggest picking one and sticking with it. Resolution: "style sheet" two words, "declaration block" two words, "CSS 2.1" with a space. Be careful not to change the grammar token "stylesheet"!! Issue closed. =Hixie= reverify ------------------------------------------------------------------------ Issue 29. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > Concern: starting identifiers with hyphens > > I have voiced my concerns and objection to allowing identifiers to start > with an unquoted hyphen vehemently in the past and will leave it > therefore at it. Resolution: Ok then... Issue closed. ------------------------------------------------------------------------ Issue 30. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > All levels of CSS -- level 1, level 2, and any future levels -- use the > same core syntax. This allows UAs to parse (though not completely > understand) style sheets written in levels of CSS that didn't exist at > the time the UAs were created. > ]]] > and > [[[ > The list of tokens for CSS2.1 is as follows. > ]]] - > > If all levels of CSS use this *same* core syntax, then why is it only the > list of tokens for *CSS 2.1* and not all versions of CSS? Remove the > reference to CSS 2.1 in the second sentence. Resolution: Change "The list of tokens for CSS 2.1 is as follows." to "The list of tokens for CSS is as follows." Issue closed. ------------------------------------------------------------------------ Issue 31. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > Appendix G describes a more restrictive grammar that is closer to the CSS > level 2 language. > ]]] - > > I have three issues with the wording of this sentence: > > (1) The reader is aware that he is reading the description for the core > syntax. This reference has potential making him wonder whether what he > reads is something normative or is not "the real" grammar he has to observe. > > Suggestion: Remove this reference to Appendix G completely. Resolution: In section 4.1.1 Tokenization, at the end of the paragraph starting "Below is the core syntax for CSS", add "Parts of style sheets that can be parsed according to this grammar but not according to the grammar in Appendix G are among the parts that will be ignored according to the rules for handling parsing errors." Issue closed. ------------------------------------------------------------------------ Issue 32. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > Appendix G describes a more restrictive grammar that is closer to the CSS > level 2 language. > ]]] - > > I have three issues with the wording of this sentence: > > (2) When Appendix G describes a more restrictive grammar that is closer > to CSS level 2 language (or isn't it CSS 2.1 ?), but still not CSS level > 2, then why bother to specify it at all? Just describe the constructs in > detail and unambigously in the description of the various parts (sections > 4.1.2 ff.) - which you have done already - and don't bother to give a > grammar at all. Why? Giving this grammar may lead implementors into > believing they can use that grammar as-is for their implementation, when > in fact they can't due to the many restrictions and error handling > requirements which are not implementable by throwing the grammar at a > scanner/parser generator. They might waste their time in doing this, just > to find out some time later that a generated parser using the > normative(!) grammar will not be easily forced into being a conforming > parser, and that they would have been way better off in implementing the > spec as described verbally (they'd have probably written a recursive > descent parser manually right from the beginning, thereby having saved > several hours of work.) > > Suggestion: Remove this reference to Appendix G completely. Resolution: Resolved by issue 31. Issue closed. ------------------------------------------------------------------------ Issue 33. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > Appendix G describes a more restrictive grammar that is closer to the CSS > level 2 language. > ]]] - > > I have three issues with the wording of this sentence: > > (3) Finally, when you want to give a grammar that is > "closer to the CSS level 2 language", just how close is it? As far as it > gets? As far as you managed? Why didn't you specify some more grammars > that are "reasonably close", "a little closer" and "way close" as well? > > Suggestion: Remove this reference to Appendix G completely. Resolution: Resolved by issue 31. Issue closed. ------------------------------------------------------------------------ Issue 34. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > The meaning of input that cannot be tokenized or parsed is undefined in > CSS2.1. > ]]] - > > I suggest removing the reference to CSS 2.1 here. This is the section on > core grammar valid for all levels of CSS: there should not be a reference > to the current level. When you need to apply restrictions to the core > grammar, make it a specific section, "CSS 2.1 Grammar restrictions". This > way, when there are several levels of CSS available to be implemented, > readers of the spec have a chance to easily compare restrictions between > levels they need to implement without having to browse through the > otherwise identical descriptions of the core grammar, which - due to its > nature - should never change in the future. Resolution: No change. I think this should stay the same. I think me may define this in future versions. I agree. It can change as along as it is a backwards compatible change. No change. Issue closed. ------------------------------------------------------------------------ Issue 35. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0141.html Description: > Suggestion of sectioning: > - 4.1 CSS Core grammar: consists essentially of current 4.1.1 with > references to CSS 2.1 removed. > - 4.2 Grammar of CSS 2.1: consists of 4.2.1 with restrictions to the core > grammar now in 4.1.1, and continues with 4.1.2, ... relabelled to 4.2.2, ... > > Of course, it would even be better to separate general constructs' > descriptions which will not change (e.g. "Statement", "At-rule", ...) > into the core grammar description, and then add restrictions for CSS 2.1 > in the CSS 2.1 grammar's section. It makes it much easier for > implementors to decide on factorings and identifying features to be put > into the parser core and which should go into configurable CSS profile > support. Resolution: We will consider this for CSS3, but it doesn't seem appropriate for CSS2.1 right now (not a change of functionality, so too late at this time to change 2.1). Issue closed. ------------------------------------------------------------------------ Issue 36. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > Keywords have the form of identifiers. > ]]] - > > The term "identifiers" is nowhere clearly visibly defined in the > specification, though a link later in the document suggests that this > should be the second item in the list in 4.1.3. Please add a link here > since it is a forward reference to the definition. Resolution: Add link in 4.1.2 to make this clearer. Issue closed. ------------------------------------------------------------------------ Issue 37. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > Keywords and property names,... > ]]] - > > The term "property names" is a *forward* reference to its definition in > 4.1.8 (although there, only *property* is actually defined, but not > *property name*). Suggesting to make it link to that section. Resolution: Add link. Issue closed. ------------------------------------------------------------------------ Issue 38. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > In CSS2.1, identifiers may begin with '-' (dash) or '_' (underscore). > ]]] - > > According to the core grammar, identifiers (assuming this being IDENT > tokens) may start with these characters in *all* versions and levels of > CSS, not just CSS 2.1 . I guess you mean to say that it is in the > *keywords* and *property names* that CSS 2.1 allows them for use as > vendor-specific extensions designators, but nowhere else. Resolution: Drop "2.1" and make it just "In CSS, identifiers..." Issue closed. ------------------------------------------------------------------------ Issue 39. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > An initial dash or underscore is guaranteed never to be used in a > property or keyword... > ]]] - > > Is "property" a synonym for "property name", or are these two different > things? If it is the same (and it seems to be when reading 4.1.8), why is > there the term "property name" used earlier in 4.1.2.1? Looks like it > should be "property" only. Resolution: Answer is "yes", "property" and "property name" mean the same thing. Change "property" to "property name" in two places in 4.1.8: in first paragraph and in first paragraph after example. Issue closed. ------------------------------------------------------------------------ Issue 40. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > ...consists of a list of statements (see the grammar above). > ]]] - > > Suggestion: Remove "(see the grammar above)" and link "statements" to the > respective line in the core grammar. Resolution: Link "grammar" to the grammar, but leave the bit in parentheses. Issue closed. ------------------------------------------------------------------------ Issue 41. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > In this specification, the expressions "immediately before" or > "immediately after" mean with no intervening whitespace or comments. > ]]] - > > This definition is rather buried, especially since it is not at 4.1- > level, but can be construed to be part of 4.1.4-level. Move this up to > 4.1, Syntax, introduction. Resolution: Editorial, but move it to 4.1. Issue closed. ------------------------------------------------------------------------ Issue 42. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > ...after any valid rule other than an @charset or an @import rule. > ]]] - > > Inconsistent usage of the term "rule" (first occurrence in sentence > above): Later in 4.1.7, "rule" is defined to be a synonym for "rule set". > Neither @charset nor @import are a rule set, however; they're at-rules. > So the first occurrence of "rule" in the above should be changed to > "statement". Resolution: Do exactly what he asks for (in 4.1.5). Issue closed. ------------------------------------------------------------------------ Issue 43. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > ...to achieve the effect of only importing a style sheet for 'print' media, > use the @import with media syntax... > ]]] - > > Should probably be: "...use the @import rule with media syntax..." ("rule" added). Resolution: Do exactly what he asks for. Issue closed. ------------------------------------------------------------------------ Issue 44. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > In between there may be any characters... > ]]] - > > Shouldn't this better read: "In between there may be any tokens..."? If > not, what's the rationale behind using "characters"? Changing to "tokens" > in the above would also mean you could drop "Single (') and double quotes > (") must also occur in matching pairs, and characters between them are > parsed as a string. See Tokenization above for the definition of a > string." completely. Honestly, I do not understand why this description > is falling back onto character level when there is a generally valid > tokenization definition given already that is also universally valid for > every style sheet. Resolution: Change "characters" to "tokens" in that sentence but do nothing else. (4.1.6) Issue closed. ------------------------------------------------------------------------ Issue 45. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > ...followed by a declaration block. A declaration-block... > ]]] - > > Use consistent hyphenation for declaration block (i.e., none). Resolution: See issue 28. Issue closed. ------------------------------------------------------------------------ Issue 46. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > ...also called a {}-block in the following text... > ]]] - > > I think it's unfortunate to use that abbreviation. When reading aloud, > one always must remember how to pronounce "{}-block": Is it "braces- > block"...? Or what was it again...? Well, it's a "declaration block", so > why not keep using that as written? Same goes with the rule set > abbreviation: Why introduce it? It makes communication more fragile > between different people when there is a synonym to remember for each > basic concept. Resolution: Replace "{}-block" with "declaration block" throughout that section (used twice), and remove the "also called a" part that introduces the term in the first place. (4.1.7) Issue closed. ------------------------------------------------------------------------ Issue 47. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > Because of the way selectors work, multiple declarations for the same > selector may be organized into semicolon (;) separated groups. > ]]] - > > I think when turning around the above sentence, it is more precise: > > "A semicolon (;) separated list of declarations in the declaration block > for a specific selector may be used as a shorthand for multiple single- > declaration rule sets with the same selector in the same order. > > Thus, the following rule > > h1 { > font-weight: bold; > font-size: 12px; > line-height: 14px; > font-family: Helvetica; > font-variant: normal; > font-style: normal > } > > is equivalent to > > h1 { font-weight: bold } > h1 { font-size: 12px } > h1 { line-height: 14px } > h1 { font-family: Helvetica } > h1 { font-variant: normal } > h1 { font-style: normal }" Resolution: Leave as is. We don't agree that this clarifies anything much. Issue closed. ------------------------------------------------------------------------ Issue 48. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > A property is an identifier. Any character may occur in the value. ... > ]]] - > > For better readability and clear separation of descriptions' subjects, > make this into two paragraphs as follows: > > "A property is an identifier. > > Any character may occur in a property's value. ..." > > Again, I do not understand why you fall back onto character level > description here when a universal tokenization is available (see above). Resolution: Don't split paragraph but change "character" to "token". Issue closed. ------------------------------------------------------------------------ Issue 49. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > ...but in any case, values are built from identifiers, strings, numbers, > lengths, percentages, URIs, and colors. > ]]] - > > This is incorrect as it is written. Even the preceding paragraph says > that "any character may occur in the value". > > An example: The value > > counters(item, ".") > > additionally contains the comma (',', a DELIM) and parentheses. > Suggestion is to drop the above part of the sentence completely, as it > does not convey any essential information at that point. Resolution: Change "and colors" to "colors, etc.". Issue closed. ------------------------------------------------------------------------ Issue 50. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > A user agent must ignore a declaration with an invalid property name..." > ]]] > and later > [[[ > The CSS2.1 parser will ignore these declarations... > ]]] - > > It's unclear whether the *parser* must ignore the declarations or the > *user agent* must ignore it. This becomes important when using SAC: > Should the property be reported or not? Again, due to the structuring of > this chapter 4, it is extremely hard to separate the required behaviour > of a general CSS parser from the required behaviour of a CSS parser that > has been configured to use the CSS 2.1 profile. Resolution: That's SAC's problem. We don't really distinguish between "parser" and "UA" in this spec, that's up to the SAC spec to define. Issue closed. ------------------------------------------------------------------------ Issue 51. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > A user agent must ignore a declaration with an invalid property name... > ]]] - > > What's the definition of "invalid name" here? Invalid per the CSS 2.1 > profile? In this case, it should probably better read "illegal property > name in CSS 2.1", as "illegal" is a well-defined term in the specification. > > Or is it meant to be invalid per the definition for the "identifier" type > (e.g. as in { 123: 12pt })? > > Also, how does the term "invalid" here relate to the term "unknown" in > 4.2, "Unknown properties"? Resolution: We don't think we should change anything. We think it's fine as it is. It seems clear enough what we mean here. Issue closed. ------------------------------------------------------------------------ Issue 52. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > "Illegal values.", third example: > [[[ > img { background: "red" } /* keywords cannot be quoted */ > ]]] - > > The correct explanation for why this is an *illegal value* is: > "/* property does not accept a string value */" Resolution: We agree that the proposal is more technically correct, but we believe it would not be as helpful to people new to CSS as the technically incorrect text currently in the spec. Issue closed. ------------------------------------------------------------------------ Issue 53. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > Example: Unexpected end of style sheet > [[[ > @media screen { > p:before { content: 'Hello'; } > } > ]]] - > > Though the example is correct in its result, it is confusing: It looks > like the user agent (btw.: why not the *parser*?) is supposed to add a > semicolon and an empty declaration after closing the open string. I > suggest changing the reference style sheet to > > @media screen { > p:before { content: 'Hello'}} > > to better hint at what the parser should virtually append at the end of > the style sheet. Resolution: Remove the semicolon (but don't change the spacing). Issue closed. ------------------------------------------------------------------------ Issue 54. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > ...in a conformant UA. > ]]] - > > As far as I know, there is no such english word "conformant" (but then, > I'm German...); use "conforming" instead. Note that you use "conforming" > already in 4.3.6. Resolution: If we say it's a word, it's a word! (More than 2000 documents on w3.org use this word.) Issue closed. ------------------------------------------------------------------------ Issue 55. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > Unexpected end of style sheet." and "Unexpected end of string. > ]]] - > > Is there anywhere a rationale given for these two amendments in CSS 2.1? > At first sight, it looks like it might encourage sloppy style sheet authoring. Resolution: We need to define error handling to ensure interoperability. Issue closed. ------------------------------------------------------------------------ Issue 56. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > Some characters appearing in an unquoted URI, such as parentheses, > commas, whitespace characters, single quotes (') and double quotes ("), > must be escaped with a backslash: '\(', '\)', '\,'. > ]]] - > > Is this meant to be the comprehensive list of characters that need > quoting? Then it should be made clear. > > If it is not a comprehensive list, there should be a hint as to where to > deduct the characters needing quoting from, i.e. the token definition for > URI. Suggested wording: > > "All characters appearing in an unquoted URI must be quoted so that the > resulting URI value matches an URI token." Resolution: Append "so that the resulting URI value is a URI token" to the end of the existing sentence. Issue closed. ------------------------------------------------------------------------ Issue 57. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > I also do not see the requirement for restricting quoting to using the > backslash - it will just complicate parser implementations to enforce > this requirement, which is not even necessary according to the core grammar. Resolution: You misunderstood the spec -- because some characters must be quoted does not mean others must not be. Issue closed. ------------------------------------------------------------------------ Issue 58. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > In CSS2, the values of counters can only be referred to from the > 'content' property. > ]]] - > > What about CSS *2.1*, the specification at hand? Does it hold the same > restriction? Resolution: Change CSS2 to CSS 2.1 here. Issue closed. ------------------------------------------------------------------------ Issue 59. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > To refer to the value of a counter, the notation 'counter()' > or 'counter(, )' is used. > ]]] - > > In contrast to the wording in 4.3.4 or 4.3.6, there is no indication that > any optional whitespace is allowed in the counter(...)/counters(...) syntax. > Is it intended that exactly one space character must follow each comma, > and no further whitespace is allowed within the parentheses? If this is > not the case, please add appropriate text. Resolution: Append "with optional whitespace separating the tokens" at the end of the two sentences introducing counter syntax in 4.3.5. Issue closed. ------------------------------------------------------------------------ Issue 60. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > The list of keyword color names is:... > ]]] - > > Maybe change to: "The list of color name keywords is: ..." or even just > "The list of color keywords is: ...". Especially, since the next paragraph > starts calling them "color keywords", anyway. Resolution: Accepted. Issue closed. ------------------------------------------------------------------------ Issue 61. URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de Description: > [[[ > Conforming user agents... > ]]] - > > This text is not a link to the conformance section, whereas the later one > in 4.4.1 is. Either link both places or link only the first occurrence in > document order (i.e. this one). Resolution: Make both a link. Issue closed. ------------------------------------------------------------------------ Issue 62. URI: http://www.w3.org/mid/Pine.LNX.4.58.0507151120300.8454@localhost.localdomain Description: The description of the empty-cells property begins like this: In the separated borders model, this property controls the rendering of borders and backgrounds around cells that have no visible content. Why does it say "in the separated borders model"? There is nothing in the description of the property that implies that it cannot also apply to the collapsing border model, and in fact it is used in an example with the collapsing border model earlier in the spec (17.5.1). -Michael Resolution: Keep definiton of 'empty-cells' as is (i.e., doesn't apply to collapsed borders). Elika came up with replacement text and images: http://www.w3.org/mid/438820C2.6060800@inkedblade.net Issue closed. ------------------------------------------------------------------------ Issue 63. URI: http://www.w3.org/mid/Pine.LNX.4.58.0507151327520.10214@localhost.localdomain Description: Another empty-cells related question: the spec has the following statement: if all the cells in a row have a value of 'hide' and have no visible content, the entire row behaves as if it had 'display: none'. Is this a strict statement, in that a row in this situation will not increment any counters, nor will the table cells within it? Or is it a loose statement, in that a row in this situation just won't be drawn, similar to the effect produced with display: none? -Michael Resolution: Change quotes sentence to: "If all the cells in a row have a value of 'hide' and have no visible content, then the row has zero height and there is vertical border-spacing on only one side of the row." Issue closed. ------------------------------------------------------------------------ Issue 64. URI: http://www.w3.org/mid/i51ekacjbi2.wl@w3.mag.keio.ac.jp URI: http://www.w3.org/mid/op.svanzwqtsmjzpq@r600 Response: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0169.html Resolution: Made it refer to XHTML1 only. Issue closed. ------------------------------------------------------------------------ Issue 65. Folded into issue 92. Issue closed. ------------------------------------------------------------------------ Issue 66. URI: http://www.w3.org/mid/i51ekacjbi2.wl@w3.mag.keio.ac.jp URI: http://www.w3.org/mid/op.svanzwqtsmjzpq@r600 Response: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0169.html Issue closed. ------------------------------------------------------------------------ Issue 67. URI: http://www.w3.org/mid/42D266E6.70404@lachy.id.au Description: The spec states: | If a subsequent row has more columns than the first, then additional | columns must not be rendered. When using 'table-layout: fixed', | authors should not omit columns from the first row. That indicates that the total number of columns in the table is determined from the number of columns spanned by the cells in the first row. However, what if there are more 'table-column' elements than the first row? Should a UA still determine the number of columns from the first row or can that be determined from the number of table-columns? For example:
test test test
with this style: table { table-layout: fixed; width: 100%; } I tested Firefox 1.0.4, IE6 and Opera 8 and each of them leave space for the 4th cell. Can the spec be clarified to either explicity allow or disallow this behaviour? Resolution: s/If a subsequent row has more columns than the first,/If a subsequent row has more columns than the greater of the number determined by the table-column elements and the number determined by the first row," Issue closed. ------------------------------------------------------------------------ Issue 68. URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0064.html Description: Clarification: Section 9.4.3 states that if a relative positioned element causes an overflow:auto box to overflow, the UA must allow the user access to the content, with the effect of adding scrollbars (and possibly forcing re-layout). Does this also apply to overflow:scroll? Recommended change: Section 9.4.3; replace: "However, if relative positioning causes an 'overflow:auto' box to have overflow, ..." with "However, if relative positioning causes an 'overflow:auto' or 'overflow:scroll' box to have overflow, ..." -Markus Resolution: Accepted. Issue closed. ------------------------------------------------------------------------ Issue 69. URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0064.html Description: Clarification: In Section 9.4.3, should the scrolling mechanism that is used allow the user to scroll to the UNOFFSET position of the relative element, or the final, offset position? As written, the text implies that it is the final, offset position that must be accessible. Recommended change: Section 9.4.3; at end of first paragraph add: "The UA must provide access to the content as if the value of the 'left', 'right', 'top' and 'bottom' properties of relatively positioned elements were all zero." -Markus I disagree. I think you should be able to move to the final position to see the actual content. -Ian Bert disagrees too. Resolution: s/must allow the user to access this content/must allow the user to access this content (at its offset position)/ Issue closed. ------------------------------------------------------------------------ Issue 70. URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0064.html Description: Clarification: Can the initial containing block be the block defined by the HTML element? Section 10.1 says the UA chooses, but can it choose the HTML box? In other words, can absolutely positioned elements under the initial containing block be offset by any borders and margins on the HTML element, or must they be offset from 0,0 of the viewport? Recommended change: Section 9.4.3; Drop issue. No change/clarification required. -Markus Resolution: Reporter retracted issue. Issue closed. ------------------------------------------------------------------------ Issue 71. URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0064.html Description: Clarification: The CSS 2.1 spec makes no statement regarding special treatment for the size of the HTML element. Should it be: 1. sized as if it were a normal block box (which means it might be smaller than the available viewport? Opera appears to follow this approach. 2. increased in size (if smaller than the viewport) to fill the viewport? 3. increased in size to enclose all absolutely positioned content whose containing block is the initial containing block? Firefox and IE6 appear to follow this approach, but there is nothing in the speec to support this behavior. Recommended change: No change required. Just a clarification. The spec is very explicit that a border of a block box does not extend around an absolute positioned. Therefore IE and Firefox are misbehaving. Am I right? -Markus Yes. For Firefox this is fixed in the latest builds. -Ian Resolution: add right before "10.6.1": Note: these rules apply to the root element just as to any other element. Issue closed. ------------------------------------------------------------------------ Issue 72. URI: http://www.w3.org/mid/op.svanzwqtsmjzpq@r600 URI: http://www.w3.org/mid/i51zmsnrgqd.wl@w3.mag.keio.ac.jp Description: Many references in CSS 2.1 Last Call Working Draft are out of date. Resolution: Assumed editorial. (See e-mail, it has a list.) Issue closed. ------------------------------------------------------------------------ Issue 73. Description: (from karlo@opera) Does 'table-caption' introduce a new block formatting context? Proposal: Yes. Add them to 9.4.1. Resolution: Accepted. Issue closed. ------------------------------------------------------------------------ Issue 74. URI: http://www.w3.org/mid/927958.1121607979084.JavaMail.servlet@kundenserver Description: In section 15.7 HTML headings should have absolute font-sizes: http://www.w3.org/TR/2005/WD-CSS21-20050613/fonts.html#font-size-props but Appendix D. (Default style sheet for HTML 4.0) recommends to use em units for h1-h6: http://www.w3.org/TR/2005/WD-CSS21-20050613/sample.html This is not conistent and should be chanced. [sic] David: This is very closely related to Issue #41 in issues-2, where we did resolve to leave Appendix D as it is. It's not entirely clear what the resolution regarding the table, was, and this probably needs some further discussion. Resolution: Remove the row. Issue closed. ------------------------------------------------------------------------ Issue 75. URI: http://www.w3.org/mid/1121876815.7387.12.camel@c-gsoutter.uk.volantis.com Description: > In the latest WD, It appears that: > > http://www.w3.org/TR/2005/WD-CSS21-20050613/syndata.html#counter > > conflicts with: > > http://www.w3.org/TR/2005/WD-CSS21-20050613/generate.html#scope > > in that the former refers to out of scope counter-reset operating on the > root element and the latter refers to it operating on the the element in > question. > > As I understand it this behaviour has recently changed so it may have > been overlooked. The latter is correct. When proposing edits for some decisions we made regarding counters, I didn't even realize that the former section existed. Probably the sentence should just be removed (and perhaps much of the section). -David Resolution: 1. Remove the paragraph: # Counters that are not in the scope of any 'counter-reset', are # assumed to have been reset to 0 by a 'counter-reset' on the root # element. 2. Take the sentence at the end of the second paragraph: # See "Nested counters and scope" in the chapter on generated # content. and make it its own paragraph (i.e., the third), and add to the end so that it reads: # See "Nested counters and scope" in the chapter on generated # content for how user agents must determine the value or values of # the counter. See the definition of counter values of the # 'content' property for how it must convert these values to # a string. Issue closed. ------------------------------------------------------------------------ Issue 76. URI: http://www.w3.org/mid/42DFD435.7070702@mit.edu Description: > What exactly is meant by a "later 'counter-reset' on the same element"? p { counter-reset: mycounter 1 mycounter 2 mycounter; } That has three counter-resets on the same element for the same counter; the scope of the reset to 1 does not include nodes that are in the scope of the reset to 2; the scope of the reset to 2 does not include nodes that are in the scope of the reset to 0. That said, I think the wording of this section should be changed to: However, it does not include any elements in the scope of a counter _with_the_same_name_ created by a 'counter-reset' on a later sibling of the element or by a later 'counter-reset' on the same element. (note addition of "with the same name"; without that I don't believe the spec is saying what it wants to be saying). -Boris Resolution: Accepted. Issue closed. ------------------------------------------------------------------------ Issue 77. URI: http://www.w3.org/mid/1121938871.7387.24.camel@c-gsoutter.uk.volantis.com Description: Also, it would be helpful if the example in 12.4.1 was extended to cover the aspects of counters explained in the new text. It appears that it has not changed since the old CR. -Geoff Resolution: Leave example, but Edit as per http://www.w3.org/mid/20060509145746.GA22598@ridley.dbaron.org Issue closed. ------------------------------------------------------------------------ Issue 78. URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-1 Description: i18n review comment 1: Request for examples of i18n fonts. Not clear exactly what the request is asking for. -Ian #1 is probably asking to re-introduce "15.2.6 Generic font families" of CSS 2.0; I'm not sure why it's not in CSS 2.1. -Bjoern Discussion: http://lists.w3.org/Archives/Member/w3c-css-wg/2005OctDec/0010 http://www.w3.org/mid/BF68580E.618ED%25tantek@cs.stanford.edu Would I use 'width' and 'height' properties in the @page rule? Resolution: Elika, David, Tim and Bert agree to add the old 15.2.6 from CSS2 Issue closed. ------------------------------------------------------------------------ Issue 79. URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-2 URI: http://www.w3.org/mid/430DB962.5060700@cisra.canon.com.au Response: http://www.w3.org/mid/njfrg1da98i14ou9u48vh43tttvq3mhlm6@hive.bjoern.hoehrmann.de Response: http://www.w3.org/mid/200510101501.15289.bert@w3.org Description: i18n review comment 2: Request to use IRIs. See issues-2 issue 160. I don't think we can do #2 (adopt IRIs) for the reasons I cited in , in particular, we would violate (C014 requires that processing is equivalent regardless of the encoding but the IRI specification requires that processing is different if the style sheet is in a non-Unicode encoding). -Bjoern Resolution: We've already agreed that we're not doing IRIs this time. Bjoern replied to SVG, we need someone to point i18n to that reply. Awaiting further reply. Issue closed. ------------------------------------------------------------------------ Issue 80. URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-3 Description: i18n review comment 3: Does ':lang()' match elements that have language set to the empty tag? Spec currently says this is explicitly undefined. -Ian #3 seems http://www.w3.org/TR/2005/WD-CSS21-20050613/selector.html#lang to be addressed in the WD, :lang is defined in terms of the document language and we do discuss :lang() with no language. Seems they either missed that or they want that :lang() is not undefined in CSS 2.1. -Bjoern Resolution: :lang() (no argument) is a syntax error and causes the rule to be ignored. Change Exception: C may be empty, but it is undefined in CSS 2.1 what it matches in that case. (This is likely to be defined in CSS level 3.) to say that C must not be empty (and perhaps that it should be an identifier). Issue closed. ------------------------------------------------------------------------ Issue 81. URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-4 Description: i18n review comment 4: Phrasing of RFC3066 reference. Resolution: Assumed editorial. Issue closed. ------------------------------------------------------------------------ Issue 82. URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-5 Description: i18n review comment 5: Phrasing of bidi algorithm requirement. See also http://lists.w3.org/Archives/Member/w3c-i18n-ig/2003Oct/0227 Elika proposes: http://www.w3.org/TR/CSS21/visuren.html#direction # Conforming user agents that do not support bidirectional text may # ignore the 'direction' and 'unicode-bidi' properties described in # this section. Append to this paragraph: | This exception includes UAs that render right-to-left characters | simply because a font on the system contains them but do not | support the concept of right-to-left text direction. which is lifted from the end of the fourth paragraph in this section. # The characters in certain scripts are written from right to left # In some documents, in particular those written with the Arabic or # Hebrew script, and in some mixed-language contexts, text in a single # (visually displayed) block may appear with mixed directionality. # This phenomenon is called bidirectionality, or "bidi" for short. # # The Unicode standard ([UNICODE], section 3.11) defines a complex # algorithm for determining the proper directionality of text. The # algorithm consists of an implicit part based on character properties, # as well as explicit controls for embeddings and overrides. CSS 2.1 # relies on this algorithm to achieve proper bidirectional rendering. # The 'direction' and 'unicode-bidi' properties allow authors to # specify how the elements and attributes of a document language map # to this algorithm. Strike the entire paragraph below: # If the rendered content contains right-to-left characters, and if # the user agent displays these characters in right-to-left order, # the user agent must apply the bidirectional algorithm. (UAs that # render right-to-left characters simply because a font on the system # contains them but do not support the concept of right-to-left text # direction are exempt from this requirement.) Replace it with: | User agents that support bidirectional text must apply the Unicode | bidirectional algorithm to every sequence of inline boxes uninterrupted | by a forced line break or block boundary. This sequence forms the | "paragraph" unit in the bidirectional algorithm. The paragraph | embedding level is set according to the value of the 'direction' | property of the containing block rather than by the heuristic given | in steps P2 and P3 of the Unicode algorithm. Markus agrees with proposal ( http://lists.w3.org/Archives/Member/w3c-css-wg/2005OctDec/0030 ) Resolution: Issue closed. ------------------------------------------------------------------------ Issue 83. URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-6 Description: i18n review comment 6: Update Unicode and other i18n references. See also issues 22 (Unicode) and 72 (General). Resolution: Assumed editorial. Issue closed. ------------------------------------------------------------------------ Issue 84. URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-7 Response: http://lists.w3.org/Archives/Member/w3c-css-wg/2005OctDec/0022 Description: i18n review comment 7: @font-face See also issue 136b in issues-1. http://lists.w3.org/Archives/Public/www-style/2004Feb/0208 already addressed #7, I'm not sure how that is not acceptable or why they did not point this out 1 1/2 years ago. Adding @font-face now would require going back to Last Call and we would probably have to use SVG implementations to exit CR if at all possible. -Bjoern Awaiting further reply. Issue closed. ------------------------------------------------------------------------ Issue 85. URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-8 Response: http://lists.w3.org/Archives/Member/member-i18n-core/2005Oct/0017.html URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005OctDec/0107 Description: i18n review comment 8: Request for UTF-16 to be mandatory (Since XML implementors often try to get out of implementing UTF-16, and since UTF-16 doesn't add anything UTF-8 doesn't have, it doesn't seem clear why we would want to do this. -Ian) #8 seems to suggest we should require UTF-16 support. I don't mind doing that but UTF-16 is of little use in practise for CSS and the argument http://lists.w3.org/Archives/Public/www-tag/2005Jun/0017 that this is to align CSS with XML is flawed; as pointed out on www-tag, many formats and applications either ignore or circumvent the requirement to support UTF-16. -Bjoern Resolution: No change. Issue closed. ------------------------------------------------------------------------ Issue 86. URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-9 Description: i18n review comment 9: list-style-types No change requested. Issue closed. ------------------------------------------------------------------------ Issue 87. URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-10 Description: i18n review comment 10: Editorial issue to do with encodings of the spec. #10 is a bug, http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0168 it seems the .htaccess did not make it... -Bjoern Resolution: Assumed editorial. Issue closed. ------------------------------------------------------------------------ Issue 88. URI: https://bugzilla.mozilla.org/show_bug.cgi?id=295309 Description: In http://www.w3.org/TR/CSS21/box.html#collapsing-margins Change The bottom margin of an in-flow block-level element with a 'height' of 'auto' and 'min-height' less than the element's used height is adjoining to its last in-flow block-level child's bottom margin if the element has no bottom padding or border. ...to: The bottom margin of an in-flow block-level element with a 'height' of 'auto' and 'min-height' less than the element's used height and 'max-height' greater than the element's used height is adjoining to its last in-flow block-level child's bottom margin if the element has no bottom padding or border. (This adds 'max-height' to the equation.) -Ian Tentative resolution: agreed, except with significant discussion about whether there should be "or equal". Elika proposes: and a used height within the limits of its 'min-height' and 'max-height' David: "within or equal to"? "x or equal to" would always be true, so can't do that. Resolution: Use Ian's original proposal. Issue closed. ------------------------------------------------------------------------ Issue 89. URI: http://www.w3.org/mid/200508022034.03732.bert@w3.org URI: http://www.w3.org/mid/200508092004.26826.bert@w3.org Description: Richard Ishida was writing a tutorial on using language in CSS and had trouble understanding the difference between :lang(x) and [lang|=x]. If he has trouble, than maybe others have, too. He suggested addding a note to the spec to point out at least that the two selectors are different. He was confused by the text that :lang worked "in the same way" as |=. Here is a possible text to add at the end of 5.11.4: *Note* the difference between [lang|=xx] and :lang(xx). In this HTML example, a rule for styling the paragraph for French would match the paragraph if the selector was 'p:lang(fr)', but 'p[lang|=fr]' will not match against this paragraph.

Je suis français.

Here is an alternative wording: *Note* the difference between [lang|=xx] and :lang(xx). In this HTML example, only the BODY matches [lang|=fr] (because it has a LANG attribute) but both the BODY and the P match :lang(fr) (because both are in French).

Je suis français.

-Bert Resolution: The second version is better. Add it. Issue closed. ------------------------------------------------------------------------ Issue 90. URI: http://www.w3.org/mid/42F8DBE8.3060801@us.ibm.com URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0099.html Description: Float rules. Resolution: Adding an example to the spec will be very useful. Issue closed. ------------------------------------------------------------------------ Issue 91. URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0060.html Description: The following two paragraphs in [1]: # The background of the root element becomes the background of the # canvas and covers the entire canvas, anchored at the same point as it # would be if it was painted only for the root element itself. The root # element does not paint this background again. # For HTML documents, however, we recommend that authors specify the # background for the BODY element rather than the HTML element. For HTML # documents whose root HTML element has computed values of 'transparent' # for 'background-color' and 'none' for 'background-image', user agents # must instead use the computed value of those properties from that HTML # element's first BODY element child when painting backgrounds for the # canvas, and must not paint a background for that BODY element. This # does not apply to XHTML documents. make it clear at what position a canvas background is painted when it comes from the root element ("anchored at the same point as..."), but do not state the position used when it comes from the BODY element. They should do so. I think it should be the same, but it's worth checking implementations. [1] http://www.w3.org/TR/2005/WD-CSS21-20050613/colors.html#q2 -dbaron The intention was that you'd use the computed values of the background properties of the BODY element, but paint everything relative to the HTML element, and do so across the entire canvas. In theory that's what browsers have implemented, too. -Ian Resolution: Add "(for 'background-position')" after the first occurance of "anchored". Add "Such backgrounds must also be anchored at the same point as they would be if they were painted only for the root element." between "must not paint a background for that BODY element." and "This does not apply". Issue closed. ------------------------------------------------------------------------ Issue 92. URI: http://www.w3.org/mid/op.svanzwqtsmjzpq@r600 URI: http://www.w3.org/mid/i51ekacjbi2.wl@w3.mag.keio.ac.jp Description: > - 4.3.4 URL + URN = URI > http://www.w3.org/TR/2005/WD-CSS21-20050613/syndata.html#uri > > This (URL + URN = URI) is now considered the "Classical View". Maybe > CSS 2.1 should adopt the "Contemporary View". > > cf. http://www.w3.org/TR/2001/NOTE-uri-clarification-20010921/#contemporary -HTMLWG Resolution: Change the title to "4.3.4 URLs and URIs". Remove the first paragraph of the section. Change "URI values" to "URI values (Uniform Resource Identifiers, see [RFC3986], which includes URLs, URNs, etc)" in the next paragraph. Issue closed. ------------------------------------------------------------------------ Issue 93. URI: http://www.w3.org/mid/4546CB8F-CE65-4C80-8FC4-EB737B57961E@apple.com URI: http://www.w3.org/mid/ED86FF2C-94FE-42D2-89F3-31B1051C181B@apple.com Description: The CSS2.1 draft states that the baseline of an inline block is the baseline of the last line box in the inline block. I just made this change and broke some Dashboard widgets. :) The problem is that the draft doesn't mention what to do if overflow is hidden/auto/scroll (and I didn't think of it either). Similarly, the first row of an inline table could be inside a scrolling table body. Should overflow != visible cause the inline block to align on its bottom margin edge always? Only if scrolled? Only if the last line is clipped? Another question I had was why use the first row for tables but the last line for inline blocks? That seems completely inconsistent to me. -hyatt (further comments at second URI) Resolution: Change: A UA should use the baseline of the last line box in the normal flow in the element as the baseline of an 'inline-block', or the element's bottom margin edge, if there is none. ...to: The baseline of an 'inline-block' is the baseline of its last line box in the normal flow, unless it has either no in-flow line boxes or if its 'overflow' property has a computed value other than 'visible', in which case the baseline is the bottom margin edge. Issue closed. ------------------------------------------------------------------------ Issue 94. URI: http://www.w3.org/mid/20050812151904.CE7B91BEBE@localhost.localdomain URI: http://www.w3.org/mid/3F6865DB7477EF4A8F79ABCB18DC7E5B02562635@cacexc06.americas.cpqcorp.net URI: http://www.w3.org/mid/17152.49397.380005.652527@localhost.localdomain Description: Some paged media stuff. (abs pos and page breaks) Third URI has proposals. Replace third sentence of first bullet point of 13.2: The edges of the first page area act as the initial containing block for layout that occurs between page breaks. ...with: The edges of the first page area establish the rectangle that is the initial containing block of the document. Issue closed. ------------------------------------------------------------------------ Issue 95. URI: http://www.w3.org/mid/Pine.LNX.4.62.0508201136250.32132@dhalsim.dreamhost.com URI: http://www.w3.org/mid/200508221756.31163.bert@w3.org Description: On Mon, 1 Aug 2005, Michael Day wrote: > > On the subject of ex units, how would they work in the following > situation: > >
>
> Hello, world! >
> Goodbye, world! >
> > Which font's x-height is used for the width of the two divs? Lengths are inherited as absolute values, so the inner
doesn't affect the answer to your question, thus it can't be 'sans-serif'. The outer div's width doesn't change based on its contents, so the doesn't affect the answer either, so it can't be 'monospace'. This leaves a MissingFont and 'serif'. Well it obviously can't be MissingFont since, well, it's missing. Thus it must be 'serif'. This isn't clear in CSS2.1. I suggest we change the following: The 'ex' unit is defined by the font's 'x-height'. The x-height is so called because it is often equal to the height of the lowercase "x". However, an 'ex' is defined even for fonts that don't contain an "x". ...to read: The 'ex' unit is defined by the element's first available font's 'x-height' metric. The x-height is so called because it is often equal to the height of the lowercase "x". However, an 'ex' is defined even for fonts that don't contain an "x". -Ian > However, does every font really have an x-height? Every *TrueType* > font does, but not all fonts are TrueType fonts: in particular, the > "serif" font is hardly ever a single TrueType font, it is usually a > collection of different fonts bundled together under the same name. I don't like to tie the spec to any specific font technology, at least not normatively, but TrueType could be mentioned as an example. For example, in the following algorithm: 1) Look at the first available font in the list, i.e., the first font that is available to the UA. If that font defines an x-height (e.g., sxHeight in OpenType and xheight in TFM), the UA must use that as the 'ex'. 2) If that font doesn't define an x-height, the UA should measure the height of an "x", as it would be drawn if the element contained an "x". (Note that that "x" may come from a later font in the list or from the UA's fallback font.) 3) If it is not possible to measure the "x", a value of 0.45 em should be used. -Bert > If the "first available font" is defined to be the font used by the > first character found in the element, what about elements that use ex > units but do not contain any text? I think the first available font is the first font in the list that the UA can read, independent of whether the element uses any glyphs from it. -Bert Bert had an action to come up with some text and came up with these two alternatives: http://lists.w3.org/Archives/Member/w3c-css-wg/2005OctDec/0063 http://www.w3.org/mid/200511071925.10288.bert@w3.org The latter is: The 'ex' unit is defined by the font's 'x-height'. The x-height is so called because it is often equal to the height of the lowercase "x". However, an 'ex' is defined even for fonts that don't contain an "x". UAs must follow the following algorithm to establish the 'ex' for a given element: 1. Using the algorithm for font selection (section 15.2), find the font that would be used for rendering an "x". 2. Set the 'ex' to the x-height defined by that font; or draw the "x" (in an off-screen buffer) and measure its height. 3. If it is impossible to find an x-height or measure an "x" glyph, use 0.5em. UAs should take care that the 'ex' they compute in step 2 is reasonable. In many fonts, the height of an "x" is not equal to the x-height (e.g., because the x has a decorative flourish). On the other hand, experience shows that many fonts don't define an x-height or define it incorrectly. Ian responded to the first of these with a suggestion to change the following paragraph now in the spec: The 'ex' unit is defined by the font's 'x-height'. The x-height is so called because it is often equal to the height of the lowercase "x". However, an 'ex' is defined even for fonts that don't contain an "x". ...to read: The 'ex' unit is defined by the element's first available font's 'x-height' metric. The element's first available font is the one that is found using the font matching algorithm, but without limiting the search to fonts that contain particular characters. The x-height is so called because it is often equal to the height of the lowercase "x". However, an 'ex' is defined even for fonts that don't contain an "x". User agent should use font metrics or direct glyph measurement if possible, but may fall back on a default of 0.5em if the first available font does not contain suitable information. Ian responded to the second of Bert's ideas above with: > This would work too. It differs from the alternative proposal in that > it uses the 'ex' height of the first font _with an x_, rather than > the first available font. Is that what we want? To which Bert replied: That's what I gathered from the minutes: http://www.w3.org/2005/10/17-css-irc.html#T22-09-17 I think the argument was that, if you use an ex and there is an x in the content, you would want the two to match. Plus, UAs already know how to search the font list for the font with an x. I think that's reasonable, and it made the algorithm nice and short. But I'm open for suggestions. Further e-mails on the subject: SteveZ: http://www.w3.org/mid/6.2.1.2.2.20060207095711.058cbeb0@namailhost.corp.adobe.com Paul Nelson: http://www.w3.org/mid/49C257E2C13F584790B2E302E021B6F90ED3DF69@winse-msg-01.segroup.winse.corp.microsoft.com Howcome: http://www.w3.org/mid/17385.2325.554019.960121@localhost.localdomain Ian: http://www.w3.org/mid/Pine.LNX.4.62.0602141911330.28514@dhalsim.dreamhost.com Resolution: > The 'ex' unit is defined by the element's first available font. The > x-height is so called because it is often equal to the height of the > lowercase "x". However, an 'ex' is defined even for fonts that don't > contain an "x". > > The x-height of a font can be found in different ways. Some > fonts contain reliable metrics for the x-height. If reliable font > metrics are not available, UAs may determine the x-height from the > height of a lowercase glyph. One possible heuristics is to look at how > far the glyph for the lowercase "o" extends below the baseline, and > subtract that value from the top of its bounding box. In the cases > where it is impossible or impractical to determine the x-height, a > value of 0.5em should be used. Issue closed. ------------------------------------------------------------------------ Issue 96. URI: http://www.w3.org/mid/430B4766.8070004@tu-clausthal.de Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0207.html Description: Subject: [CSS21] 3.2 Conformance: User Preferences Issue closed. ------------------------------------------------------------------------ Issue 97. URI: http://www.w3.org/mid/430DB80F.80504@cisra.canon.com.au Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0358.html URI: http://www.w3.org/mid/431235A0.2090202@cisra.canon.com.au Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0379.html Description: Subject: [CSS21] Examples From Craig on behalf of SVG. Awaiting further clarification. Issue closed. ------------------------------------------------------------------------ Issue 98. URI: http://www.w3.org/mid/1171770201.20050825154958@w3.org Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0359.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0401.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0422.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0401.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0422.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0425.html Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0122.html URI: http://lists.w3.org/Archives/Public/www-style/2005Oct/0126.html Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0138.html Description: Subject: [CSS21] Examples From Chris on behalf of SVG and CDF. Awaiting further reply. Issue closed. ------------------------------------------------------------------------ Issue 99. URI: http://www.w3.org/mid/430DB839.60106@cisra.canon.com.au Description: Section 3.3 Error conditions says we don't define error handling behaviour. However, this seems to be untrue. Resolution: Replace first paragraph with: In general, this document specifies error handling behavior throughout the specification. For example, see the rules for handling parsing errors. Drop the second and third paragraphs. Issue closed. ------------------------------------------------------------------------ Issue 100. URI: http://www.w3.org/mid/430DB861.30309@cisra.canon.com.au Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0254.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0259.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0269.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0274.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0360.html Description: Subject: [CSS21] Section 4.1.1 From Craig on behalf of SVG. Satisfied: http://www.w3.org/mid/43123735.1050408@cisra.canon.com.au Issue closed. ------------------------------------------------------------------------ Issue 101. URI: http://www.w3.org/mid/430DB885.6060505@cisra.canon.com.au Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0257.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0265.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0268.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0273.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0361.html Description: Subject: Re:\[CSS21] Section 4.1.1 (b) From Craig on behalf of SVG. Satisfied: http://www.w3.org/mid/43123735.1050408@cisra.canon.com.au Issue closed. ------------------------------------------------------------------------ Issue 102. URI: http://www.w3.org/mid/430DB8AD.3030405@cisra.canon.com.au Description: We claim that 4.1.2.2 Informative Historical Notes is informative, but the last sentence uses RFC2119 terminology in a seemingly normative manner: Vendor/organization specific extensions should be avoided. We should fix the inconsistency here somehow. Resolution: Move the normative line to the previous section and change it to read "Authors should avoid vendor-specific extensions". Fix the table as well (-ms- for Microsoft, mso- for Microsoft Office, -moz- for Mozilla). Issue closed. ------------------------------------------------------------------------ Issue 103. URI: http://www.w3.org/mid/430DB8F1.9010105@cisra.canon.com.au Response: http://www.w3.org/mid/35grg19rkm7qej471chpjhl3brdqm2k1hv@hive.bjoern.hoehrmann.de Description: Subject: Re: [CSS21] ISO10646 From Craig on behalf of SVG. Awaiting further reply. Issue closed. ------------------------------------------------------------------------ Issue 104. URI: http://www.w3.org/mid/430DB91A.2080905@cisra.canon.com.au URI: http://www.w3.org/mid/430DB941.9060204@cisra.canon.com.au Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0142.html URI: http://lists.w3.org/Archives/Public/www-style/2005Oct/0143.html Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0147.html Description: Section 4.2 This section states that CSS reserves all property values and @-keywords. So any property introduced by other working groups must be ignored. This also states that only future CSS specifications can introduce properties. Please remove statements that indicate the CSS WG owns all property values and @-keyword as this is not true. For instance SVG 1.1 introduced for instance, the @color-profile keyword. The last sentence under the illegal values bullet point indicates that conforming CSS UA's can accept values defined in future specification. This does not take into account values that could be added by other grammars. Please allow other grammers (such as SVG) to add property values. -SVG Property Resolution: Rejected. This statement only applies to text/css resources, which is the responsibility of the CSS working group; it is not a statment regarding the general W3C property namespace. SZ sent http://www.w3.org/mid/6.2.1.2.2.20051201104905.0f7e1db0@namailhost.corp.adobe.com WG discussed but disagreed with the conclusion. Issue closed. ------------------------------------------------------------------------ Issue 105. URI: http://www.w3.org/mid/430DB9F0.7080409@cisra.canon.com.au Description: Section 4.3.6 Could you specify that users agents may perform higher quality mapping of colours from one gamut to another? Specifying that they should be clipped will produce poor results when the output colour space is not 'close' to sRGB, such as a CMYK printer. For example User Agents may use a process that provides mapping of the gamut to the device gamut in other ways, such as perceptual or photometric gamut mapping. This may involve compressing the full gamut of colours to fit inside the gamut of the output device, rather than simply clipping those outside the gamut so as to provide a better visual output. Please allow conformant UA's to perform higher quality gamut mapping. Also please specify late clipping of colours as per CSS 2.0. Thus preserving colours until the final rendering step. This will also facilitate better colour quality. -SVG I think the answer is that remapping is not possible without knowing what gamut the colors were chosen for in the first place (although it is probably a good guess that colors in an '@media screen' style sheet are meant for an RGB monitor). There is a property 'rendering-intent' in CSS3 Color, which may help with remapping. Resolution: Insert "Users agents may perform higher quality mapping of colors from one gamut to another." just before the sentence that starts with "For a typical CRT monitor...". Then change "clipped" at the end of the section to "mapped". Issue closed. ------------------------------------------------------------------------ Issue 106. URI: http://www.w3.org/mid/430DBA41.5080802@cisra.canon.com.au Thread: http://lists.w3.org/Archives/Public/www-style/2005Aug/thread.html#221 Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0292.html Description: Subject: [CSS21] CSS3 From Craig on behalf of SVG. Awaiting further reply. Issue closed. ------------------------------------------------------------------------ Issue 107. URI: http://www.w3.org/mid/430DBA76.60509@cisra.canon.com.au Description: Section 5.8.3 Why does this section reference SVG 1.0? It should reference SVG 1.1. Please correct this. -SVG Resolution: Assumed editorial. Issue closed. ------------------------------------------------------------------------ Issue 108. URI: http://www.w3.org/mid/430DBA76.60509@cisra.canon.com.au Description: Section 5.8.3 The page numbers are also missing, but why are there page numbers at all? (e.g. SVG 1.0 [SVG10] describes the SVG "class" attribute [p. ??] and how a UA should interpret it, and similarly MathML 2.0 [MATH20] describes the MathML "class" attribute [p. ??] .) -SVG Resolution: Rejected; page numbers are added by PS generator. Issue closed. ------------------------------------------------------------------------ Issue 109. URI: http://www.w3.org/mid/430DBAA3.1050102@cisra.canon.com.au Thread: http://lists.w3.org/Archives/Public/www-style/2005Aug/thread.html#223 Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0363.html Description: Subject: Re: [CSS21] Additional Note From Craig on behalf of SVG. Satisfied: mid:4312373E.2080804@cisra.canon.com.au Issue closed. ------------------------------------------------------------------------ Issue 110. URI: http://www.w3.org/mid/430DBAD7.8060305@cisra.canon.com.au Response: http://www.w3.org/mid/lverg1pki5p4nfakttihgedg568etnaqik@hive.bjoern.hoehrmann.de Description: Subject: [CSS21] xml:id From Craig on behalf of SVG. Awaiting further reply. Issue closed. ------------------------------------------------------------------------ Issue 111. URI: http://www.w3.org/mid/430DBB11.2010004@cisra.canon.com.au Thread: http://lists.w3.org/Archives/Public/www-style/2005Aug/thread.html#225 Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0364.html Description: Subject: From Craig on behalf of SVG. Resolution: Examples fixed, note in 1.4.4 changed. Awaiting further reply. Issue closed. ------------------------------------------------------------------------ Issue 112. URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0226 Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0365.html Description: Subject: [CSS21] Section 6.1.2 From Craig on behalf of SVG. Satisfied: http://www.w3.org/mid/43123735.1050408@cisra.canon.com.au Issue closed. ------------------------------------------------------------------------ Issue 113. URI: http://www.w3.org/mid/430DBB4B.9010802@cisra.canon.com.au Thread: http://lists.w3.org/Archives/Public/www-style/2005Aug/thread.html#227 Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0299.html Description: Subject: [CSS21] Section 6.1.3 From Craig on behalf of SVG. Satisfied: http://www.w3.org/mid/43123735.1050408@cisra.canon.com.au Issue closed. ------------------------------------------------------------------------ Issue 114. URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0228 Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0293.html Description: Subject: Re: [CSS21] Section 6.4.4 From Craig on behalf of SVG. Awaiting further reply. Issue closed. ------------------------------------------------------------------------ Issue 115. URI: http://www.w3.org/mid/430DBB93.6090808@cisra.canon.com.au Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0366.html Description: Subject: [CSS21] Section 15.2 From Craig on behalf of SVG. Satisfied: http://www.w3.org/mid/43123735.1050408@cisra.canon.com.au Issue closed. ------------------------------------------------------------------------ Issue 116. URI: http://www.w3.org/mid/1404915290.20050825153832@w3.org Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0368.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0381.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0386.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0390.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0392.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0397.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0420.html URI: http://www.w3.org/mid/43156D79.1070402@disruptive-innovations.com URI: http://www.w3.org/mid/438E77CE.7010107@inkedblade.net URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0427.html Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0142.html (post-discussion) URI: http://lists.w3.org/Archives/Public/www-style/2005Oct/0143.html Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0147.html URI: http://lists.w3.org/Archives/Public/www-style/2005Oct/0151.html Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0156.html Description: Subject: Re: [CSS21] Unclear status of different versions Subject: Re: several messages Subject: Re: How to add properties to the CSS syntax From Chris on behalf of SVG and CDF. Resolution: In Abstract and Section 1.1, remove the sentence starting "Implementations may refer to CSS2...", and replace it with "Future specs should refer to CSS2.1 (unless they need features from CSS2 which have been dropped in CSS2.1, and then they should only reference CSS2 for those features, or preferably reference such feature(s) in the respective CSS3 Module that includes those feature(s))." Issue closed. ------------------------------------------------------------------------ Issue 117. URI: http://www.w3.org/mid/265287321.20050825153955@w3.org Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0369.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0380.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0382.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0383.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0385.html (no request) URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0388.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0413.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0424.html Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0121.html URI: http://www.w3.org/mid/304767906.20051017163037@w3.org (no request) Description: Subject: Re: [CSS21] Unclear applicability to XML From Chris on behalf of SVG and CDF. Reporter stated intent to clarify request. Awaiting further reply. Issue closed. ------------------------------------------------------------------------ Issue 118. URI: http://www.w3.org/mid/1789757423.20050825154151@w3.org Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0370.html Description: Subject: Re: [CSS21] Multiple IDs From Chris on behalf of SVG and CDF. Awaiting further reply. Issue closed. ------------------------------------------------------------------------ Issue 119. URI: http://www.w3.org/mid/619362537.20050825154406@w3.org Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0283.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0284.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0305.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0309.html Description: Subject: [CSS21] Lack of version control for content From Chris on behalf of SVG and CDF. Awaiting further reply. Issue closed. ------------------------------------------------------------------------ Issue 120. URI: http://www.w3.org/mid/39742339.20050825154530@w3.org Description: Please clearly mark which sections are normative and which informative. This applies to the entire document. As an example, in chapter 2: * 2.1 A brief CSS 2.1 tutorial for HTML * 2.2 A brief CSS 2.1 tutorial for XML * 2.3 The CSS 2.1 processing model o 2.3.1 The canvas o 2.3.2 CSS 2.1 addressing model * 2.4 CSS design principles Perhaps the tutorials of 2.1, 2.2 are informative and the processing model 2.3 is normative? Its not clear whether 2.4 should be normative or informative. Informative: 1.2, 1.3, 1.5, 2.1, 2.2, 2.4, A, C, D, F, I Normative: Everything else, including G. Resolution: Add to 3.1: "All sections of this specification, including appendices, are normative unless otherwise noted." In all places that are non-normative (as listed below) state "This section is non-normative." Those sections are: 1.2, 1.3, 1.5, 2.1, 2.2, 2.4, A, C, D, F, I Remove the statement in G that it is normative. Hyperlink 1.4.4 to 3.1, and 3.1 to 1.4.4. Update the reference to "CSS1" in 1.4.4 to just say "CSS". Issue closed. ------------------------------------------------------------------------ Issue 121. URI: http://www.w3.org/mid/1341455960.20050825154824@w3.org Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0371.html URI: http://www.w3.org/mid/1341229462.20050829170955@w3.org Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0387.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0389.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0417.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0428.html Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0124.html Description: Subject: [CSS21] Projected deprecation Resolution: Assumed s/such as/namely/ by Ian. See http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0171.html Issue closed. ------------------------------------------------------------------------ Issue 122. URI: http://www.w3.org/mid/1382052719.20050825155110@w3.org Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0372.html Description: Subject: [CSS21] Notes From Chris on behalf of SVG and CDF. Awaiting further reply. Issue closed. ------------------------------------------------------------------------ Issue 123. URI: http://www.w3.org/mid/922544614.20050825155235@w3.org Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0373.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0398.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0421.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0426.html Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0123.html URI: http://lists.w3.org/Archives/Public/www-style/2005Oct/0125.html Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0135.html URI: http://lists.w3.org/Archives/Public/www-style/2005Oct/0137.html Description: Subject: Re: [CSS21] Style sheet definition From Chris on behalf of SVG and CDF. Reporter said he would take the issue up elsewhere. Issue closed. ------------------------------------------------------------------------ Issue 124. URI: http://www.w3.org/mid/406656511.20050825155353@w3.org Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0374.html Description: Subject: Re: [CSS21] Single viewport From Chris on behalf of SVG and CDF. Awaiting further reply. Issue closed. ------------------------------------------------------------------------ Issue 125. Thread: http://lists.w3.org/Archives/Public/www-style/2005Aug/thread.html#266 URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0266.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0296.html (replied) Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0339.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0306.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0307.html (replied) Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0310.html (replied) URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0308.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0311.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0321.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0333.html (replied) URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0335.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0336.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0352.html (replied) URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0322.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0324.html (replied) URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0326.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0328.html (replied) URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0329.html Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0376.html URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0399.html (no requests) Description: Subject: Re: [CSS21] Wider variety of (non-junk) examples requested From Chris on behalf of SVG. Awaiting further reply. Issue closed. ------------------------------------------------------------------------ Issue 126. Description: 4.1.5 is clear that "CSS 2.1 user agents must ignore any '@import' rule that occurs inside a block or after any valid rule other than an @charset or an @import rule.", ever since we agreed to say this as part of CSS2.1 issues-2 issue 82. Thus, UA requirements are clear. However, section 6.3 says "Any @import rules must precede all rule sets in a style sheet.", which is for the author point of view but is not as clear. I propose we change that sentence in 6.3 to read "Any @import rules must precede all other rules (except the @charset rule, if present)." -Ian (Incidentally, there's an error in media queries. It has an @import inside an @media block. Oops.) Resolution: Approved. Make change described above. Issue closed. ------------------------------------------------------------------------ Issue 127. URI: http://www.w3.org/mid/43496FF1.6030306@inkedblade.net Description: (See also empty-cells in issue 62) http://www.w3.org/TR/CSS21/tables.html#table-layers This example seems to be demonstrating two things: - what to do if a cell is empty and empty-cells is 'hide' - what to do if a cell is completely missing The first case is well-defined in CSS2.1, but the second doesn't seem to be defined at all. I propose that missing cells be treated, for the purpose of rendering, as empty cells with all properties (notably including border and background) except 'emtpy-cells' set at their default values and "empty-cells: hide". This will make sure handling in collapsed border tables defined, and will make sure the cells effectively disappear in the separated borders model. It's also compatible with what I perceive to be CSS2's take on the problem. (See the last rule in 17.5.1 in CSS2.) -Elika Resolution: Add the following paragraph right after the list and before the paragraph following the list in section 17.5: A "missing cell" is a cell in the row/column grid that is not occupied by an element or pseudo-element. Missing cells are rendered as if an anonymous table-cell box occupied their position in the grid. Issue closed. ------------------------------------------------------------------------ Issue 128. URI: http://www.w3.org/mid/4315C787.6030203@comhem.se Description: shrink-to-fit issue. Resolution: He is wrong. David replied: http://lists.w3.org/Archives/Public/www-style/2005Aug/0437.html Issue closed. ------------------------------------------------------------------------ Issue 129. URI: http://www.w3.org/mid/43187BCC.3050109@easyconnect.fr Description: error handling of selectors Resolution: Add reference from 4.2 to 4.1.7. Issue closed. ------------------------------------------------------------------------ Issue 130. URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0196.html Description: Some things in 4.1.1 still say [a-zA-Z]. Resolution: Assumed editorial. Issued closed. ------------------------------------------------------------------------ Issue 131. URI: http://www.w3.org/mid/e474a6b0ffb3c208411115775fe0b074@asahi-net.or.jp Description: Request to change a graphic. Resolution: Assumed editorial by Ian. Issue closed. ------------------------------------------------------------------------ Issue 132. URI: http://www.w3.org/mid/9882C98B3C3D9B45A9A5F9EDECE014D812686BF9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com Description: Clarify rule about pseudo-elements not being anywhere but the end of a rule. Resolution: Retracted by reporter. Issue closed. ------------------------------------------------------------------------ Issue 133. URI: http://www.w3.org/mid/20050919225223.GA9168@ridley.dbaron.org Description: List numbering in 2.1. Resolution: Remain silent. Address in test suite. =Hixie= Test suite: Put http://dbaron.org/css/test/2005/list-numbering-across-types in the test suite along with many other tests on this. Issue closed. ------------------------------------------------------------------------ Issue 134. URI: http://www.w3.org/mid/n2m-g.5tqkj11nfnmho9ijthjsj51um88q0r9kvm@news.spartanicus.utvinternet.ie URI: http://www.w3.org/mid/n2m-g.shskj1hnqnk0u1q1096r4aurdeaekhfl0i@news.spartanicus.utvinternet.ie Description: http://www.w3.org/TR/CSS21/changes.html#q4 currently doesn't mention the new value "none" for the "content" property, and other comments. Resolution: Assumed editorial. Issue closed. ------------------------------------------------------------------------ Issue 135. URI: http://www.w3.org/mid/20050929151808.12625@mail.visualclick.de URI: http://www.w3.org/mid/20050929160255.25775@mail.visualclick.de URI: http://www.w3.org/mid/20051003125102.16412@mail.visualclick.de URI: http://www.w3.org/mid/20050929173351.13550@mail.visualclick.de (proposal) Description: I seem to have lost the place where it is defined how to establish the size of the page box (). I think this used to be done with the 'size' property in CSS2, but this is no longer in CSS21. Resolution: Issue closed. ------------------------------------------------------------------------ Issue 136. Description: Many of the normative refs should be informative. PNG, HTML4, CSS1, CSS2, XML10 etc might not want to be normative. But we should check. [CHARSETS] maybe should be normative? Resolution: =David= Check all the references for whether they should be norm/non-norm. ------------------------------------------------------------------------ Issue 137. Description: Resolution: Change or remove the copyright in chapter 1. (1.6) Issue closed. ------------------------------------------------------------------------ Issue 138. Description: PDF is broken (appendices out of order). Resolution: Issue closed. ------------------------------------------------------------------------ Issue 139. Description: [PNG]'s URI is old. [URI]'s reference's description is missing. (RFC problem) Resolution: Issue closed. ------------------------------------------------------------------------ Issue 140. URI: http://www.w3.org/mid/7AEA6A97-B533-4707-87A3-A4BE386A4CFF@apple.com URI: http://www.w3.org/mid/37891D60-D98A-47AF-AD51-2323D2AC6454@apple.com URI: http://www.w3.org/mid/F9AA656B-D48C-4043-A65F-BB7461BC74A9@apple.com URI: http://www.w3.org/mid/EFD9E7D3-D95D-4377-9519-D3BAFC63567A@apple.com Description: pre-wrap issue. Last e-mail has proposals. Various proposals have been made that differ from the above proposals, but they have received push-back. Resolution: 4. If spaces (U+0020) or tabs (U+0009) at the end of a line have 'white-space' set to 'pre-wrap', UAs may visually collapse them. Issue closed. ------------------------------------------------------------------------ Issue 141. URI: http://www.w3.org/mid/4383ABE2.5010905@mit.edu Description: I think 6.4.1 needs to be clearer about the sort at each step being only within groups of rules that sorted equivalent to each other at the previous step... That's not obvious from just looking at the text, as things stand. -Boris howcome says: I propose to change this text in 6.4.1 from: To find the value for an element/property combination, user agents must apply the following sorting order: to: To find the value for an element/property combination, user agents must use the following pseudo-algorithm: and add this paragraph after the numbered list: The sorting process continues until one winning declaration is found. dbaron disagreed and proposed: Change the start of (2) from "Sort" to "Choose the last declaration in the sort". Change the start of (3) from "Sort" to "If the previous sort resulted in a tie, break the tie by choosing the highest declaration in the sort". Change the start of (4) from "Finally, sort by order specified: if two rules have the same weight, origin and specificity," to "Finally, if the previous sort still resulted in a tie,". David also proposed: Choose the declarations at the highest numerical value in the following list based on importance (normal or important) and origin (author, user, or user agent): 1. user agent style sheets 2. user normal style sheets 3. author normal style sheets 4. author important style sheets 5. user important style sheets If this results in more than one declaration, choose the declarations tied for the highest specificity of selector. Pseudo-elements and pseudo-classes are counted as normal elements and classes, respectively. If this results in more than one declaration, break the tie with order: the latter specified wins. Rules in imported style sheets are considered to be before any rules in the style sheet itself. Resolution: Replace 2 with "2. Sort according to importance (normal or important) and origin (author, user, or user agent). In ascending order of precendence:" Insert "rules with the same importance and origin" after "3. Sort" Issue closed. ------------------------------------------------------------------------ Issue 142. URI: http://www.w3.org/mid/20051123002259.GA27719@ridley.dbaron.org > "User agent: Conforming user agents must apply a default style sheet > (or behave as if they did) prior to all other style sheets for a > document....." We should just remove the words "prior to all other style sheets for a document", since they're redundant and potentially confusing if interpreted too literally. -dbaron Resolution: Accept dbaron's proposal. Issue closed. ------------------------------------------------------------------------ Issue 143. Description: Margin and padding properties should apply to table-caption (they currently say they don't despite the table section defining how margins work for table-caption boxes). Resolution: Change Applies To: line. Issue closed. ------------------------------------------------------------------------ Issue 144. URI: http://www.w3.org/mid/439D00F7.5060500@inkedblade.net URI: http://www.w3.org/mid/440CFCDC.6030301@inkedblade.net Description: Table backgrounds. Resolution: Replace text as given in Elika's email Issue closed. ------------------------------------------------------------------------ Issue 145. URI: http://www.w3.org/mid/43E85E2B.5030203@lachy.id.au Description: Resolution: Not changing this for CSS2.1. Issue closed. ------------------------------------------------------------------------ Issue 146. URI: http://www.w3.org/mid/200602031701.30469.bert@w3.org Description: Resolution: Answered on list. Issue closed. ------------------------------------------------------------------------ Issue 147. URI: http://www.w3.org/mid/5a5jr1pi8b2hh2tdl0812einu2i01b5472@hive.bjoern.hoehrmann.de Description: http://www.w3.org/TR/2005/WD-CSS21-20050613/grammar.html G.2 has "!"{w}"important" {return IMPORTANT_SYM;} ... "url("{w}{string}{w}")" {return URI;} So you can't have url(/**/foo/**/) or !/**/important (or you can have both, my flex is a bit rusty); this contradicts 4.1.1 which prohibes the former and allows the latter. Anne says iCab, IE win/mac, and Gecko do apply "!/**/important", Opera and KHTML do not. Resolution: Fix the tokeniser. Issue closed. Testcases: http://www.hixie.ch/tests/adhoc/css/parsing/uri/001.html http://www.hixie.ch/tests/adhoc/css/parsing/uri/002.html http://www.hixie.ch/tests/adhoc/css/parsing/uri/003.html http://www.hixie.ch/tests/adhoc/css/parsing/uri/004.html http://www.hixie.ch/tests/adhoc/css/parsing/uri/005.html ------------------------------------------------------------------------ Issue 148. URI: http://www.w3.org/mid/v8j8s1d49i1vrr8vjktrrnnu3sgr1kpdhc@hive.bjoern.hoehrmann.de Description: CSS 2.1 has http://www.w3.org/TR/CSS21/syndata.html#escaped-characters Third, backslash escapes allow authors to refer to characters they can't easily put in a document. In this case, the backslash is followed by at most six hexadecimal digits (0..9A..F), which stand for the ISO 10646 ([ISO10646]) character with that number, which must not be zero. (It is undefined in CSS 2.1 what happens if a style sheet does contain a zero.) I think at least the second instance of "zero" is misleading, this should probably be ... which must not be U+0000 ... does contain a U+0000 ... though there might be better wording for it. It also notes Backslash escapes are always considered to be part of an identifier or a string (i.e., "\7B" is not punctuation, even though "{" is, and "\32" is allowed at the start of a class name, even though "2" is not). That doesn't seem right as if the escape is not part of STRING or IDENT tokens as defined in the tokenization, it cannot be considered part of any. This basically says that unescaping happens conceptually after parsing and that escapes may occur in places where the literal character would not be allowed. I am not sure how to rephrase it (nor does it seem to be needed) though. Resolution: Edit the first of the above to be clearer that by "zero" we mean the unicode character zero; prepend the word "Note:" at the beginning of the second paragraph he's complaining about, and maybe add ", where allowed, " between "escapes" and "are". Issue closed. ------------------------------------------------------------------------ Issue 149. URI: http://www.w3.org/mid/iak8s156vp3i5r4uc3n0a03g55ijm0mi5n@hive.bjoern.hoehrmann.de Description: Do we have a list of inputs that cannot be tokenized or parsed per CSS 2.1? There should be some specific issues in the list archives, maybe we should keep track of them? In any case, .test { color:green;color\ :red; } should probably be added if it's not there already. It seems this is tokenized as ... IDENT ('color') DELIM ('\') S ('\n') DELIM (:) IDENT ('red') ';' which does not match 'declaration'. It's green in Opera9 and red in Mozilla/IE6. Resolution: No change. Issue closed. ------------------------------------------------------------------------ Issue 150. URI: http://www.w3.org/mid/43C68B95.4070405@mit.edu Description: I'm trying to understand the following paragraph in section 11.1.1 [1]: In the case of a scrollbar being placed on an edge of the element's box, it should be inserted between the inner border edge and the outer padding edge. Any space taken up by the scrollbars should be subtracted from the computed width/height, thus preserving the inner border edge. What does that mean in practice? Specifically, consider the following markup:
Text
And the styles #outer { overflow: auto; height: 200px; width: 200px;} #inner { height: 100%; width: 200%; } Now the "outer" div overflows horizontally, so a horizontal scrollbar has to be inserted. Given that, what is the computed value of "height" for the outer div? Is it 100px? Or is it (100px - 'height of scrollbar')? And more specifically, what is the computed value of "height" for the inner div? Testcase: http://annevankesteren.nl/test/css/temp/002.htm Resolution: The computed value of the outer 'height' is 200px. The computed value of the inner 'height' is 100%. Proposal: 10.3.3: Change 'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-width' + 'margin-right' = width of containing block If 'width' is not 'auto' and 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-width' ...to: 'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-width' + 'margin-right' + scrollbar width (if any) = width of containing block If 'width' is not 'auto' and 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-width' + scrollbar width (if any) Add to the end of that section: The "scrollbar width" value is only relevant if the user agent uses a scrollbar as its scrolling mechanism. See the definition of the 'overflow' property. 10.3.7: Change: 'left' + 'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-width' + 'margin-right' + 'right' = width of containing block ...to: 'left' + 'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-width' + 'margin-right' + 'right' + scrollbar width (if any) = width of containing block Add to the end of that section: The "scrollbar width" value is only relevant if the user agent uses a scrollbar as its scrolling mechanism. See the definition of the 'overflow' property. 10.6.4: Change: 'top' + 'margin-top' + 'border-top-width' + 'padding-top' + 'height' + 'padding-bottom' + 'border-bottom-width' + 'margin-bottom' + 'bottom' = height of containing block ...to: 'top' + 'margin-top' + 'border-top-width' + 'padding-top' + 'height' + 'padding-bottom' + 'border-bottom-width' + 'margin-bottom' + 'bottom' + scrollbar height (if any) = height of containing block Add to the end of that section: The "scrollbar height" value is only relevant if the user agent uses a scrollbar as its scrolling mechanism. See the definition of the 'overflow' property. Change 11.1.1: In the case of a scrollbar being placed on an edge of the element's box, it should be inserted between the inner border edge and the outer padding edge. Any space taken up by the scrollbars should be subtracted from the computed width/height, thus preserving the inner border edge. ...to: In the case of a scrollbar being placed on an edge of the element's box, it should be inserted between the inner border edge and the outer padding edge. The space taken up by the scrollbars affects the computation of the dimensions in the rendering model. Issue closed. ------------------------------------------------------------------------ Issue 151. Description: I was just rereading the CSS 2.1 spec and believe I stumbled across a typo in the Flex tokenizer. string1 \"([^\n\r\f\\"]|\\{nl}|{escape})*\" string2 \'([^\n\r\f\\']|\\{nl}|{escape})*\' invalid1 \"([^\n\r\f\\"]|\\{nl}|{escape})* invalid2 \'([^\n\r\f\\']|\\{nl}|{escape})* In the first part of these rules, shouldn't there be one more or one less backslash before the single and double quotes? For example: (a) if a lone backslash is to be forbidden: [^\n\r\f\\\"] (b) if a lone backslash is to be allowed: [^\n\r\f\"] I would think that option (a) is what's intended. I didn't see anything about this in the changes/errata. Could you please confirm? Nice work on the spec, btw. Thanks, Jared Resolution: Non-issue (no need to escape quotes in [] in flex) Issue closed. ------------------------------------------------------------------------ Issue 152. URI: http://www.w3.org/mid/43D27CCC.9040709@mit.edu URI: http://www.w3.org/mid/21324932.1137881854316.JavaMail.ngmail@webmail-02.arcor-online.net Description: Based on previous discussion [1], I think it's clear the ::first-line pseudo-element is badly underspecified and further that there is no clear idea how to specify it. Given the state it's in, I don't think it's possible to implement it interoperably. Given that, I request that ::first-line be removed from the CSS2.1 specification until such a time as it's better specified. [1] http://lists.w3.org/Archives/Public/www-style/2005Oct/0163.html (see equivalent selectors issue too) Further discussion including a testcase: http://lists.w3.org/Archives/Public/www-style/2006Jan/0209.html Tantek's proposal: Put the ::first-line pseudo inside the inline elements. Paint the background separately, as for an anonymous box around the contents of the first line. Problems that remain with Tantek's proposal: Which background do you use, if ::first-line says "background: inherit"? What do you report for getComputedStyle(element, "::first-line") ? Resolution: Keep as is. ISSUE UNRESOLVED -- INCLUDE IN DISPOSITION OF COMMENTS ------------------------------------------------------------------------ Issue 153. URI: http://www.w3.org/mid/20060201223415.GC24163@ridley.dbaron.org Anne van Kesteren raised as a last-call comment on WICD [1] regarding the sizing of scalable SVG background images (i.e., those that do not provide a size, and may or may not provide an intrinsic ratio). The CDF working group discussed this and concluded [2] that it would be best if this were specified by CSS. Resolution: In section 14.2 add: Intrinsic dimensions expressed as percentages must be resolved relative to the dimensions of the rectangle that establishes the coordinate system for the background-position property. If the image has no intrinsic dimensions and has an intrinsic ratio the dimensions must be assumed to be the largest dimensions at that ratio such that neither dimension exceeds the dimensions of the rectangle that establishes the coordinate system for the background-position property. If the image has no intrinsic ratio either, then the dimensions must be assumed to be the rectangle that establishes the coordinate system for the background-position property. Issue closed. ------------------------------------------------------------------------ Issue 154. URI: http://www.w3.org/mid/9882C98B3C3D9B45A9A5F9EDECE014D8155D13A1@win-msg-01.wingroup.windeploy.ntdev.microsoft.com Description: Resolution: Remove mso, add -ms, simplify table accordingly. Issue closed. ------------------------------------------------------------------------ Issue 155. URI: http://www.w3.org/mid/9882C98B3C3D9B45A9A5F9EDECE014D8155D14D3@win-msg-01.wingroup.windeploy.ntdev.microsoft.com Description: Chapter 10 already says: "CSS2.1 does not define the exact algorithm." That's enough. (Minutes 29 Aug 2006) Resolution: no change Issue closed ------------------------------------------------------------------------ Issue 156. URI: http://www.w3.org/mid/43F1094B.8000702@inkedblade.net URI: http://www.w3.org/mid/43F116DF.90409@inkedblade.net Description: (text-decoration stuff) The issue raised at the may 9th F2F was regarding how to handle underlines near images, specifically whether underlines should go under images when specified on spans that contain text other than the image in question. Resolution: http://lists.w3.org/Archives/Member/w3c-css-wg/2006JulSep/0183.html proposes text to replace 2nd and 3rd para of 16.3.1: | Underlines, overlines, and line-throughs are applied only to text | (including white space, letter spacing, and word spacing): margins, | borders, and padding are skipped. If an element contains no text, | user agents must refrain from rendering these text decorations on the | element. For example, images will not be underlined. | | The 'text-decoration' property on descendant elements cannot have any | effect on the decoration of the ancestor. In determining the position | of and thickness of text decoration lines, user agents may consider the | font sizes of and dominant baselines of descendants, but must use the | same baseline and thickness on each line. Relatively positioning a | descendant moves all text decorations affecting it along with the | descendant's text; it does not affect calculation of the decoration's | initial position on that line. and further down: s/The color of decorations should remain the same/The color of decorations must remain the same/ and: s/as opposed to simply drawing the decoration through the elements/as opposed to preserving a constant thickness and line position/ and in Appendix E, step 6.1.4: s/1. Underline of element./1. Any underlining affecting the text of the element, in tree order of the elements applying the underlining./ s/1. Overline of element./1. Any overlining affecting the text of element, in tree order of the elements applying the overlining./ s/1. Line-through of element./1. Any line-through affecting the text of element, in tree order of the elements applying the line-through./ Issue closed. ------------------------------------------------------------------------ Issue 157. Description: Resolution: Mention in the Changes section that for changes not listed by Changes section, it's recommended that implementors read the disposition of comments. Issue closed. ------------------------------------------------------------------------ Issue 158. Description: 'no-wrap' should be 'nowrap' in 16.6.1:1. Resolution: Editorial. Issue closed. ------------------------------------------------------------------------ Issue 159. Description: fantasai wants 6.4.1:2 to be s/style sheets/declarations/ dbaron wants 6.4.1:4 to be s/rules/declarations/ Resolution: Done. Issue closed. ------------------------------------------------------------------------ Issue 160. URI: http://www.w3.org/mid/9882C98B3C3D9B45A9A5F9EDECE014D815B23950@win-msg-01.wingroup.windeploy.ntdev.microsoft.com Description: selector wording Resolution: Change to "...may only be appended after the last simple selector of the selector" Issue closed. ------------------------------------------------------------------------ Issue 161. URI: http://www.w3.org/mid/9882C98B3C3D9B45A9A5F9EDECE014D8161032A5@win-msg-01.wingroup.windeploy.ntdev.microsoft.com Description: vertical-align and font-size Resolution: Dropped. Issue closed. ------------------------------------------------------------------------ Issue 162. Description: From: Bob Jervis To: "howcome@opera.com" , "ian@hixie.ch" Cc: Markus Mielke The CSS text is sketchy on the issue of line breaks. Is a float a line break opportunity? This came up accidentally in composing a test page where I had something like: Blah blah blahfoo foo foo, more blah blah blah So there is no space between the 'blah' before the span and the ',' afterward. Should a browser (formatting English just to avoid any language-specific issues) ever allow a line break between the word and the comma? Visually, if you have some construct like: Xxxyyyzzz The xxx, yyy and zzz sub-sequences may appear very different, but I could not find a browser that would line break that sequence. Yet, I did find that FireFox 1.5 (I think) does line break at a float. What is the correct behavior? There is language in the spec that says floats should have no effect on vertical layout (relating to block elements in the same flow), but I find no equivalent statement about inline elements and text in the same flow. Resolution: CSS2.1 does not define line breaking opportunity. We all agree that there should be no line break opportunity with floats. Proposed text addition: "A float should not introduce a line break opportunity." Issue closed. ------------------------------------------------------------------------ Issue 163. URI: http://www.w3.org/mid/440C62EC.3080403@mit.edu URI: http://www.w3.org/mid/440D5F48.4080307@peda.net URI: http://www.w3.org/mid/7.0.1.0.2.20060307100207.023631a8@nc.rr.com Description: wording in 10.3.2/10.6.2. bz's suggestions was: If 'height' has a computed value of 'auto', 'width' also has a computed value of 'auto', and the element has an intrinsic height, the intrinsic height is the used value of 'height'. ...and analogously for width. Resolution: We accept the proposal in http://lists.w3.org/Archives/Public/www-style/2006Mar/0014 Issue closed. ------------------------------------------------------------------------ Issue 164. URI: http://www.w3.org/mid/440CFCDC.6030301@inkedblade.net Description: table backgrounds continued Resolution: See 144. Issue closed. ------------------------------------------------------------------------ Issue 165. URI: http://www.w3.org/mid/E1FGhW7-00047U-G6@localhost.localdomain URI: http://www.w3.org/mid/440D7856.2060506@inkedblade.net Description: content: uri(404) Proposal: Change If a user agent cannot display the resource it must ignore it. to If the user agent cannot display the resource it must leave it out as if it were not specified. Counter-proposal: Change If a user agent cannot display the resource it must ignore it. to If the user agent cannot display a resource, it should display some indication that the resource cannot be displayed. Counter-counter-proposal: Change If a user agent cannot display the resource it must ignore it. to nothing. Counter-counter-counter-proposal: Change If a user agent cannot display the resource it must ignore it. to If the user agent cannot display the resource it must either leave it out as if it were not specified or display some indication that the resource cannot be displayed. Resolution: counter-counter-counter-proposal accepted. Issue closed. ------------------------------------------------------------------------ Issue 166. URI: http://www.w3.org/mid/4415FA58.50609@inkedblade.net URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2006JanMar/0240.html Description: - font fallback seems restricted to only one font - Paul notes that UA should be free to pick using any algorithm - UA should be able to do something more intelligent than using the missing glyph glyph; e.g. print box with Unicode hex code - Elika notes that UA should try at least one UA-chosen font before falling back to default glyphs because even though all fonts on system have required glyph, author may have specified a list of fonts that aren't on the system, Resolved: In section 15.2 replace point 5 with: 5. If there is no font within the family selected in 2, then use a UA-dependent default 'font-family' and repeat step 2, using the best match that can be obtained within the default font. If a particular character cannot be displayed using this font, then the UA may use other means to determine a suitable font for that character. The UA should map each character for which it has no suitable font to a visible symbol chosen by the UA, preferably a "missing character" glyph from one of the font faces available to the UA. Resolution: Issue closed. ------------------------------------------------------------------------ Issue 167. URI: http://www.w3.org/mid/o7bn2w0g7oy7x2c.160320061757@pinscher Description: Resolution: Remove "Only properties, values, units, pseudo-classes, pseudo-elements, and at-rules may start with a hyphen (-); other identifiers (e.g. element names, classes, or IDs) may not." in section 4.1.3 bullet 2. Issue closed. ------------------------------------------------------------------------ Issue 168. URI: http://www.w3.org/mid/op.s6xfs2zg64w2qv@id-c0020.oslo.opera.com Description: Minor glossary change. Resolution: Change, in conform.html#intrinsic, In CSS 2.1 it is assumed that all replaced elements, and only replaced elements, come with intrinsic dimensions. ...to: In CSS 2.1 only replaced elements can come with intrinsic dimensions. Issue closed. ------------------------------------------------------------------------ Issue 169. URI: http://www.w3.org/mid/3DE2E6C6-6AB6-4109-AAB2-C2671A132E70@bfo.co.uk Description: Resolution: Remove in 17.5.3: "specifies the height explicitly; the table may thus be taller or shorter than the height of its rows. The 'height' property on 'table' boxes" Issue closed. ------------------------------------------------------------------------ Issue 170. URI: http://www.w3.org/mid/444FAABA.2080104@fgm.com Description: first issue Resolution: Issue closed. ------------------------------------------------------------------------ Issues 171: URI: http://www.w3.org/mid/444FAABA.2080104@fgm.com Description: second issue (9.9.1) Resolution: Editorial: Issue closed. ------------------------------------------------------------------------ Issues 172: URI: http://www.w3.org/mid/444FAABA.2080104@fgm.com Description: third issue (5.8.3) Resolution: Editorial. Issue closed. ------------------------------------------------------------------------ Issues 173: URI: http://www.w3.org/mid/444FAABA.2080104@fgm.com Description: fourth issue (5.11.4) Resolution: Editorial. Issue closed. ------------------------------------------------------------------------ Issues 174: URI: http://www.w3.org/mid/444FAABA.2080104@fgm.com Description: fifth issue (6.4.3) Resolution: Editorial. Hixie suggests changing "count 1 if the selector is a 'style' attribute rather than a selector, 0 otherwise" to "count 1 if the declaration is from a 'style' attribute rather than a rule with a selector, 0 otherwise". Issue closed. ------------------------------------------------------------------------ Issues 175: URI: http://www.w3.org/mid/444FAABA.2080104@fgm.com Description: sixth issue (10.8.1) Resolution: Editorial. Issue closed. ------------------------------------------------------------------------ Issues 176: URI: http://www.w3.org/mid/444FAABA.2080104@fgm.com Description: seventh issue (12.4) Resolution: Editorial. Issue closed. ------------------------------------------------------------------------ Issues 177: URI: http://www.w3.org/mid/444FAABA.2080104@fgm.com Description: Resolution: eighth issue (12.5) Resolution: Editorial. Issue closed. ------------------------------------------------------------------------ Issues 178: URI: http://www.w3.org/mid/444FAABA.2080104@fgm.com Description: ninth issue (16.6.1) Resolution: Editorial Issue closed. ------------------------------------------------------------------------ Issues 179: URI: http://www.w3.org/mid/444FAABA.2080104@fgm.com Description: tenth issue (C.2.6) Resolution: Issue closed. ------------------------------------------------------------------------ Issues 180: URI: http://www.w3.org/mid/op.s8tdjxtdgyx5j1@development2.tatooine.net.au Description: Resolution: Editorial. (I recommend just accepting his text -Hixie.) Issue closed. ------------------------------------------------------------------------ Issue 181. Description: French error. Resolution: Editorial. In 5.11.4, s/fran/Fran/ in the example. Issue closed. ------------------------------------------------------------------------ Issue 182. URI: http://lists.w3.org/Archives/Public/www-style/2006Mar/0106.html Description: References. Resolution: Issue closed. ------------------------------------------------------------------------ Issue 183. Description: How should error handling work in this test?: http://www.hixie.ch/tests/adhoc/css/parsing/uri/007.html Proposed resolution: Make the URI token match this in the two tokenisers: url\({w}{string}{w}\) |url\({w}{string}({escape}|[^)])*\) |url\({w}([!#$%&*-~]|{nonascii}|{escape})*{w}\) |url\(({escape}|[^)])*\) Add in section 4.3.4, after the sentence starting "Some characters", the following: "Specifically, when the URI is unquoted, only the following characters are valid: '!', '#', '$', '%', '&', and all characters in the range '*' to '~' in Unicode, as well as any character above (but not including) U+007F. The '\' character must be handled as descripted in character escapes. Other characters cause the URI token to be malformed. When the URI is quoted, the quoted part must be handled as a string token." Add in section 4.2 a new bullet "Malformed URI tokens": "UAs must handle URI tokens that do not follow the correct URI syntax described in the URLs and URIs section by consuming all characters from the first character that does not match the syntax up to the first unescaped close parenthesis (")"). If the url() contents start with a quote mark, or whitespace followed by a quote mark, the UA must first find the end of the string before consuming characters in this way. (If the string is itself malformed, it must be handled as described below under the unexpected end of string section.) The resulting token must cause the declaration to be ignored as a malformed declaration. If the end of the stylesheet is reached before the matching parenthesis, the URI token construct must be closed as described below in the unexpected end of string section." Resolution: Require reparse. No change to spec. Issue closed. ------------------------------------------------------------------------ Issue 184. URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2006AprJun/0101.html URI: http://www.w3.org/mid/20060511073448.GA4569@ridley.dbaron.org Description: Error in example in 12.4.1. Resolution: Editorial. Issue closed. ------------------------------------------------------------------------ Issue 185. URI: http://www.w3.org/mid/5.1.1.5.2.20060426114009.00c29b40@mailserver.nist.gov Description: Editorial issues from Tim. Resolution: Editorial. Issue closed. ------------------------------------------------------------------------ Issue 186. URI: http://www.w3.org/mid/20060511134503.GA6122@ridley.dbaron.org Description: Resolution: Issue closed. ------------------------------------------------------------------------ Issue 187. URI: http://lists.w3.org/Archives/Public/www-style/2006Apr/0016.html Description: 'overflow', when it's propagated, makes / have weird effects with floats. Resolution: Change the title of: 10.6.6 Block-level, non-replaced elements in normal flow when 'overflow' does not compute to 'visible'; 'inline-block', non-replaced elements; and floating, non-replaced elements ...to: 10.6.6 Complicated cases

This section applies to:

  • Block-level, non-replaced elements in normal flow when 'overflow' does not compute to 'visible' (except if the 'overflow' property's value has been propagated to the viewport).
  • 'Inline-block', non-replaced elements.
  • Floating, non-replaced elements.
Add to section 10.6.3:

This section also applies to block-level non-replaced elements in normal flow when 'overflow' does not compute to 'visible' but has been propagated to the viewport.

Change section 9.4.1 where it says: "Floats, absolutely positioned elements, inline-blocks, table-cells, table-captions, and elements with 'overflow' other than 'visible' establish new block formatting contexts." ...to: "Floats, absolutely positioned elements, inline-blocks, table-cells, table-captions, and elements with 'overflow' other than 'visible' (except when that value has been propagated to the viewport) establish new block formatting contexts." Issue closed. ------------------------------------------------------------------------ Issue 188. URI: http://www.w3.org/mid/20060602211506.GA28317@ridley.dbaron.org Description: should empty-cells affect layout Resolution: No change. Issue closed. ------------------------------------------------------------------------ Issue 189. URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2006JulSep/0036.html Description: Ambiguity in interpreting max-height/max-width when either width or height (but not both) is set. Original proposal: Change text in 10.4, so that constraint table applies as soon as either width or height is auto, as follows: "However, for replaced elements with an intrinsic ratio and at least one value of 'height' or 'width' specified as 'auto', the algorithm is as follows:" Plus analogous change in 10.7. Resolution: Revert the original change and then add clarifications. Issue closed. ------------------------------------------------------------------------ Issue 190. URI: Description: br style rule in sample HTML style sheet needs "white-space: pre" Resolution: not necessary, it's already there. Issue closed. ------------------------------------------------------------------------ Issue 191. URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2006JulSep/0049.html URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2006JulSep/0157.html Description: Appendix E wording for painting canvas background is not very clear. Resolution: "unclipped" should be "over the entire canvas" as with point 1, and "painted at" should be "anchored at" Issue closed. ------------------------------------------------------------------------ Issue 192. URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2006JulSep/0049.html URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2006JulSep/0157.html Description: Appendix E wording (Paragraph starting "for each element in each line box") for painting inlines is not very clear. Proposals: Replace 1. For each element in each line box of the element, in tree order, if any, or if the element is inline-level (note that all elements in line boxes are forcably inline-level), on a per-line-box basis: with   1. For each element in each line box of the element (if any), in tree      order; or if the element is inline-level (note that all elements in line      boxes are forcibly inline-level), on a per-line-box basis: or 1. For each line box of the box (outer loop), and then for each box, in tree order, in that line box (inner loop): or 1. Taking each line box of the box in order, for each box (in tree order) in that line box: or ??? Resolution: Replace 6, 6.1, and 6.2 with: 6. If the element is an inline element that generates a stacking context, then: 1. For each line box that the element is in: 1. Jump to 7.2.1 for the box(es) of the element in that line box (in tree order). 7. Otherwise: first for the element, then for all its in-flow, non-positioned, block-level descendants in tree order: 1. If the element is a block-level replaced element, then the replaced content, atomically. 2. Otherwise, for each line box of that element: 1. For each box that is a child of that element, in that line box, in tree order: [current child list of 6.1] Note: Some of the boxes may have been generated by line splitting or the Unicode bidirectional algorithm. ...then change 6.1.4.4.1 to be 7.2.1.4.4.1 and have it read: "Jump to step 7.2.1 for the box(es) of this element in this line box." ...then change what used to be 6.1.5 and 6.3 to mention "see 10 below" instead of "see 9 below". Issue closed. ------------------------------------------------------------------------ Issue 193. URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2006JulSep/0049.html URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2006JulSep/0157.html Description: Appendix E doesn't seem to address anonymous inlines. Resolution: Change "In this description, "element" refers to both actual elements and pseudo-elements." to "In this description, "element" refers to both actual elements, pseudo-elements, and anonymous boxes." Issue closed. ------------------------------------------------------------------------ Issue 194. URI: http://lists.w3.org/Archives/Public/www-style/2006Sep/0054.html Description: Clarifications to inheritance, cascading, and initial values. Resolution: (checked in by howcome during meeting) Issue closed. ------------------------------------------------------------------------ Issue 195. URI: http://lists.w3.org/Archives/Public/www-style/2006Sep/0202.html Description: Grammar/Tokenization errors Resolution: No change. Issue closed. ------------------------------------------------------------------------ Issue 196. URI: http://lists.w3.org/Archives/Public/www-style/2006Oct/0019.html Description: http://www.w3.org/TR/2006/WD-CSS21-20060411/ui.html#propdef-outline-width says for the computed value of 'outline-width': "'0' if the outline style is 'none' or 'hidden'". But further down it says that 'hidden' is not a legal value for 'outline-style'. Proposal: Remove "or 'hidden'" from the computed-value line. Resolution: Editorial. Issue closed. ------------------------------------------------------------------------ Issue 197. Description: Text of an inline element should be painted in tree order with inline descendants. Resolution: Replace 7.2.1.4.3 and 7.2.1.4.4 with: 3. Then for all the element's in-flow, non-positioned, inline-level children, including anonymous inline elements generated for text inside the element, in tree order: 1. If the element was generated for text, paint the text. 2. Otherwise, jump to 7.1.1. for that element. Issue closed. ------------------------------------------------------------------------ Issue 198. Description: If a rel pos inline contains a block then the block doesn't move along with the rel positioning. Resolution: Add to end of paragraph in 9.2.1.1 beginning with "When an inline box...": When such an inline box is affected by relative positioning, the relative positioning also affects the block box. Issue closed. ------------------------------------------------------------------------ Issue 199. URI: http://www.w3.org/mid/452932DD.7030603@w3.org Description: I just noticed another inconsistency in CSS 2.1 :-( Section 13.3.3 says that the used values of margins at a page break are zero, but section 13.2.1 says that the computed value of margins at the top and bottom of a page are zero (thus not only at a page break and not only the used values.) I'm pretty sure 13.2.1 is wrong. It probably dates from before the introduction of "used value." Resolution: Remove the redundant and incorrect sentence in 13.2.1 that reads: "The computed value of box margins at the top or bottom of the page area is zero." Issue closed. ------------------------------------------------------------------------ Issue 200. Description: Hakon complains about issues-2:11. Resolution: Replace: Unknown media type names must not result in the @media rule or @import rule being ignored. ...with: @media and @import rules with unknown media types are treated as if the unknown media types are not present. e.g. In the following snippet, the rule on the "p" element applies to any UA that uses the 'screen' media type (even though the 'pineapple' type is not known). @media screen, pineapple { p { color: green; } } Issue closed. ------------------------------------------------------------------------ Issue 201. URI: http://www.w3.org/mid/546c6c1c0606251116p566e8660s1de12365b8cadc50@mail.gmail.com Description: I still found some tipographical issues :* there is still HTML 4.0 instead of HTML 4 everywhere else referencing the notes (in selector.html and tables.html) * the doctypes of longdesc are 4.0 Transitional * And that Jan Roland Eriksson has not his name well markuped and miss a span additional-name Resolution: Editorial. Issue closed. ------------------------------------------------------------------------ Issue 202. Description: [derived from #5 in http://lists.w3.org/Archives/Public/www-style/2006Oct/0109.html ] Given:
text

text

text
the spec currently says that only the first "text" should be reversed, but it should really say that the first and third should be. Resolution: # This corresponds to adding a LRO (U+202D; for 'direction: ltr') or RLO # (U+202E; for 'direction: rtl') at the start of the element and a PDF # (U+202C) at the end of the element. Change to This corresponds to adding a LRO (U+202D; for 'direction: ltr') or RLO (U+202E; for 'direction: rtl') at the start of the element or at the start of each anonymous child block box, if any, and a PDF (U+202C) at the end of the element. Issue closed. ------------------------------------------------------------------------ Issue 203. Description: The "Computed value" line for 'text-align' can't be "as specified" for the default value, since the default value can't be specified -- but the default value should be a computed value since we want the default to change with 'direction'. Resolution: Editorial. Issue closed. ------------------------------------------------------------------------