Disposition of comments for the WD of 6 November 2006 of Cascading Style Sheets, level 2 revision 1 as of April 26, 2007.
| Issue | Response |
|---|---|
| 2 | no response |
| 3 | accept |
| 4 | no response |
| 5 | no response |
| 6 | no response |
| 7 | no response |
| 8 | no response |
| 11 | no response |
| 12 | maybe |
| 13 | no response |
| 16 | no response |
| 17 | no response |
| 19 | no response |
| 25 | no response |
| 29 | no response |
| 31 | accept |
| 32 | no response |
(Other issues were either editorial or were internal to the WG.)
no response = no response from commenter since announcing the WG's resolution; maybe = commenter wants more info before deciding; objection = commenter disagrees with the resolution; accept = commenter agrees with resolution.
"A declaration block (also called a declaration block in the following text)..." Remove "(also called a declaration block in the following text)" completely.
Assumed editorial.
Issue closed.
Behavior of blocks that establish a new block formatting context in the presence of floats.
http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0303.html 1. Link the words "may become narrower" in 9.4.1 to the 5th paragraph of 9.5 "Floats" 2. In the first sentence of of that 5th paragraph of 9.5, change "margin box" to "border box" (Issue 21). 3. Add this sentence at the end of that 5th paragraph of 9.5: "They may even make the border box of said element narrower than defined by section 10.3.3. CSS2 does not define when a UA may put said element next to the float or by how much said element may become narrower."
Proposal accepted.
Issue closed.
Why aren't overlapping table cells required?
http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0303.html Leave spec as-is. New proposal: http://lists.w3.org/Archives/Member/w3c-css-wg/2007AprJun/0250.html Add explicitly undefined cases to bullet 5 in 17.5
(After discussing with the Director:) the layout of illegal XHTML
tables (and all similar combinations of rowspan/colspan in other
formats) when rendered with CSS's table properties is explicitly
undefined, as follows:
Change this text in bullet 5 of 17.5
The rectangle must be as far to the left as possible, but it
may not overlap with any other cell box, and must be to the
right of all cells in the same row that are earlier in the
source document. (This constraint holds if the 'direction'
property of the table is 'ltr'; if the 'direction' is 'rtl',
interchange "left" and "right" in the previous sentence.)
to
The rectangle must be as far to the left as possible, but the
part of the cell in the first column it occupies must not
overlap with any other cell box (i.e., a row-spanning cell
starting in a prior row), and the cell must be to the right of
all cells in the same row that are earlier in the source
document. If this position would cause a column-spanning cell
to overlap a row-spanning cell from a prior row, CSS does not
define the results: implementations may either overlap the
cells (as is done in many HTML implementations) or may shift
the later cell to the right to avoid such overlap. (This
constraint holds if the 'direction' property of the table is
'ltr'; if the 'direction' is 'rtl', interchange "left" and
"right" in the previous two sentences.)
Also change the following example and its image caption
correspondingly.
Issue closed.
The Min-Max Issue
Leave spec as-is and continue with image-scaling in CSS3. Add note: Note: In cases where an explicit width or height is set and the other dimension is auto, applying a minimum or maximum constraint on the auto side can cause an over-constrained situation. The spec is clear in the behavior but it might not be what the author expects. The CSS3 image-fit property can be used to obtain different results in this situation.
No normative change, add warning note to authors.
Issue closed.
Test assumes
:before, :after { white-space: pre-line }
is not there, even though it's in the sample style sheet.
Repeat "white-space: pre" on :before, :after in test t1202-counters-17-d.htm
Issue closed.
issues-3.103: Add reference to Unicode Standard, not just ISO10646.
We already reference Unicode.
Issue closed.
issues-3.104: Clarify that CSS reserving all property values and @keywords does not retroactively make invalid SVG 1.0/1.1 documents with external stylesheets.
We already agreed to publish an CSS3 SVG module.
Issue closed.
issues-3.105: RGB colors may be clipped prematurely. http://www.w3.org/Style/Group/css2-src/syndata.html#color-units
(From Bert and Melinda)
1. Replace note after last example in 4.3.6 with
"Note. Mapping or clipping of color values should be done to
the actual device gamut if known (which may be larger or
smaller than 0..255)."
2. In the paragraph before that example, change
"Values outside the device gamut should be clipped"
to
"Values outside the device gamut should be clipped or
mapped into the gamut when the gamut is known."
Proposal accepted.
Issue closed.
issues-3.106: Make reference to CSS3 obviously non-normative.
Assumed editorial. Changed "Implementors should look at CSS3 Lists" to "Implementors are advised to look at CSS3 Lists" in the section "Features at risk" on the cover page.
Issue closed.
Poster has a question about floats in absolutely-positioned elements, apparently can't find answer in spec. If we can't find it either, this is an issue. Otherwise, we just need to post a reply with the answer and add his test cases to the test suite.
http://lists.w3.org/Archives/Public/www-style/2007Feb/0104.html
No change.
Issue closed.
Empty inline elements should act like display: none; (?) [Needs testcase]
Line boxes that contain no text, no spaces, and no in-flow content (such as images, inline blocks or inline tables), and don't end with a line feed must be taken out of flow and not rendered. Inline elements on such line boxes must not be rendered. For the purposes of finding the static position for positioning or position for floats, an anonymous block that acts as a parent of these elements must be assumed to replace the line box.
Line boxes that contain no text, no preserved white space, and no in-flow content (such as images, inline blocks or inline tables), and don't end with a line feed must be taken out of flow and not rendered. Inline elements on such line boxes must not be rendered. The static position and the position for floats is calculated as if such inline elements were anonymous blocks.
Line boxes that contain no text, no preserved white space, no inline elements with non-zero margins, padding, or borders, and no other in-flow content (such as images, inline blocks or inline tables), and don't end with a line feed must be taken out of flow and not rendered. Inline elements on such line boxes must not be rendered. The static position of such inline elements is calculated with respect to an anonymous block that replaces the line box. This anonymous block is the containing block for any descendant floats.
Line boxes that contain no text, no preserved white space, no inline elements with non-zero margins, padding, or borders, and no other in-flow content (such as images, inline blocks or inline tables), and don't end with a line feed must be taken out of flow and not rendered. Inline elements on such line boxes must not be rendered. The static and relatively-positioned position of such inline elements is the static position of an anonymous block that replaces the line box. This anonymous block is the containing block for any descendant floats.
Empty inline elements without padding, margins or borders (and ignored height) on an otherwise empty line box do not participate in rendering. For positioning purposes treat the empty inline as an empty block box.
Line boxes that contain no text, no preserved white space, no inline elements with non-zero margins, padding, or borders, and no other in-flow content (such as images, inline blocks or inline tables), and don't end with a line feed must be treated as zero-height line boxes. For the purposes of margin collapsing, this line box must be ignored.
Proposal 6 accepted for 9.4.2.
Issue closed.
Dissent on change to ignoring broken URIs in 'content'.
Reply: http://lists.w3.org/Archives/Public/www-style/2007Feb/0106.html No change.
No change.
Issue closed.
Definition of replaced element unclear about embedded <svg> elements, uses undefined term "CSS formatter".
Change "CSS formatter" to "CSS formatting model" and either
a) Remove "The rendered content of a replaced element comes
from outside the source document" or
b) Replace it with "The rendered content of a replaced element
is outside the scope of this specification"
Proposal accepted with wordsmithed option b: "How a replaced element's content is rendered is not defined by this specification."
Issue closed.
The third bullet in Section 3.2 says that UA's that render must respect points 1-5. Should this be point 1-6?
Assumed editorial.
Issue closed.
Unclear whether escapes are allowed in !important tokens.
Assumed editorial. Fixed Appendix G to allow escapes. Reply to www-style/Bjoern: http://lists.w3.org/Archives/Public/www-style/2007Feb/0048.html
Issue closed.
Define whether -0 is a non-negative number. (Browsers seem to treat it as non-negative.)
Add "-0 is equivalent to 0 and is not a negative number." to the end of the first paragraph in 4.3.1.
Proposal accepted.
Issue closed.
Replace <list-style-type> with <'list-style-type'> in syndata and generate
Assumed editorial.
Issue closed.
What to do with Unicode escapes above U+10FFFF
A UA should display something, such as a replacement character or a missing glyph character. Bert to add something to either chapter 4 or chapter 15. Actual text added to 4.1.3: If the number is outside the range allowed by Unicode (e.g., "\110000" is above the maximum 10FFFF allowed in current Unicode), the UA may replace the escape with the "replacement character" (U+FFFD). If the character is to be displayed, the UA should show a visible symbol, such as a "missing character" glyph (cf. 15.2, point 5).
Issue closed.
Changes section out-of-sync.
Assumed editorial.
Issue closed.
Should floats be excluded from the margin box or the border box of elements flowing alongside?
Change "The margin box of a table..." to "The border box of a table..." in the 5th paragraph of 9.5. Group is leaning towards accepting this proposal, waiting for feedback from HP (and others who want to think about it) before making it final.
Proposal accepted.
Issue closed.
"Note. After a certain amount of time, user agents may choose to return a visited link to the (unvisited) ':link' state." should be normative.
Replace the note in 5.11.2 by this (normative) paragraph: UAs may return a visited link to the (unvisited) ':link' state at some point.
Issue closed.
Clearly specify handling of unicameral scripts.
In 16.5, replace Conforming user agents may consider the value of 'text-transform' to be 'none' for writing scripts for which there is no transform. by Only characters belonging to bicameral scripts [xyz] are affected. and add a bibliographic reference [xyz] to http://www.unicode.org/reports/tr21/tr21-5.html#Introduction
Issue closed.
We decided a change to the priority rules among possible page breaks, but no action was assigned at the time. So here is the action:
In section 13.3.3, change If the above doesn't provide enough break points to keep content from overflowing the page boxes, then rules B and D are dropped in order to find additional breakpoints. If that still does not lead to sufficient break points, rules A and C are dropped as well, to find still more break points. to If the above doesn't provide enough break points to keep content from overflowing the page boxes, then rules A, B and D are dropped in order to find additional breakpoints. If that still does not lead to sufficient break points, rule C is dropped as well, to find still more break points. (I.e., 'A' should be added to the first paragraph and deleted from the last paragraph.)
Issue closed.
Define what happens to margin/border/padding/text-decoration where element is broken.
(From Bert, modified by Melinda:) http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0303.html Add to the end of 13.3.1: "When a page break splits a box, the box's margins, borders, and padding have no visual effect where the split occurs." or: "When a box is interrupted at the bottom of one page and continued on the top of the next, the box's margins, borders, and padding are not rendered at the bottom and top of the respective pages. Future specifications may define properties to modify this behavior. (At the time of writing, a property 'border-break' [CSS3BG] is under consideration.)"
First proposal accepted.
Issue closed.
This is a request from SVG. Intrinsic ratio is ignored when there is neither intrinsic height or width. Should use available width like for non-replaced blocks where possible and calculate height from ratio. Example (use FF or Opera): SVG image with intrinsic ratio, but no intrinsic size: http://fantasai.inkedblade.net/style/tests/issues/intrinsic-ratio.svg Document with a wide body that includes this image: http://fantasai.inkedblade.net/style/tests/issues/intrinsic-ratio-1
1. Use 300px by 150px. This will help us exit CR, because it's what
implementations do today. It is not what CDF agreed to, and it's
not what CDF or SVG wants.
Text: current text
2. Use available width and intrinsic ratio where possible (fall back
to 300px otherwise). This is not what implementations do today.
It is what SVG wants, what CDF expected the spec to say, and it
is the most useful for authoring.
Text: http://lists.w3.org/Archives/Member/w3c-svg-wg/2006OctDec/0373.html
(+ changes for #3 to handle fallback)
3. Use 300px times intrinsic ratio. This is not what implementations
do today, and it's not what CDF or SVG wants.
Text: Remove "'width' has some other computed value," from the 3rd
paragraph in 10.6.2.
Proposal 2 accepted.
Issue closed.
In 8.3.1 "An element's own margins are adjoining if ... it has neither vertical borders nor vertical padding" Term "vertical borders" and "vertical padding" is confusing.
Replace "vertical" with "top or bottom".
Assumed editorial.
Issue closed.
The informative appendix on aural properties http://www.w3.org/Style/Group/css2-src/aural.html#pause-props says # These properties specify a pause to be observed before (or after) # speaking an element's content. Values have the following meanings: # ... # The pause is inserted between the element's content and any # 'cue-before' or 'cue-after' content. To be consistent with CSS3 Speech, we can replace "an element's content" with "an element's cues and content" and delete the other sentence. Otherwise, we should add a note after that last sentence. Note: In CSS3 pauses are inserted around the cues and content rather than between them. See [CSS3 Speech] for details.
Add note.
Issue closed.
Spec is not clear on whether 'clip'-ed content that would have overflowed should be considered as causing overflow.
Add "Content that has been clipped does not cause overflow" to after "... outside the clipping region" in section 11.1.2
Issue closed.
9.5.2 defines behavior of 'clear' as follows: Computing the clearance of an element on which 'clear' is set is done by first determining the hypothetical position of the element's top border edge within its parent block. This position is determined after the top margin of the element has been *collapsed* with previous adjacent margins (including the top margin of the parent block). If the element's top border edge has not passed the relevant floats, then its clearance is set to the amount necessary to place the border edge of the block even with the bottom outer edge of the lowest float that must be cleared. However 8.3.1 describes collapsing margins as In this specification, the expression collapsing margins means that adjoining margins (no non-empty content, padding or border areas or *clearance* separate them) of two or more boxes (which may be next to one another or nested) combine to form a single margin. This creates a circular reference which makes the two rules contradictory.
In 8.3.1, remove all 5 instances of the word 'clearance' (and whole sentences that are not needed without 'clearance') Note: Clearance was added as a concept at Oslo f2f in 2003. It was added both to 9.5.2 and 8.3.1. However since margin collapsing happens before clearance, it doesn't need to have clearance-related rules.
http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0512.html
http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0535.html
http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0538.html
Ian's text accepted: http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0535.html
Issue closed.
Make XHTML <body> magic like HTML <body>.
6.4.4 paragraph 2: change "For HTML" to "For HTML and XHTML". 11.1.1: Change the sentence "HTML UAs must instead apply the 'overflow' property from the BODY element to the viewport, if the value on the HTML element is 'visible'." to: When the root element is an HTML "HTML" element or an XHTML "html" element, and that element has an HTML "BODY" element or an XHTML "body" element as a child, user agents must instead apply the 'overflow' property from the first such child element to the viewport, if the value on the root element is 'visible'. 14.2 paragraph 4: change to: For HTML documents, however, we recommend that authors specify the background for the BODY element rather than the HTML element. For documents whose root element is an HTML "HTML" element or an XHTML "html" element that 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 element's first HTML "BODY" element or XHTML "body" element child when painting backgrounds for the canvas, and must not paint a background for that child element. Such backgrounds must also be anchored at the same point as they would be if they were painted only for the root element. 17.5 paragraph 2: change the last sentence to: "These rules do not apply to HTML or XHTML; HTML imposes its own limitations on row and column spans." 17.5 final example: This would need various editorial changes to indicate that the second example is not XHTML but some non-HTML XML vocabulary.
http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0538.html
No change at this point.
Mark this behavior at risk.
page-break-inside on child can override parent, but the same isn't true of page-break-before/after
Do nothing. Add a new value in CSS3.
Insert before the last "," in rule B: "and all the blocks contributing to the margin have a 'page-break-inside' value of 'avoid'"
No change.
Issue closed.
Clear may not have the desired effect on the last child of a formatting context.
David proposes http://lists.w3.org/Archives/Public/www-style/2007Apr/0013 maybe modified according to http://lists.w3.org/Archives/Public/www-style/2007Apr/0015 Ian agrees http://lists.w3.org/Archives/Public/www-style/2007Apr/0014
Proposal accepted.
Issue closed.
"margin box" "border box" and "padding box" used but not defined
In section 8.1 Box dimensions, Add to the definition of "margin edge" | The four margin edges define the box's margin box. Add to the definition of "border edge" | The four border edges define the box's border box. Add to the definition of "padding edge" | The four padding edges define the box's padding box. Add to the definition of "content edge" | The four content edges define the box's content box.
Proposal accepted.
Issue closed.
background-position defined by example, not by normative text
See URI.
Proposal accepted.
Issue closed.
"padding area" incorrectly used in place of "padding box"
Assumed editorial.
Issue closed.
Confusion over newlines and line feed
Add after the value definitions in 16.6: "Newlines in the source can be represented by a carriage return (U+000D), a linefeed (U+000A) or both (U+000D U+000A) or by some other mechanism that identifies the beginning and end of document segments, such as the SGML RECORD-START and RECORD-END tokens. The CSS 'white-space' processing model assumes all newlines have been normalized to line feeds."
Issue closed.
Elika writes: [...] the third paragraph of 10.6.2 states the same thing, essentially, three times: # If 'height' and 'width' both have computed values of 'auto' and # the element has no intrinsic height, but does have an intrinsic # width and intrinsic ratio; # or if 'height' has a computed value of 'auto', and the element # does have an intrinsic ratio; # or if 'height' and 'width' both have computed values of 'auto' and # the element has an intrinsic ratio but no intrinsic height or # width and the containing block's width doesn't itself depend on # the replaced element's width; # then the used value of 'height' is: I think we can replace all that with | Otherwise if 'height' has a computed value of 'auto' and the | element does have an intrinsic ratio then the used value of | 'height' is: since that second case covers the other two. Bert agrees and thinks this is editorial.
Assumed editorial.
Issue closed.
"outline-width: thick solid" in example should be "outline: thick solid"
Assumed Editorial.
Issue closed.
Not clear what media style rules that are not qualified by an @media rule apply to.
Add to the end of 7.2.1: Style rules outside of @media rules apply to all media types that the sheet applies to.
Proposal accepted.
Issue closed.
Initial containg block for fixed positioning and absolute positioning don't match.
In 10.1 where it says If the element has 'position: fixed', the containing block is established by the viewport in the case of continuous media or the page box in the case of paged media change "page box" to "page area".
Proposal accepted.
Issue closed.