issues-2

CSS2.1 Post CR Issues List
==========================

This issues list covers issues in the Candidate Recommendation
http://www.w3.org/TR/2004/CR-CSS21-20040225/

   _________________________________________________________________
 ,-----------------------------------------------------------------/|
 | THIS ISSUES LIST IS CLOSED.                                     ||
 |                                                                 ||
 | NO MORE ISSUES WILL BE RESOLVED BEFORE THE CSS2.1 SPECIFICATION ||
 | REACHES LAST CALL. (AGAIN.)                                     ||
 `-----------------------------------------------------------------+'

^Issue ([0-9]+[a-z]*)\.$
^URI: (.+)$
^Description:$ followed by lines of text
^Section: (.+)$
^Rejected.$
^Resolution:$ followed by lines of text
^Reply: (.+)$
^Issue closed.$

------------------------------------------------------------------------
Issue 1.
Description:
Need to add something somewhere to make it clear that vertical margins
on inline elements have no effect and can be ignored.
Resolution:
Add to the definition of "'margin-top', 'margin-bottom'", after the
property table (section 8.3):
| <p class="note">These properties have no effect on non-replaced inline
| elements.</p>
Issue closed.
------------------------------------------------------------------------
Issue 2.
Section: 7.3 Recognized media types
Description:
The spec says:
# Media types are mutually exclusive in the sense that a user agent
# can only support one media type when rendering a document. However,
# user agents may have different modes which support different media
# types.
This makes print-preview non-conformant according to some people.
Resolution:
Accepted.
Internal resolution:
Use text based on these:

<Hixie> Media types are mutually exclusive in the sense that a user agent
<Hixie> can only support one media type per canvas when rendering a
<Hixie> document. Multimodal media types use one canvas. However, user
<Hixie> agents may have different modes which support different media types.
<Hixie>
<Hixie> For example, the 'tv' media type's canvas has an X axis, a Y axis,
<Hixie> and a speech axis, but printing implies two canvases: the screen
<Hixie> canvas, and the print canvas.

<fantasai> Media types are mutually exclusive in the sense that
<fantasai> a user agent can only support one media type per canvas
<fantasai> when rendering a document. However, user agents may have
<fantasai> different modes which support different media types.
<fantasai> Note a multimodal media type is still only one media type.
<fantasai> The 'tv' media type, for example, has an x axis, a y axis,
<fantasai> and a speech axis all as part of a single canvas. Printing,
<fantasai> however, implies two canvases: the screen canvas and the
<fantasai> print canvas.

Issue closed.
------------------------------------------------------------------------
Issue 3.
URI: http://www.w3.org/mid/BC5AAC3E.36B54%25tantek@cs.stanford.edu
Section: 15.2 Font matching algorithm
Resolution:
Change "for the given element" to "for the given element or character".
Issue closed.
------------------------------------------------------------------------
Issue 4.
URI: http://www.w3.org/mid/5B78805D3185784993C473999029D73601150B14@RED-MSG-53.redmond.corp.microsoft.com
Section: 12.2 The 'content' property
Resolution:
Replace "in a block, inline, or marker box" with "in a block or inline box".
Issue closed.
------------------------------------------------------------------------
Issue 5.
URI: http://www.w3.org/mid/5B78805D3185784993C473999029D73601150AAA@RED-MSG-53.redmond.corp.microsoft.com
Section: 12.2 The 'content' property
Resolution:
Replace "Same as 'none', but increments (decrements) the level of
nesting for quotes." with "Introduces no content, but increments
(decrements) the level of nesting for quotes."
Issue closed.
------------------------------------------------------------------------
Issue 6.
Section: 17.6.2 The collapsing border model
URI: http://www.w3.org/mid/Pine.LNX.4.58.0402230022480.13400@dhalsim.dreamhost.com
Description:
We seem to be a little vague on where the table background extends to.

For example, with:

   <table>             table { background: yellow; border: 0.5em solid;
                               border-collapse: collapse; }
    <tr> <td/> </tr>   tr           > td { border: 2em dotted; }
    <tr> <td/> </tr>   tr + tr      > td { border: 1em dotted; }
    <tr> <td/> </tr>   tr + tr + tr > td { border: 3em dotted; }
   </table>

Where does the yellow background go on the second row? There seems to
be only a few options (assuming that later rows coming in
incrementally shouldn't cause the background in earlier rows to
suddenly change extent or origin):

1. Having it extend outside the table on row 2, and only extend
   through half the border on row 3 (i.e. extend as far as the first
   row's border). This is the only option that will look ugly if the
   borders are solid -- the other options all look fine if the border
   is solid.
   http://www.damowmow.com/temp/csswg/css21/issues-cr-issue6-case1

2. Having it extend to half way through the border in all three cases.
   Always looks ugly. Means there is no way to put a background behind
   the complete border of a normal table.
   http://www.damowmow.com/temp/csswg/css21/issues-cr-issue6-case2
   Implemented by: Mozilla (strict mode), Safari, MSN Mac.

3. Having it extend to the table's computed border-width. In this
   case, it would extend 1.25em into the first row's border, 0.75em
   into the second, and 1.75em into the third. That's a straight line,
   half the table's computed border-width from the grid line.
   Simplifies to option 2 when only the cells have borders (not the
   table itself) which is quite common.
   http://www.damowmow.com/temp/csswg/css21/issues-cr-issue6-case3
   Implemented by: Opera.

4. Having it extend to the each row's border edge. This would result
   in an uneven background edge and probably be hard to implement, not
   to mention being an issue with images. It looks cool though. For
   some people.
   http://www.damowmow.com/temp/csswg/css21/issues-cr-issue6-case4

5. Another?
   Implemented by: Mozilla (quirks mode)

Note that case 3 can actually do the effect of case 2, so it is the
most flexible. The other cases can only do their own rendering, and
can't be tweaked to look like the others.

Resolution:
Add the following at the end of 17.6.2 before "Border conflict
resolution":
"CSS2.1 does not define where the edge of a background on a
table element lies."
=hyatt= Edit CSS3 Tables.
Issue closed.
------------------------------------------------------------------------
Issue 7.
Section: 5.12.1 The :first-line pseudo-element
URI: http://lists.w3.org/Archives/Public/www-style/2004Feb/0330.html
Resolution:
Change:
# A UA should act as if the fictional start tag of the first-line
# pseudo-element is just inside the innermost enclosing block-level
# element.
...to:
| A UA should act as if the fictional start tags of the first-line
| pseudo-elements were nested just inside the innermost enclosing
| block-level element.
Issue closed.
------------------------------------------------------------------------
Issue 8.
URI: http://www.w3.org/mid/Pine.LNX.4.58.0402232300580.1475@dhalsim.dreamhost.com
Resolution:
Agreed. |@charset "| followed by the literal charset name, then |";|
Issue closed.
------------------------------------------------------------------------
Issue 9.
Section: 4.4 CSS style sheet representation
URI: http://www.w3.org/mid/1488001767.20040224031102@w3.org
URI: http://www.w3.org/mid/20040224045752.GA32622@darby.dbaron.org
Resolution:
Change section 4.4 from:
# very start of the style sheet, not preceded by any characters,
# except possibly a "BOM" (U+FEFF).
...to:
| very start of the style sheet or immediately after a Byte Order Mark
| (BOM, U+FEFF) that is at the very start of the style sheet.
Issue closed.
------------------------------------------------------------------------
Issue 10.
Section: 4.4.1 Referring to characters not represented in a character encoding
URI: http://www.w3.org/mid/1488001767.20040224031102@w3.org
Rejected.
------------------------------------------------------------------------
Issue 11.
URI: http://www.w3.org/mid/3B206934-6766-11D8-A256-000502CB1B77@stickdog.com
Section: 7.3 Recognized media types
Resolution:
Change "should not" to "must not" in:
# Unknown media type names should not result in the @media rule being
# ignored.
Issue closed.
------------------------------------------------------------------------
Issue 12.
Section: 4.1.3 Characters and case
Description:

This text could definitely be made easier to understand:

# In CSS 2.1, identifiers (including element names, classes, and IDs
# in selectors) can contain only the characters [A-Za-z0-9] and ISO
# 10646 characters U+00A1 and higher, plus the hyphen (-) and the
# underscore (_); they cannot start with a digit. 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.

To highlight the relevant parts:

# In CSS 2.1, identifiers (including element names, classes, and IDs
# in selectors) can contain [...] the hyphen [...]. Only [...] may
# start with a hyphen (-); other identifiers (e.g. element names,
# classes, or IDs) may not.

Sure, the text is technically correct, but...

Proposal:
Just strike the first "(including element names, classes, and IDs in
selectors)".

Resolution:
Emphasise the second occurance of "start" in:
# In CSS 2.1, identifiers (including element names, classes, and IDs
# in selectors) can contain only the characters [A-Za-z0-9] and ISO
# 10646 characters U+00A1 and higher, plus the hyphen (-) and the
# underscore (_); they cannot start with a digit. 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.

Issue closed.
------------------------------------------------------------------------
Issue 13.
URI: http://www.w3.org/mid/Pine.GSO.3.96.1040227131149.8909F-100000@rmi-sun.rmi.acnet.ge
Resolution:
Change the Changes chapter.
Issue closed.
------------------------------------------------------------------------
Issue 14.
Section: 16.6 Whitespace: the 'white-space' property
Description:
The link in:
# This property declares how _whitespace_ inside the element is handled.
...should be removed (it links to the grammar definition of
whitespace!).
Resolution:
Agreed.
Issue closed.
------------------------------------------------------------------------
Issue 15.
Description:
Kimberly should either be an editor or an acknowledged.
Resolution:
Acknowledge.
Issue closed.
------------------------------------------------------------------------
Issue 16.
Section: 16.6.1 The 'white-space' processing model, step 1
Description:
# Each non-linefeed whitespace character surrounding a linefeed
# character is removed if 'white-space' is set to 'normal', 'no-wrap',
# or 'pre-line'.
...should define "whitespace", or, better, just list which characters
it means. Ian thinks it is just U+0020 and U+0009.
Resolution:
Change the above paragraph in 16.6.1 The 'white-space' processing
model, step 1 to:
# Each tab (U+0009), carriage return (U+000D), or space (U+0020)
# character surrounding a linefeed (U+000A) character is removed if
# 'white-space' is set to 'normal', 'no-wrap', or 'pre-line'.
Issue closed.
------------------------------------------------------------------------
Issue 17.
Section: 12.5.1 Lists: the 'list-style-type', 'list-style-image', 'list-style-position', and 'list-style' properties
Description:
Should armenian, georgian, lower-greek be removed.
Resolution: 
Maybe.

Add, to the status section:

<h3>Features at risk</h3>
<p>The working group has identified the following features as being
currently poorly implemented by UAs. They are therefore most at risk
of being removed from CSS2.1 when exiting CR. (Any changes of this
nature will still result in the specification being returned to last
call.) Implementors are urged to implement these features, or correct
bugs in their implementations, if they wish to see this feature remain
in this specification.</p>
<dl>
 <dt>New 'list-style-type' values</dt>
 <dd>
  <ul>
   <li>'armenian'</li>
   <li>'georgian'</li>
   <li>'lower-greek'</li>
  </ul>
  <p>Implementors should look at CSS3 Lists instead, where these and
  many other new values not found in CSS1 are defined in detail.
  [[CSS3LISTS]]</p>
 </dd>
</dl>

Remove from 12.5.1:
# A user agent that does not recognize a numbering system should use
# 'decimal'.
Issue closed.
------------------------------------------------------------------------
Issue 18.
Description:
<fantasai> There's a section that says that margins, borders, and
padding of /non-replaced/ elements do /not/ enter into the line box
calculation, but I can't find the section that says margins, borders,
and padding on replaced elements do.
<dbaron> This is clear in CSS1, section 4.4, paragraph 5: "Replaced
elements (e.g. images) on the line can make the line-box bigger, if
the top of the replaced element (i.e., including all of its padding,
border and margin) is above the tallest text section, or if the bottom
is below the lowest."
Resolution:

Edit "10.6.1 Inline, non-replaced elements":

| But only the 'line-height' is used to calculate the height of the
| line box.

...to:

| But only the 'line-height' is used when calculating the height of
| the line box.

Add to "10.6.2 Inline replaced elements, block-level replaced elements
in normal flow, 'inline-block' replaced elements in normal flow and
floating replaced elements":

| For 'inline' and 'inline-block' elements, the margin box is used when
| calculating the height of the line box.

Add to "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":

| For 'inline-block' elements, the margin box is used when calculating
| the height of the line box.

Issue closed.
------------------------------------------------------------------------
Issue 19. http://www.w3.org/mid/3F875337.6080406@escape.com
Section: 5.8.2 Default Attributes
Description:
#    EXAMPLE { /*... default property settings ...*/ }
# Because this selector is less specific than an attribute selector,
# it will only be used for the default case.
This is false. The selector will be used for all cases, not just the
default case. If a declaration from this rule conflicts with one from
a more specific rule, then it will be overridden--but the declaration
still applies.
Resolution:
Replace the entire example in 5.8.2 Default Attributes with the
example in:
http://lists.w3.org/Archives/Public/www-style/2004Feb/0391.html
Issue closed.
------------------------------------------------------------------------
Issue 20. http://lists.w3.org/Archives/Public/www-style/2003Nov/0021.html
Section: 16.6.2 Example of bidirectionality with white-space collapsing
Description:
This is wrong:
# This is best avoided by using the natural bidirectionality of
# characters instead of explicit embedding levels.
Richard Ishida was looking at this.
Resolution:
Replace the above with:
"This can sometimes be avoided by using the natural bidirectionality
of characters instead of explicit embedding levels. Also, it is good
to avoid spaces immediately inside start and end tags, as these tend
to do weird things when dealing with white space collapsing."
=fantasai= If that isn't good enough, please provide examples and
we'll open a new issue.
Issue closed.
------------------------------------------------------------------------
Issue 21. 
Section: 4.4 CSS style sheet representation
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2004JanMar/0288.html
Description:
Define how the BOM and @charset should work.
Issue closed.
------------------------------------------------------------------------
Issue 22.
Section: 3.2 Conformance
Description:
It's unclear that CSS requires that UAs let authors disable all author
stylesheets.
Issue closed.
------------------------------------------------------------------------
Issue 23.
Section: 4.1.3 Characters and case
Description:
# 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.
So what if it _is_ zero? What does that parse as?
Resolution:
Add a warning note in CSS2.1.
In CSS3, say that \0 (an escape of character 0) is simply ignored, so
blockquote and block\0quote are exactly equivalent.
=dbaron= Edit CSS3.
Issue closed.
------------------------------------------------------------------------
Issue 24.
URI: http://bugzilla.mozilla.org/show_bug.cgi?id=182748
URI: http://www.w3.org/mid/20050223233244.GA555@ridley.dbaron.org
Description:
I suspect the spec should probably be changed to
add the paragraph that's in 10.3.3:

  If 'width' is not 'auto' and 'border-left-width' +
  'padding-left' + 'width' + 'padding-right' +
  'border-right-width' (plus any of 'margin-left' or
  'margin-right' that are not 'auto') is larger than
  the width of the containing block, then any 'auto'
  values for 'margin-left' or 'margin-right' are, for
  the following rules, treated as zero.

...to other places.
dbaron has sent further details, see second URI.
Resolution:
Change the text within 10.3.7:

# If both 'margin-left' and 'margin-right' are 'auto', solve the
# equation under the extra constraint that the two margins get equal
# values.

to be:

: If both 'margin-left' and 'margin-right' are 'auto', solve the
: equation under the extra constraint that the two margins get equal
: values, unless this would make them negative, in which case when
: direction is 'ltr' ('rtl'), set 'margin-left' ('margin-right') to zero
: and solve for 'margin-right' ('margin-left').

And change the text within 10.3.8:

# 4. If at this point both 'margin-left' and 'margin-right' are still
# 'auto', solve the equation under the extra constraint that the two
# margins must get equal values. 

to be:

: 4. If at this point both 'margin-left' and 'margin-right' are still
: 'auto', solve the equation under the extra constraint that the two
: margins must get equal values, unless this would make them negative,
: in which case when direction is 'ltr' ('rtl'), set 'margin-left'
: ('margin-right') to zero and solve for 'margin-right' ('margin-left').

Issue closed.
------------------------------------------------------------------------
Issue 25.
Description:
howcome says the text for "Used values" is a bit arcane.
Resolution:
Edit to say:
  Computed values are processed as far as possible without formatting
  the document. Some values, however, can only be determined when the
  document is being laid out. For example, if the width of an element is
  set to be a certain percentage of its containing block, the width
  cannot be determined until the width of the containing block has been
  determined. The <dfn id="usedValue">used value</dfn> is the result of
  taking the computed value and resolving any remaining dependencies
  into an absolute value.
Issue closed.
------------------------------------------------------------------------
Issue 26.
Section: 11.1.2 Clipping: the 'clip' property
Description:
We forgot to update the intro text. It still says:
# By default, the clipping region has the same size and shape as the
# element's border box.
It should say:
# By default, the element is not clipped.
Issue closed,
------------------------------------------------------------------------
Issue 27.
Description:
<exclipy> In CSS2.1:12.5.1, the list-style-type values "lower-alpha"
and "upper-alpha" aren't listed formally.
Issue closed.
------------------------------------------------------------------------
Issue 28.
Description:
There is a diagram in the text-decoration section that became out of
sync with the prose during editing.
Resolution:
Update text so that the sentence in "16.3.1 Underlining,
overlining, striking, and blinking: the 'text-decoration' property"
that reads "The <em>text</em> in the em block is not underlined at
all, as it is not contained in the same anonymous inline element." is
changed to read "The <em>text</em> in the em block is also underlined,
as it is in an in-flow block to which the underline is propagated."
(or similar) then update the image to be:
   http://www.damowmow.com/temp/csswg/css21/underline-example.png
Issue closed.
------------------------------------------------------------------------
Issue 29.
Description:
empty-cells is too vaguely specified. Does a zero-height zero-width
image could as visible content? What if it is display:inline and thus
creates a line box? What about an empty block with no background,
border, padding, height, or width? What about... etc.
Proposal:
A cell is empty if it contains nothing but the whitespace characters
currently listed _and_ white-space would collapse those characters so
that they don't form a line box. Any other textual or element content
counts as visible content. (I assume we don't have to say anything
about PIs or comments, I mean, those obviously don't affect rendering
right? -Ian)

<Hixie> "cells are empty if they contain no in-flow nor floating
content other than whitespace that has been collapsed away by the
white-space property handling"?

Tests: http://www.hixie.ch/tests/adhoc/css/box/table/empty-cells/

Resolution:
Accepted.

Change this text in 17.6.1:

# Visible content includes "&nbsp;" and other whitespace except ASCII
# CR ("\0D"), LF ("\0A"), tab ("\09"), and space ("\20").

...so that it says:

  Cells are empty unless they contain one or more of the following:
    * floating content (including empty elements),
    * in-flow content (including empty elements) other than whitespace
      that has been collapsed away by the white-space property handling.

(Group agreed that cells are empty if they contain no in-flow nor
floating content other than whitespace that has been collapsed away by
the white-space property handling.)

Issue closed.
------------------------------------------------------------------------
Issue 30.
Description:
From CSSWG telecon minutes:
     "explicitly state somewhere in media.html that unknown
      identifiers are parseable in media lists (e.g.
         @media blarg, screen, blorg { p { color: green; } }
      should make p elements green for screen media)."
Issue closed.
------------------------------------------------------------------------
Issue 31.
URI: http://www.w3.org/mid/20040412233323.GA5478@darby.dbaron.org
Description:
I think it should be specified what happens when a stylesheet
specifies the same counter more than once in the value of the
'counter-increment' and 'counter-reset' properties. -dbaron
(See URI for details.)
Resolution:
They all get applied (so for counter-reset, the last one takes
effect).
Specifically, replace:

  If the same counter is specified more than once in the value of the
  'counter-reset' and 'counter-increment' properties, all counters are
  processed in the order specified.

...with:

  If the same counter is specified more than once in the value of the
  'counter-reset' and 'counter-increment' properties, each mention of
  the counter is processed (in the order specified).

Isue closed.
------------------------------------------------------------------------
Issue 32.
URI: http://www.w3.org/mid/1940625.20040411235142@w3.org
Description:
Alfonso Martinez pointed out that according to the CSS 2.1
recommendation, lower-greek is an alphabetic system, not a
numbering system, which -- to my surprise -- is true.

As is clear, from my bug report filing, lower-greek should be
reclassified as a numbering system, and handled accordingly,
by www browsers.
Resolution:
Keep lower-greek as alphabetic; in CSS3 we may have 'greek', if
someone can give us an algorithm.
Issue closed.
------------------------------------------------------------------------
Issue 33.
URI: http://www.w3.org/mid/4082CF57.9060709@mit.edu
Resolution:
In "10.8.1 Leading and half-leading" change "The minimum height
consist" to "The minimal height consists". In "10.8 Line height
calculations: the 'line-height' and 'vertical-align' properties", add
a fourth list item that is:
  <li>If the resulting height is smaller than the minimal height of
  line boxes for this block, as specified by the
  <...>line-height</...> property, the height is increased to be that
  minimal height.</li>
Issue closed.
------------------------------------------------------------------------
Issue 34.
URI: http://www.w3.org/mid/5B78805D3185784993C473999029D736016D684D@RED-MSG-53.redmond.corp.microsoft.com
Resolution:
Move the paragraph in "17.5.1 Table layers and transparency" after the
list in that section starting "The edges of the rows, columns, ...",
up to section "17.5 Visual layout of table contents", after the list
but before the note.
Then, change "sets" to "determines" in item 2 of the list in section
"Fixed table layout" in section "17.5.2 Table width algorithms: the
'table-layout' property".
Issue closed.
------------------------------------------------------------------------
Issue 35.
URI: http://www.w3.org/mid/4084367E.2020701@mit.edu
Resolution:
Add, after:
| If the letters that would form the first-letter are not in the same
| element, such as "'T" in <p>'<em>T..., the UA may create a
| first-letter pseudo-element from one of the elements, both elements,
| or simply not create a pseudo-element.
...the following:
| Similarly, if the first letter(s) of the block are not at the start
| of the line (for example due to bidirectional reordering), then the
| UA need not create the pseudo-element(s).
Issue closed.
------------------------------------------------------------------------
Issue 36.
URI: http://www.w3.org/mid/BC9B67BC.3A945%25tantek@cs.stanford.edu
Resolution:
Change "only one" in 10.3.8 Absolutely positioned, replaced
elements, subitem 6, to "an".
Issue closed.
------------------------------------------------------------------------
Issue 37.
Description:
(From: Felipe Gasper <fgasper@freeshell.org>)

I am designing a web application for managing accounting data. To
prevent users from "instinctively" holding SHIFT to capitalize, I am
capitalizing all text displayed in form elements (input[type='text']
{text-transform: uppercase}). This, of course, has no effect on the
*actual* data passed to the application server.

This technique works in Gecko and IE, but KHTML (both Konqueror and
Safari) ignores this CSS property of the <input> tag, presumably
because, technically, this is not "enclosed" text as the specification
seems to point out.

Perhaps some stipulation should be added to the CSS spec regarding
this useful property?

Resolution:

Specification says:
# CSS2.1 does not define which properties apply to form controls and
# frames

...which is good enough.

Issue closed.
------------------------------------------------------------------------
Issue 38.
URI: http://www.w3.org/mid/20040310010513.GA11213@darby.dbaron.org
Resolution:
Add to 6.2.1 "The 'inherit' value" some text that says that 'inherit'
on the root element is equivalent to using the initial value.
Issue closed.
------------------------------------------------------------------------
Issue 39.
URI: http://www.w3.org/mid/4058A078.9413.47C932@localhost
Resolution:

Add "Note: This may cause the containing block's width to be
negative." in section 10.1, as a paragraph of subitem 1 of item 4,
under subitem 2 of subitem 1 of item 4.

Add "If the containing block's width is negative, the used value is
zero." to the definition of <percentage> in 'min-width' in 10.4.

Issue closed.
------------------------------------------------------------------------
Issue 40.
URI: http://www.w3.org/mid/5365489$10804178564065de40129434.27614134@config21.schlund.de
Description:
1. Recomended line-height

The default style sheet for HTML contains this:
  body { line-height: 1.12 }.
But what all popular UAs use is  line-height: 1.2  -isn't it?
This sentence about line-height (section 10.8.1)
  "We recommend a used value for 'normal' between 1.0 to 1.2."
should be matched to the recomended value of appendix D.

Resolution:
Remove the line that says
  body { line-height: 1.12 }
Issue closed.
------------------------------------------------------------------------
Issue 41.
URI: http://www.w3.org/mid/5365489$10804178564065de40129434.27614134@config21.schlund.de
Description:
2. Recomended font-size of headings, scaling factors for font-size

There are significant differences between appendix D and section 15.7.
The font-sizes of headings don't match.

section 15.7
font-size      xx-small x-small small  medium  large  x-large xx-large
<font size>    1                2       3      4       5        6
heading        h6       --      h5      h4     h3      h2       h1
scaling factor 0.60     0.75    0.89    1.0    1.20    1.50     2.0
appendix D     0.75em   --      0.83em  1.0em  1.17em  1.50em   2.0em

And think on something like this:
<body style="font-size:40px">
<h2 style="font-size:x-large">heading</h2>
<p>text</p>
On an average screen this h2 may have a font size of 24px, while the
text is larger. Headings should be sized relatively, like in appendix D,
and not absolutely, like section 15.7. may suggest. Throw it out here,
it's confusing.

I don't like the scaling factors of section 15.7. Is this really a
reflection of current implementations? 0.89 seems me to big and 0.60 to
small.

This may be a consistent compromise:
section 15.7
font-size      xx-small x-small small  medium  large  x-large xx-large
<font size>     1       --      2       3      4       5        6
scaling factor  0.60    0.72    0.85    1.0    1.20    1.50     2.0
appendix D              h6      h5      h4     h3      h2       h1
font-size               0.72em  0.85em  1.0em  1.20em  1.50em   2.0em

Or this range:  0.62    0.73    0.85    1.0    1.17    1.5      2.0

Proposed Resolution (Boston F2F):
Remove the HTML headings row of the table in 15.7 and remove the
mention of headings in the paragraph before it.
Disagreed by Tantek.
See also: http://www.w3.org/mid/20040701233052.GA12236@darby.dbaron.org
Testcase: http://dbaron.org/css/test/2004/font-size-table

From testing in IE6, FF0.8, and Opera7.53 -

------------+----------+---------+-------+--------+-------+---------+---------
Keyword     | xx-small | x-small | small | medium | large | x-large | xx-large
Proportion  | 5/9      | 7/9     | 9/11  | 1      | 6/5   | 3/2     | 2/1
Heading     | --       | H6      | H5    | H4     | H3    | H2      | H1
<font> size | --       | 1       | 2     | 3      | 4     | 5       | 6
------------+----------+---------+-------+--------+-------+---------+---------

using David Baron's test case
http://dbaron.org/css/test/2004/font-size-table

Resolution:
Replace the table with a remark that a fixed ratio has given problems
in the past and that implementors are encouraged to build a table that
takes into account the medium font size of the user and the device it
is being displayed on and the resolution of the device.
Leave Appendix D as is.
Issue closed.
------------------------------------------------------------------------
Issue 42.
URI: http://www.w3.org/mid/5365489$10804178564065de40129434.27614134@config21.schlund.de
Description:
3. I'm missing img in appendix D.
Shouldn't img have display:inline-block like object?
Resolution:
Remove 'object' from the 'inline-block' rule.
Issue closed.
------------------------------------------------------------------------
Issue 43.
URI: http://www.w3.org/mid/5365489$10804178564065de40129434.27614134@config21.schlund.de
Description:
4. btw...
I found "CSS2" where "CSS 2.1" should be used:
12.4    Automatic numbering in CSS2 is controlled...
13.3.5  CSS2 does not define...
        CSS2 does not forbid a user agent...
        But CSS2 does recommend that...
        ... just like normal CSS2 declarations.
18      18.2 CSS2 System Colors
18.2    Note. The CSS2 System Colors...
        ...etc., CSS2 introduced...
Full Table of Contents 18.2  CSS2 System Colors
Resolution:
Chapter 18 is correct. The other two aren't though:
Edit section 12.4 to say CSS2.1 instead of CSS2.
Edit section 13.3.5 to say CSS2.1 instead of CSS2.
Issue closed.
------------------------------------------------------------------------
Issue 44.
URI: http://www.w3.org/mid/5365489$10804178564065de40129434.27614134@config21.schlund.de
Description:
5. btw...
section 4.1.2: -khtml- is a known vendor-specific extension too.
Resolution:
Do nothing.
Issue closed.
------------------------------------------------------------------------
Issue 45.
URI: http://www.w3.org/mid/20040504012730.GA8545@darby.dbaron.org
Resolution:
Add:

   The width of the table is the distance from the left inner padding
   edge to the right inner padding edge (including the border spacing
   but excluding padding and border).

   However, in HTML and XHTML, the the width of the <table> element is
   the distance from the left border edge to the right border edge.

   Note: In CSS3 this peculiar requirement will be defined in terms of
   UA stylesheet rules and the 'box-sizing' property.

...after the second normative paragraph in 17.6.1 "The separated
borders model".

Issue closed.
------------------------------------------------------------------------
Issue 46.
URI: http://www.w3.org/mid/BCBC55C3.3CFAB%25tantek@cs.stanford.edu
Description:
In 'outline-color', in the final note, the outline is refered to as
"focus outline." I thought at first that this was another, independent
outline, so maybe the word "focus" should be dropped.
Issue closed.
------------------------------------------------------------------------
Issue 47.
URI: http://www.w3.org/mid/408AC1C4.4060106@mit.edu
Resolution:
No change.
Issue closed.
------------------------------------------------------------------------
Issue 48.
Section: 15.3 Font family: the 'font-family' property
Description:
We should say that <family-name> cannot start with a '/', so that
'font' parsing is non-ambiguous.
Resolution:
Change "Similarly, quote marks, semicolons, exclamation marks and
commas within unquoted font family names must be escaped." to
"Similarly, quote marks, semicolons, exclamation marks, commas and
leading slashes within unquoted font family names must be escaped." in
"15.3 Font family: the 'font-family' property".
Issue closed.
------------------------------------------------------------------------
Issue 49.
Description:
The grammar for 'property' doesn't allow for nested blocks which means
that font-family isn't described by the grammar.
Resolution:
Remove "either balanced or" from "15.3 Font family: the 'font-family'
property".
Issue closed.
------------------------------------------------------------------------
Issue 50.
Description:
Should we say that 'overflow' on the root element applies to the
viewport instead of the root element?
Resolution:
Change, in section 11.1.1 "Overflow: the 'overflow' property": 
# HTML UAs may apply the overflow property from the BODY or HTML
# elements to the viewport.
...to:
# UAs may apply the 'overflow' property set on the root element to
# the viewport (instead of the root element). HTML UAs may also apply
# the 'overflow' property from the BODY element to the viewport.
Issue closed.
------------------------------------------------------------------------
Issue 51.
Description:
Should the description of the property tables be normative?
Resolution:
Remove "In this section, we begin the formal specification of CSS 2.1,
starting with the contract between authors, users, and implementors."
from section 3.1.
Issue closed.
------------------------------------------------------------------------
Issue 52.
Description:
CSS2.1 should clarify the ability for implementations and
specifications to extend the CSS language.
Resolution:
Add:
| CSS2.1 reserves for future versions of CSS all property:value
| combinations and @-keywords that do not contain an identifier
| beginning with dash or underscore. Implementations MUST ignore such
| combinations (other than those introduced by future versions of
| CSS).
...at an appropriate place in chapter 4 (e.g. first paragraph of 4.2,
or in 4.1).
Issue closed.
------------------------------------------------------------------------
Issue 53.
Description:
(raised at the workshop on compound documents)
Does a line breaking opportunity exist between two replaced elements?
Does a line breaking opportunity exist between two inline-blocks?
Does a line breaking opportunity exist between a character and one of
the above?
Assume no characters that allow line breaking are otherwise present.
Tests: http://dbaron.org/css/test/2003/line-breaking/
Tests: http://fantasai.inkedblade.net/style/tests/ad-hoc/line-breaking/objects/
Resolution:
Move to CSS3 and needs a formal proposal.

Add a note saying that "Note: CSS 2.1 does not fully define where line
breaking opportunities occur." to the end of section 16.6.1 The
'white-space' processing model.
Issue closed.
------------------------------------------------------------------------
Issue 54.
URI: http://lists.w3.org/Archives/Public/www-style/2004Mar/0178.html
Resolution:
Ian to reply.
Done: http://www.w3.org/mid/Pine.LNX.4.61.0503292104530.25644@dhalsim.dreamhost.com
Issue closed.
------------------------------------------------------------------------
Issue 55.
URI: http://lists.w3.org/Archives/Public/www-style/2004Jun/0013.html
Description:
  1. According to chapter 4 in CSS 2.1, identifiers may
     now begin with '-'. However, the lexical scanner in
     Appendix G.2 has not been updated to reflect this change.
Resolution:
Bert to propose changes.
Issue closed.
------------------------------------------------------------------------
Issue 56.
URI: http://lists.w3.org/Archives/Public/www-style/2004Jun/0013.html
Description:
  2. In section 4.1.3 it says about identifiers:
       "... they cannot start with a digit."
     Shouldn't this be:
       "... they cannot start with a digit, or a '-' followed by a digit."
Resolution:
Editorial.
Issue closed.
------------------------------------------------------------------------
Issue 57.
URI: http://lists.w3.org/Archives/Public/www-style/2004Jun/0013.html
Description:
  3. The grammar in Appendix G.1 states that function values
     may be prefixed with a unary operator, that is, '+' or '-'.
     But with the introduction of identifiers that start with '-',
     it will no longer be possible to prefix functions with '-'.
     Any attempt to do so will only cause the '-' to be considered
     part of the function name. In other words, this syntax:
       -myfunc(x)
     will be tokenized as:
       FUNCTION, IDENT, ')'
     rather than
       '-', FUNCTION, IDENT, ')'

     As far as I know there are no functions in CSS 2.1 that it would
     make sense to prefix with a minus sign, but apparently such functions
     (representing length values, for example) may be introduced in CSS3?
     (Note, that it will not help to say that function names cannot start
      with '-', because the tokenizer will still see the '-' as part of
      the identifier, and the example above will yield:
        IDENT, '(', IDENT, ')'
      which will likely cause a parsing error.)
Resolution:
Bert to propose changes.
Issue closed.
------------------------------------------------------------------------
Issue 58.
URI: http://lists.w3.org/Archives/Public/www-style/2004Jun/0013.html
Description:
  4. Another change in the lexical scanner in CSS 2.1 is that some tokens
     are defined to include their preceding white space (for example LBRACE).
     This, together with the change that the production 'simple_selector'
     no longer ends with S*, means that, for example, the following syntax
     is no longer valid:
        P  /* A comment */  { color: red }
     because this will tokenize as:
        IDENT, S, LBRACE, S, IDENT, ':', S, IDENT, S, '}'
     and the grammar does not allow the first S. (According to section
     4.1.9, comments only occur between tokens, so the space before the
     comment will not be seen as part of the LBRACE token.)
Resolution:
Bert to propose changes.
Issue closed.
------------------------------------------------------------------------
Issue 59.
URI: http://lists.w3.org/Archives/Public/www-style/2004Jun/0013.html
Description:
  5. The token UNICODERANGE has been removed from the lexical scanner,
     and also from the grammar. However, the 'range' definition is still
     present in the lexical scanner, but is no longer used anywhere. Also,
     the UNICODE-RANGE token is defined in section 4.1.1. Should it be in
     the grammar or not?
Resolution:
Editorial.
Issue closed.
------------------------------------------------------------------------
Issue 60.
URI: http://lists.w3.org/Archives/Public/www-style/2004Jun/0013.html
Description:
  6. In the lexical scanner in Appendix G.2, nmstart only allows lower case
     letters.
Resolution:
nmchar shouldn't mention capital letters, since CSS is case insensitive,
as described ten lines above.
Issue closed.
------------------------------------------------------------------------
Issue 61.
URI: http://www.w3.org/mid/20040603211503.GA3727@darby.dbaron.org
Description:
Agreed to: The margin box of a table<ins>, a block-level replaced
element,</ins> or an element...
Issue closed.
------------------------------------------------------------------------
Issue 62.
Description:
It was pointed out to me that one of the two allowed renderings for
'outline' makes no sense when you have an inline that has borders:
   http://bugzilla.mozilla.org/attachment.cgi?id=152121&action=view
I think we want to have inline outlines be rendered when the block's
outline is rendered. Specifically, move E.6.1.5 to before E.6.3 and
make it read "Optionally, for each element in each line box of the
element, if any, or if the element is inline-level, on a per-line-box
basis, the outline of the element (see 9 below).". -Ian
Resolution:
We really just want step 9, but we have interoperable implementations
of both current alternatives, so leave it.
Issue closed.
------------------------------------------------------------------------
Issue 63.
Description:
"It's under 17.6.3 Border styles - definition of 'ridge', groove is
spelt as grove."
Resolution:
Issue closed.
------------------------------------------------------------------------
Issue 64.
URI: http://www.w3.org/mid/20040714233023.C30F3A1AD7@frink.w3.org
Description:
(Should network errors be ignored?)
Resolution:
Out of scope for CSS, should be defined by network layer spec (e.g.
HTTP).
Issue closed.
------------------------------------------------------------------------
Issue 65.
URI: http://www.w3.org/mid/20040714233027.EFE3AA1AE3@frink.w3.org
Description:
(Should we require some encodings?)
Resolution:
Require UTF-8 support (replace "This specification does not
mandate..." sentence).
Issue closed.
------------------------------------------------------------------------
Issue 66.
URI: http://www.w3.org/mid/20040715030827.66292A19C0@frink.w3.org
Description:
(What should UA do with stylesheet in unknown encoding?)
Resolution:
Ignore stylesheets in unknown encodings.
Issue closed.
------------------------------------------------------------------------
Issue 67.
URI: http://www.w3.org/mid/20040715042015.8937FA1B84@frink.w3.org
Description:
In section 6.4.1, the spec says "It is therefore important that the user
agent give the user the ability to turn off the influence of a certain style
sheet, e.g., through a pull-down menu."

Is this a requirement, or not?  It doesn't match the RFC2119 terminology
specified in section 3.1, but it is marked as being "important."

Also, it's not clear to which specific style sheet(s) the "certain style
sheet" phrase refers.  I would guess, the user style sheet, but it may mean
all author, UA default, or particular referenced style sheets.

Resolution:
Reword to:
| User agents must give the user the ability to turn off the influence
| of specific author style sheets, e.g., through a pull-down menu.
| Conformance to UAAG 1.0 checkpoint 4.14 satisfies this condition.
Also add UAAG 1.0 to the normative references section.
Issue closed.
------------------------------------------------------------------------
Issue 68.
URI: http://www.w3.org/mid/000701c46c98$38b0b4b0$0301a8c0@ATHLON
Description:
(We don't define the clipping region for 'overflow', and we imply it
is something that doesn't match UAs.)
Resolution:
Change 11.1 to say "its padding edge" not "its content box".
Isue closed.
------------------------------------------------------------------------
Issue 69.
URI: http://www.w3.org/mid/41127AC5.6988.24EB1C@localhost
Description:
(Please add examples of margin collapsing.)
Resolution:
Refer to test suite.
Issue closed.
------------------------------------------------------------------------
Issue 70.
URI: http://www.w3.org/mid/9D0CAABC-E72D-11D8-AD43-000502CB1B77@stickdog.com
Resolution:
Replace "In addition, the document language may impose restrictions,
e.g. HTML imposes restrictions on the possible values of the "class"
attribute." with "However, not all syntactically correct CSS can take
effect, since the document language may impose restrictions that are
not in CSS, e.g., HTML imposes restrictions on the possible values of
the "class" attribute.".
Issue closed.
------------------------------------------------------------------------
Issue 71.
URI: http://www.w3.org/mid/BF89F35B-E72E-11D8-AD43-000502CB1B77@stickdog.com
Description:
(Response to pre-CR issue 62.)
Resolution:
In 13.2.1:
  s/page box width/the width of the page box/
  s/page box height/the height of the page box/
Issue closed.
------------------------------------------------------------------------
Issue 72.
URI: http://www.w3.org/mid/4110C39C.2010007@inkedblade.net
Description:
Proposed resolution:
Replace this:
# If a user agent cannot support the resource because of
# the media types it supports, it must ignore the resource.
...with:
: If a user agent cannot display the resource it must ignore it.
Issue closed.
------------------------------------------------------------------------
Issue 73.
URI: http://www.w3.org/mid/4100C923.1000404@smilingsouls.net
Description:
"Why does the UA not define what 'medium' means in pixels?"
Resolution:
Answer: Because it's the user's default.
Change the spec to say that 'medium' is the user's preferred font size.
Issue closed.
------------------------------------------------------------------------
Issue 74.
Description:
(private e-mail to the editors)
[in the grammar]
* What is the meaning of "range"; it is declared but don't seems to be
used.
Resolution:
Remove "range" from Appendix G.
Issue closed.
------------------------------------------------------------------------
Issue 75.
Description:
(private e-mail to the editors)

* DIMEN don't seems to be used too, shouldn't it be added like this:

term
  : unary_operator?
    [ NUMBER S* | PERCENTAGE S* | LENGTH S* | EMS S* | EXS S* | ANGLE S* |
-      TIME S* | FREQ S*| function ]
+      TIME S* | FREQ S*| DIMEN S* | function ]
  | STRING S* | IDENT S* | URI S* | hexcolor
  ;
Resolution:
Remove DIMEN from Appendix G.
Issue closed.
------------------------------------------------------------------------
Issue 76.
URI: http://lists.w3.org/Archives/Public/www-style/2004Aug/0162.html
(More whining about the tiniest of details that really don't matter in
the real world.)
Resolution:
Change "quote marks" to "quotation marks (both single and double)".
Issue closed.
------------------------------------------------------------------------
Issue 77.
Description:
At the moment, if multiple elements all have non-'none' values for the
'clear' property in one set of collapsed margins, then the order that
is used is ambiguous.
Example: http://junkyard.damowmow.com/163
Proposal: We should say 'clear' is resolved in document order, maybe
by adding "The hypothetical position of an element is calculated
assuming that all later elements have no clearance."
Resolution:
Do nothing.
Issue closed.
------------------------------------------------------------------------
Issue 78.
Description:
'clear' says it applies to block-level elements, which includes
position:absolute and position:fixed. But that obviously makes no
sense...
Resolution:
Do nothing.
Issue closed.
------------------------------------------------------------------------
Issue 79.
URI: http://www.w3.org/mid/opsflowqhsbrj5zx@dial81-131-185-96.in-addr.btopenworld.com
Resolution:
Add to second paragraph of 4.1.5: It must do the same for an invalid
at-rule (although something that is ignored because it is invalid,
such as an invalid declaration within an @media-rule, does not make
the entire @-rule invalid).
Issue closed.
(Note: The relevant part in 4.1.5 was nuked by a later resolution.
Instead Tantek and myself decided to put equivalent text in 4.2. -IH)
------------------------------------------------------------------------
Issue 80.
URI: http://www.w3.org/mid/200410252107.14872.bert@w3.org
Description:
Can 'page-break-inside' apply to TR?
http://lists.w3.org/Archives/Public/www-style/2004Oct/0057.html
dbaron suggests to find out if Prince supports it
Change "These properties only apply to block level elements that are
in the normal flow of the root element." to:
"These properties must apply to block level elements that are in the
normal flow of the root element. User agents may apply these
properties to other elements."
Issue closed.
------------------------------------------------------------------------
Issue 81.
URI: http://www.w3.org/mid/200410252107.14872.bert@w3.org
Description:
Should the prose state that @media requires at least one media type?
http://lists.w3.org/Archives/Public/www-style/2004Oct/0041.html
Note: The grammar already says it requires at least one media type.
Resolution:
Leave as is.
Issue closed.
------------------------------------------------------------------------
Issue 82.
URI: http://www.w3.org/mid/BE5BC6AE-1AA1-11D9-8B61-000502CB1B77@stickdog.com
Description:
Resolution:
Change 3rd sentence of 4.1.5 to: "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."
Issue closed.
------------------------------------------------------------------------
Issue 83.
URI: http://www.w3.org/mid/16755.47210.308364.420094@lanalana.inria.fr
Resolution:
Change "top 25%" to "25% top".
Issue closed.
------------------------------------------------------------------------
Issue 84.
URI: http://www.w3.org/mid/20041018160911.7591@mail.visualclick.de
Resolution:
Sorry, too late.
Issue closed.
------------------------------------------------------------------------
Issue 85.
Description:
How does page-break work inside nested block-formatting-contexts?
Resolution:
It's undefined. See CSS3.
Issue closed.
------------------------------------------------------------------------
Issue 86.
Description:
consider changing overflowing left (for ltr) and right (for rtl)
floats, like the second paragraph in 10.3.3 -dbaron
http://dbaron.org/css/test/2004/10-mountain-view/cr86-float-overflow
Resolution:
No change.
Issue closed.
------------------------------------------------------------------------
Issue 87.
Description:
should over-constrained margins use 'direction' of parent, or self?
http://dbaron.org/css/test/2004/10-mountain-view/cr87-direction
Resolution:
Change "If the 'direction' property is 'ltr'" to "If the 'direction' property of the containing block is 'ltr'" in 9.4.3. (Done.)
Change "the 'direction' property" to "the 'direction' property of the containing block" in 10.3.3.
Change "if 'direction'" to "if the 'direction' property of the containing block" in 10.3.7 (twice).
Change "case 'direction' is" to "case the 'direction' property of the containing block is" in 10.3.7.
Change "while 'direction'" to "while the 'direction' property of the containing block" in 10.3.8 (twice).
Change "case 'direction' is" to "case the 'direction' property of the containing block is" in 10.3.8.
Add "The 'direction' property of the initial containing block is the same as for the root element." to the first item in the list in 10.1.
Issue close.
------------------------------------------------------------------------
Issue 88.
Description:
Need to update Appendix H.
Resolution:
Leaving it blank for now.
Issue closed.
------------------------------------------------------------------------
Issue 89.
Description:
Section 10.5, <percentage> section, "A percentage height on the root
element is relative to the viewport.", is not defined for paged media,
since viewport is only defined for continuous media.
Resolution:
Change "viewport" to "initial containing block" in the sentence above,
and then change the definition of "initial containing block" to be
more testable by replacing 10.1:1 by "The containing block in which
the root element lives is the viewport for continuous media, and the
page area for paged media. This containing block is called the initial
containing block." (Note: this is already as defined for paged media
from 13.2.)
Issue closed.
------------------------------------------------------------------------
Issue 90.
Description:
Resolution:
Add the word "first" between "the" and "page" in the third sentence of
the first bullet point of 13.2 in CSS2.1, so that it is clear what
positioned elements are actually relative to.
Issue closed.
------------------------------------------------------------------------
Issue 91.
Description:
If a box is position:absolute in paged media, and is, say, top:120%,
sending it below the fold of the initial containing block, does it
paint on the second page or not at all?
Resolution:
10.1 has a sentence which sort-of applies.
Leave as is for now.
Issue closed.
------------------------------------------------------------------------
Issue 92.
Description:
The ".class" selector when there are multiple class attributes.
Resolution:
Add:
 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.
...to 5.8.3 at the bottom.
Issue closed.
------------------------------------------------------------------------
Issue 93.
Description:
The "#id" selector when there are multiple IDs.
Resolution:
Add:
 If an element has multiple ID attributes, all of them must be treated
 as IDs for that element for the purposes of the ID selector. Such a
 situation could be reached using mixtures of xml:id, DOM3 Core, XML
 DTDs and namespace-specific knowledge.
...to 5.8.4 at the bottom.
Add:
 Support for multiple ID attributes for the ID selector
    Since implementations are not expected to support multiple IDs per
    element soon, this feature may be made informative. The W3C
    Selectors specification will continue to have this feature
    normatively.
...to the "At Risk" section.
Issue closed.
------------------------------------------------------------------------
Issue 94.
Description:
Should background-position allow '54px left' as well as '54px top'?
Should background-position allow 'top 54px' as well as 'left 54px'?
Resolution:
No.
Issue closed.
------------------------------------------------------------------------
Issue 95.
URI: http://lists.w3.org/Archives/Public/www-style/2004Nov/0033.html
Description:
One proposed resolution is:
http://lists.w3.org/Archives/Public/www-style/2004Nov/0034.html
However, the commentor gives implementation feedback saying that it
would be better to simply say that 'auto' means '0' on position:fixed
things, and that the spec as is is rather unimplementable.
Hyatt says that too: http://www.w3.org/mid/41909022.2060303@apple.com
bz says he'll implement this in Mozilla:
   http://lists.w3.org/Archives/Public/www-style/2004Nov/0034.html
Resolution:
Replace this:
| For the purposes of calculating the static position, the containing 
| block of fixed positioned elements is the initial containing block 
| instead of the viewport.
...with this:
"For the purposes of calculating the static position, the containing
block of fixed positioned elements is the initial containing block
instead of the viewport, and all scrollable boxes should be assumed to
be scrolled to their origin."
...in "10.6.4 Absolutely positioned, non-replaced elements".
Issue closed.
------------------------------------------------------------------------
Issue 96.
Description:
@charset isn't in the index.
Issue closed.
------------------------------------------------------------------------
Issue 97.
URI: http://lists.w3.org/Archives/Public/www-style/2004Nov/0077.html
Description:
The title makes it clear that CSS2.1 is a revision of CSS2, a second
edition as it were, but some of the spec, in particular the following
text in the abstract:
| CSS 2.1 builds on CSS2 [CSS2] which builds on CSS1 [CSS1].
...seems to imply that the relationship between CSS2.1 and CSS2 is the
same as CSS2 and CSS1.
Chris Lilley says:
> "CSS 2.1 is derived from and is intended to replace CSS2. Some parts of
> CSS2 are unchanged in CSS 2.1, some parts have been altered, and some
> parts removed. The removed portions may be used in a future CSS3
> specification. Once CSS 2.1 becomes a W3C Recommendation, it is the
> intention of the CSS Working Group to move CSS 2 to Rescinded status."
Resolved:
Add to Status and About:
"CSS 2.1 is derived from and is intended to replace CSS2. Some parts
of CSS2 are unchanged in CSS 2.1, some parts have been altered, and
some parts removed. The removed portions may be used in a future CSS3
specification. Implementations may refer to CSS2 for the definitions
of features that have been removed, but for other features CSS2.1 is
the normative reference."
Issue closed.
------------------------------------------------------------------------
Issue 98.
Description:
(This is a requirement from the CDF group.)
If a replaced element has no intrinsic dimensions then rendering is
undefined. We should say there is a default, so that rendering of such
cases are defined. (e.g. text/plain objects)
I suggest 300px width, with the height derived from the intrinsic
ratio, and, if there isn't one, defaulting to height 150px. -Ian

Resolution:

Replace CSS 2.1 section 10.3.2 "Inline, replaced elements" with:

   A computed value of 'auto' for 'margin-left' or 'margin-right'
   becomes a used value of '0'.

   If 'width' has a computed value of 'auto' and 'height' also has a
   computed value of 'auto', the element's intrinsic width is the used
   value of 'width', if it has one.

   If 'width' has a computed value of 'auto' and 'height' has some
   other computed value, and the replaced element has an intrinsic
   ratio, or, if both 'width' and 'height' have computed values of
   'auto', and the element has no intrinsic width but does have an
   intrinsic height and intrinsic ratio, then the used value of
   'width' is:

     (intrinsic ratio) * (used height)

   Otherwise, if 'width' has a computed value of 'auto', but none of
   the conditions above are met, then the used value of 'width'
   becomes 300px. If 300px is too wide to fit the device, UAs should
   use the width of the largest rectangle that has a 2:1 ratio and
   fits the device instead.

   Percentage intrinsic widths are first evaluated with respect to the
   containing block's width, if that width doesn't itself depend on
   the replaced element's width. If it does, then a percentage
   intrinsic width on that element can't be resolved and the element
   is assumed to have no intrinsic width.

Replace CSS 2.1 section 10.6.2 "Inline replaced elements, block-level
replaced elements in normal flow, 'inline-block' replaced elements in
normal flow and floating replaced elements" with the following:

   If 'margin-top', or 'margin-bottom' are 'auto', their used value is
   0.

   If 'height' has a computed value of 'auto' and 'width' also has a
   computed value of 'auto', the element's intrinsic height is the
   used value of 'height', it has one.

   If 'height' has a computed value of 'auto' and 'width' has some
   other computed value, and the replaced element has an intrinsic
   ratio, or, if both 'height' and 'width' have computed values of
   'auto', and the element has no intrinsic height but does have an
   intrinsic width and intrinsic ratio, then the used value of
   'height' is:

    (used width) / (intrinsic ratio)

   Otherwise, if 'height' has a computed value of 'auto', but none of
   the conditions above are met, then the used value of 'height' must
   be set to 150px. If 300px is too wide to fit the device width, UAs
   should use the height of the largest rectangle that has a 2:1 ratio
   and fits the device width instead.

   Percentage intrinsic heights are evaluated with respect to the
   containing block's height, if that height is specified explicitly,
   or if the replaced element is absolutely positioned. If neither of
   these conditions is met, then percentage values on such replaced
   elements can't be resolved and such elements are assumed to have no
   intrinsic height.

   For 'inline' and 'inline-block' elements, the margin box is used
   when calculating the height of the line box.

Replace the definition of "Replaced element" in section 3.1
"Definitions" with:

   An element that is outside the scope of the CSS formatter, such as
   an image, embedded document, or applet. For example, the content of
   the HTML IMG element is often replaced by the image that its "src"
   attribute designates. Replaced elements often have intrinsic
   dimensions: an intrinsic width, an intrinsic height, and an
   intrinsic ratio. For example, a bitmap image has an intrinsic width
   and an intrinsic height specified in absolute units (from which the
   intrinsic ratio can obviously be determined). On the other hand,
   other documents may not have any intrinsic dimensions (for example
   a blank HTML document).

   User agents may consider a replaced element to not have any
   intrinsic dimensions if it is believed that those dimensions could
   leak sensitive information to a third party. For example, if an
   HTML document changed intrinsic size depending on the user's bank
   balance, then the UA might want to act as if that resource had no
   intrinsic dimensions.

Issue closed.
------------------------------------------------------------------------
Issue 99.
Description:
Given that intrinsic sizes can be percentages (as, e.g., they are by
default in SVG), how do percentages get handled in the following
expression (from 10.3.2 and similar in 10.6.2)?
   (intrinsic width) * ( (used height) / (intrinsic height) )
What if one is a percentage and the other is not?
Resolution:
See proposal in issue 98.
Issue closed.
------------------------------------------------------------------------
Issue 100.
Description:
Under 'height' <percentage>:
# If the height of the containing block is not specified explicitly
# (i.e., it depends on content height), and this element is not
# absolutely positioned, the value is interpreted like 'auto'.
Under 10.6.2:
# If 'height' has a computed value of 'auto' ...
Does "is interpreted like 'auto'" mean it computes to 'auto'?
Resolution:
Under <height>, change "is interpreted like" to "computes to".
Make sure the "Computed value" line is still correct for 'height'.
Issue closed.
------------------------------------------------------------------------
Issue 101.
Description:
In appendix E it says:
# For each element in each line box of the element, 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:
...but doesn't say what order that is. It should say it is in tree
order (like the rest of the painting algorithm). -Ian
Resolution:
Agree that it should be tree order.
Issue closed.
------------------------------------------------------------------------
Issue 102.
Description:
I think we might need to add the "If the containing block's width depends  
on this element's width, then the resulting layout is undefined in CSS
2.1." clause to the min/max-width/height properties' definitions of %.
  -IH
http://www.hixie.ch/tests/adhoc/css/box/float/048.html
Resolution:
Add this to the definition of <percentage> for min-/max-width:
   If the containing block's width depends on this element's width,
   then the resulting layout is undefined in CSS 2.1.
Add this to the definition of <percentage> for min-/max-height, after
"(i.e., it depends on content height),":
   and this element is not absolutely positioned,
Issue closed.
------------------------------------------------------------------------
Issue 103.
Description:
Can replaced elements have overflow:visible? What does it mean? (For
text/plain, text/html, image/svg+xml?)
Resolution:
Change applies-to line for 'overflow' to:
| Applies to: non-replaced block-level elements, table cells, and
| inline-block elements.
Issue closed.
------------------------------------------------------------------------
Issue 104.
Description:
Can the root element have overflow:visible? What does it mean? (Does
it mean "show scrollbars"?)
Resolution:
Add the following:
| The 'visible' value in this case must be interpreted as 'auto'.
...after:
| UAs may apply the 'overflow' property set on the root element to the
| viewport (instead of the root element).
...but before:
| HTML UAs may also apply the 'overflow' property from the BODY
| element to the viewport.
...then add the following to the end of that last sentence:
| , if the value on the HTML element is 'visible'
Issue closed.
------------------------------------------------------------------------
Issue 105.
Description:
Take this: http://junkyard.damowmow.com/177
Should the table size to the remaining width (it does in Opera,
Firefox and IE, but the spec is vague about it)? And if so, should we
be explicit about it? How about other roots of formatting contexts?
Other testcase: http://fantasai.inkedblade.net/style/tests/ad-hoc/tables/002

Resolution:

Add this to section 17.5.2, Automatic table layout section:

   "Input to this algorithm must only include the width of the
   containing block and the content of, and any CSS properties set on,
   the table and any of its descendants."

...then mark this as an "at risk" feature in the status of the document.

Issue closed.
------------------------------------------------------------------------
Issue 106.
URI: http://www.w3.org/mid/BB24D4EB-1AA1-11D9-8B61-000502CB1B77@stickdog.com
URI: http://www.w3.org/mid/20040917151429.24902@mail.visualclick.de
Description:
Handling of "unrecognised" at-rules is unclear. e.g. what exactly does
"unrecognised" mean?
(I think we need to be clearer somewhere that it is the smallest
unrecognised part of a stylesheet that is ignored, and that the rest
of the stylesheet should be handled as described by the spec. For
example, if a declaration is invalid, you drop it but keep using the
rule. If a rule is invalid, you drop that but keep using its parent
rule. And so forth. -IH)
Resolution:
Remove "A CSS user agent that encounters an unrecognized at-rule must
ignore the whole of the at-rule and continue parsing after it." from
4.1.5.
Issue closed.
------------------------------------------------------------------------
Issue 107.
URI: http://www.w3.org/mid/20041104194521.GA3694@darby.dbaron.org
URI: http://www.w3.org/mid/20041215052142.GA23158@darby.dbaron.org
URI: http://www.w3.org/mid/16832.7460.603429.635656@howcome.oslo.opera.com
URI: http://www.w3.org/mid/200412202017.58606.bert@w3.org
URI: http://www.w3.org/mid/20050120055804.GA31338@ridley.dbaron.org
URI: http://www.w3.org/mid/20050120095544.GA2343@ridley.dbaron.org
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JanMar/0197
URI: http://www.w3.org/mid/20050402003637.GA4480@ridley.dbaron.org
Description:
Counters and how they work.
See also issue 31.
dbaron had an action to summarise issues and give presentation.
He has sent a summary:
   http://lists.w3.org/Archives/Member/w3c-css-wg/2005JanMar/0213.html
He has also sent a list of proposed edits:
   http://lists.w3.org/Archives/Member/w3c-css-wg/2005JanMar/0263
Resolution:
Make edits in:
   http://www.w3.org/mid/20050405162655.GA19751@ridley.dbaron.org
   http://lists.w3.org/Archives/Member/w3c-css-wg/2005JanMar/0263
   http://www.w3.org/mid/20050402003637.GA4480@ridley.dbaron.org
Issue closed.
------------------------------------------------------------------------
Issue 108.
URI: http://www.w3.org/mid/opsfauzucsbrj5zx@dial81-131-29-47.in-addr.btopenworld.com
Description:
Is the media in @media required, or is

   @media { ... }

...allowed?
Resolution:
No change. Grammar says it is required.
=Ian= Add a testcase.
Issue closed.
------------------------------------------------------------------------
Issue 109.
URI: http://www.w3.org/mid/20041003202304.GA17471@darby.dbaron.org
Description:
We should remove the use of the word "elements" and replace it by
"boxes". -DB (See e-mail for context of where in the spec the change
is expected.)
Resolution:
In 17.2.1 change appropriate occurrences of "element" to "box".
Issue closed.
------------------------------------------------------------------------
Issue 110.
URI: http://www.w3.org/mid/000301c4a62e$a03f35a0$a100a8c0@thomas
Description:
Possible error in example in section 17.1.
Resolution:
Accept change.
Issue closed.
------------------------------------------------------------------------
Issue 111.
URI: http://www.w3.org/mid/opsh23w7q8brj5zx@host213-122-105-92.in-addr.btopenworld.com
Description:
(Not entirely sure. The e-mail has a couple of editing suggestions and
ends with a third suggestion that I don't follow. Maybe following the
thread would shine more light. -IH)
Resolution:
Make one change: Section 9.3.1: Change "and is fixed with respect to
the page" to "and is fixed with respect to the page box".
Issue closed.
------------------------------------------------------------------------
Issue 112.
URI: http://www.w3.org/mid/20041126083845.GA8630@darby.dbaron.org
Description:
Some comments on 16.6.1 The 'white-space' processing model [1]:

 1. "ignoring bidi formatting characters as if they were not there"
    should perhaps be "treating bidi formatting characters as if they
    were not there".

Resolution:
Agreed.
Issue closed.
------------------------------------------------------------------------
Issue 113.
URI: http://www.w3.org/mid/20041126083845.GA8630@darby.dbaron.org
Description:
Some comments on 16.6.1 The 'white-space' processing model [1]:

 2. In bullet (2) in the first list, "However, a line breaking
    opportunity exists at the end of the sequence." seems bizarre.  A
    line breaking opportunity exists at the end of any sequence of
    spaces inside something that's 'pre' or 'pre-wrap'?

(I was also hoping things would be a little better defined, although I
also don't understand the whole thing yet.)

Resolution:
The second bit should just be for 'pre-wrap'. Add "for 'pre-wrap',"
after "However,", in step 2.
Issue closed.
------------------------------------------------------------------------
Issue 114.
URI: http://www.w3.org/mid/p06110403bdd3fb447f04@%5B152.16.15.54%5D
Description:
(see also other mails in that thread)
How do we deal with CSS2.1 obsoleting CSS2?
We need a way of marking CSS2 as superseded by CSS2.1.
Resolution:
http://www.w3.org/TR/REC-CSS2/ and http://www.w3.org/TR/CSS2/ should
be updated to point to 2.1 once we reach rec. In the meantime, the
paragraphs in the abstract and in 1.1 are fine.
Issue closed.
------------------------------------------------------------------------
Issue 115.
URI: http://www.w3.org/mid/41ADC380.50001@annevankesteren.nl
URI: http://www.w3.org/mid/41ADD83D.2060105@expway.fr
Description;
#id should be changed to not refer only to ID attributes (elements can
be given IDs in ways other than by attributes).
Resolution:
Spec says "CSS ID selectors match an element instance based on its
identifier." which is open enough to allow stuff. The attributes text
doesn't say anything about CSS really.
Issue closed.
------------------------------------------------------------------------
Issue 116.
URI: http://www.w3.org/mid/61192FA29C719B469A2B13E57DEDF75B0300F190@mail.hbinc.com
Description:
See issues 48 and 76 for context.
Resolution:
This is quite clear enough already... We could specify it in more
detail but it's obvious what is meant if you spend more than 2 seconds
thinking about it. :-P
Issue closed.
------------------------------------------------------------------------
Issue 117.
URI: http://www.w3.org/mid/41060B4F.3070805@annevankesteren.nl
Description:
We need to decide once and for all if :active applies to elements that
can't be activated beyond just receiving click events.
:focus only applies to elements that can be focussed
:hover applies to all elements
does :active apply only to elements that can be activated, or does it
apply to all elements?
Resolution:
Remove the relevant :active pseudo-class test from the Selectors
test suite (19a).
Issue closed.
------------------------------------------------------------------------
Issue 118.
URI: http://www.w3.org/mid/200412151916.24533.bert@w3.org
URI: http://www.w3.org/mid/41c13e89.266975859@smtp.bjoern.hoehrmann.de
Description:
How should control characters be handled?
Form Feed, Line Separator, and Paragraph Separator come to mind.
Currently we only define the handling of space, tab, line feed, and
the bidi formatting characters.
Browsers have the following special cases:
  U+000D - treated as U+000A (Mozilla, Opera)
  U+000B - treated as U+000A (Opera)

Resolution:

<p>Control characters other than U+0009 (tab), U+000A (line feed),
U+0020 (space), and U+202x (bidi formatting characters) are treated as
characters to render in the same way as any normal character.</p>

<p>Combining characters should be treated as part of the character
with which they are supposed to combine. For example, :first-letter
styles the entire glyph if you have content like
"<code>o&lt;span&gt;&amp;#x308;&lt;/span&gt;</code>"; it doesn't just
match the base character.</p>

Issue closed.
------------------------------------------------------------------------
Issue 119.
URI: http://www.w3.org/mid/5.1.1.5.2.20041216145358.00ac1410@mailserver.nist.gov
Description:
We should update CSS2.1 to comply to QASG.
Resolution:
Read through http://www.w3.org/TR/qaframe-spec/ and
http://lists.w3.org/Archives/Public/www-qa/2004Dec/att-0012/css21-specgl.htm
and update the spec appropriately.
Issue closed.
------------------------------------------------------------------------
Issue 120.
URI: http://www.w3.org/mid/200501121523.00154.bert@w3.org
URI: http://www.w3.org/mid/20050112190248.GA20771@ridley.dbaron.org
Description:
The empty list-item issue. (Did we already resolve this?)
Resolution:
Spec is correct. No change.
Issue closed.
------------------------------------------------------------------------
Issue 121.
URI: http://www.w3.org/mid/3F6865DB7477EF4A8F79ABCB18DC7E5BBC9BA2@cacexc06.americas.cpqcorp.net
URI: http://www.w3.org/mid/20050112232659.GA14936@ridley.dbaron.org
URI: http://www.w3.org/mid/3F6865DB7477EF4A8F79ABCB18DC7E5BBC9BC2@cacexc06.americas.cpqcorp.net
URI: http://www.w3.org/mid/3F6865DB7477EF4A8F79ABCB18DC7E5BBC9C10@cacexc06.americas.cpqcorp.net
Description:
When an object is absolutely positioned using the 'bottom' and 'right'
properties and direction is ltr, step 2 of the current algorithm in
Section 10.3.8 seems to inappropriately set 'left' to the static
position when the intrinsic width of the object implies a different
left position. (Essentially the 'right' offset is overridden by
setting 'left' to the static position.) And the analogous issue for
rtl also applies, I believe. -MG
Resolution:
Edit as per:
   http://www.w3.org/mid/3F6865DB7477EF4A8F79ABCB18DC7E5BBC9C10@cacexc06.americas.cpqcorp.net
Issue closed.
------------------------------------------------------------------------
Issue 122.
URI: http://www.w3.org/mid/41E7B41A.2060200@mit.edu
Description:
How is a replaced element with display:table-cell handled?
How about other display values?
[Fwiw, my personal preference from an implementation perspective is
that replaced elements with table-row-group, table-row, table-cell,
table-caption display values be treated as inlines and anonymous boxes
be constructed appropriately.... (read that as "Boris doesn't want to
rewrite all the table rendering code in Mozilla to not assume things
about the layout objects it's working with"). -Boris]

Resolution:
Add to 17.2, after the table display types list:
| Replaced elements with these 'display' values are treated as their
| given display types during layout. For example, an image that is set
| to 'display: table-cell' will fill the available cell space, and its
| dimensions might contribute towards the table sizing algorithms, as
| with an ordinary cell.
Issue closed.
------------------------------------------------------------------------
Issue 123.
URI: http://www.w3.org/mid/41EACB0E.1000808@annevankesteren.nl
Description:
'clip' handling
Resolution:
Out of scope.
Issue closed.
------------------------------------------------------------------------
Issue 124.
Description:
How to handle unterminated constructs (unexpected end of stylesheet)
is undefined.
Proposal from howcome and ian to add to section 4.2:

   Unexpected end of stylesheet.

   User agents must close all open constructs (blocks, parentheses,
   brackets, rules, strings, comments, etc) at the end of the
   stylesheet. For example:

      @media screen {
        p:before { content: 'Hello

   ...would be treated the same as:

      @media screen {
        p:before { content: 'Hello'; }
      }

   ...in a conformant UA.

Resolution:
Use the proposal above.
Change "(blocks, parentheses, brackets, rules, strings,
comments, etc)" to "(for example: blocks, parentheses, brackets,
rules, strings, and comments)"
Issue closed.
------------------------------------------------------------------------
Issue 125.
Description:
How to handle unterminated constructs (line break in string).
Three sane options:
 * linefeed terminates the string,
 * strings can be multilined, or
 * unterminated strings terminate at a linefeed but make the
   declaration invalid.

Proposed text for the last bullet point:

   Unexpected end of string.

   User agents must close strings upon reaching the end of a line, but
   then drop the construct (declaration or rule) in which the string
   was found. For example:

      p {
        color: green;
        font-family: 'Courier New Times
        color: red;
        color: green;
      }

   ...would be treated the same as:

      p { color: green; color: green; }

   ...because the second declaration (from 'font-family' to the
   semicolon after 'color: red') is invalid and is dropped.

Resolution:
(done) Use the proposal text above.
Change the spec prose to allow control characters in
strings, if necessary (i.e. if it says anywhere that they are not
allowed).
(done) Allow control characters in strings in the grammar.
(done) Update grammar to make newline create an invalid string token.
Issue closed.
------------------------------------------------------------------------
Issue 126.
Description:
(from eddy@opera.com)

In the list of Absolute lengths, a little down from that heading:

   * pt: points - the points used by CSS 2.1 are equal to 1/72th of an inch.

This is *so* ugly: "1/72th of an inch"
If it's going to be said like that, it should be "1/72nd of an inch"
but it would be much more sensible to call it "inch / 72"
and far better to say
   * pt: points - 72 of the points used by CSS 2.1 are equal to one inch.
or
   * pt: points - the points used by CSS 2.1 are defined by 72pt = 1in.
but 72th is just broken grammar.

Furthermore, given that the pica is involved as well, it would make
sense to change the order of these two entries in the list and say:

  * pc: picas - 1 pica is equal to one sixth of an inch; 6pc = 1in.
  * pt: points - 1 point is equal to one twelfth of a pica; 12pt = 1pc.

and relegate the language about "used by CSS 2.1" to a sentence
outside this list, perhaps saying "although these units may have other
meanings in other contexts, the above definitions are normative for
CSS 2.1" or similar.  [That way it'll apply to the inch definition as
well; 2.54cm is a relatively modern specification.]

Hmm ... so pica is inch / 6 ?  I had it as inch / 12, and thus
redundant with the "line" - not necessarily, but possibly, a clue that
I got this wrong.  Do you know where CSS got this definition of the
pica ?  (I *don't* know where I got my version of pica.)

Resolution:
Reject except for 1/72th change.
=Tantek= Change 1/72th to 1/72nd.
------------------------------------------------------------------------
Issue 127.
URI: http://www.w3.org/mid/E1CsQBn-0003Lx-ID@localhost
Description:
Allow 'content: none' in CSS2.1 (despite it being redundant with
'normal').
Resolved:
Add the 'none' keyword, and say that 'normal' computes to it for
:before and :after.
Update property database to match.
Issue closed.
------------------------------------------------------------------------
Issue 128.
URI: http://www.w3.org/mid/20050124140037.4344@mail.visualclick.de
Description:
Issues with idents starting with a hyphen. (re-raised issue 84.)
Resolution:
Rejected again. Still too late. (We do agree it is unfortunate.)
Issue closed.
------------------------------------------------------------------------
Issue 129.
URI: http://www.w3.org/mid/Pine.GSO.3.96.1050201140139.13203A-100000@rmi-sun.rmi.acnet.ge
Description:
Interaction of "The :before and :after pseudo-elements elements
interact with other boxes, such as run-in boxes, as if they were real
elements inserted just inside their associated element" (12.1) and "If
the parent P of a 'table-cell' element T is not a 'table-row', an
object corresponding to a 'table-row' will be generated between P and
T. This object will span all consecutive 'table-cell' siblings (in the
document tree) of T." (17.2.1) is unclear.
Resolution:
Change "siblings (in the document tree)" to "sibling boxes" throughout
17.2.1.
Issue closed.
------------------------------------------------------------------------
Issue 130.
URI: http://www.w3.org/mid/14111.1107260765@www39.gmx.net
Description:
One case of 'display: caption' should be 'display: table-caption' in
the tables chapter.
Resolution:
Fix.
Issue closed.
------------------------------------------------------------------------
Issue 131.
URI: http://www.w3.org/mid/C0289E3872DEC2498185DD1743006C2E091742F1@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com
Description:
Too many cases of undefined behaviour in CSS2.1. For instance:
 * percentage values on 'height' on table cells
 * table layout is not defined

Ian says: The reason it's not defined is that we can't come up with a
decent proposal for those issues. If you can suggest something that
works, I'm all for it.
Tantek agrees with Ian's comment.

Some non-exhaustive testcases:
   http://damowmow.com/playground/demos/percentages/001.html
   http://damowmow.com/playground/demos/percentages/002.html

Resolution:
We can't wait for this for 2.1. Leave 2.1 as is.
We want to resolve this for CSS3 ASAP though, and may back-port from
CSS3 to CSS2.1 if it is ready in time.

=Markus= Ask ChrisW to produce something.
=Markus= Investigate what IE6 does with %s in tables in standards mode.
Moved to CSS3.
Issue closed.
------------------------------------------------------------------------
Issue 132.
URI: http://www.w3.org/mid/C0289E3872DEC2498185DD1743006C2E091742F1@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com
Description:
17.5.3 says:
| CSS 2.1 does not specify how cells that span more than row affect
| row height calculations except that the sum of the row heights
| involved must be great enough to encompass the cell spanning the
| rows.
..."more than row" should be "more than one row".
Resolution:
Fix the typo. (done)
=ChrisW= Investigate, suggest edits for 2.1 (but 2.1 will not be held
for this).
Issue closed.
------------------------------------------------------------------------
Issue 133.
URI: http://www.w3.org/mid/20050202123220.2190@mail.visualclick.de
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JanMar/0197.html
Description:
My question: Is

  12\i\n = 12in

?

Or in other words, at which level in the processing chain of CSS is the
quoting resolved to the actual Unicode character?

In the example above, the scanner generates a DIMENSION token for each
side of the equation, and at some later point it needs to be decided
whether it will become a DIMEN or LENGTH token with different results
depending on whether escape resolution is carried out before or after the
refinement step.

Resolution:
Units can be escaped, as they are just identifiers.
Edit the appendix to make the tokeniser/scanner match chapter four.
Issue closed.
------------------------------------------------------------------------
Issue 134.
Issue closed.
------------------------------------------------------------------------
Issue 135.
URI: http://www.w3.org/mid/42064E43.23241.1EC58207@localhost
Description:
Please drop 'run-in'.
Resolution:
No change.
Issue closed.
------------------------------------------------------------------------
Issue 136.
Description:
<bloo> under http://www.w3.org/TR/CSS21/generate.html#content it says that <uri> is legal
<Hixie_> indeed
<bloo> and under http://www.w3.org/TR/CSS21/changes.html#q21 it says it is dropped
<Hixie_> how unfortunate
Resolution:
Change the changes.
Issue closed.
------------------------------------------------------------------------
Issue 137.
Description:
howcome and ian suggest changing 4.2 last paragraph:
# How to handle unparseable and untokenizable stylesheets is undefined
# in CSS2.1
...to:
| How to handle parse errors other than those described in this
| section is undefined in CSS2.1.
Resolution:
Strike paragraph. Any remaining undefined cases are a mistake.
Issue closed.
------------------------------------------------------------------------
Issue 138.
Description:
Two steps in appendix E apply to relatively positioned floats.
Step 5 should be changed to only apply to non-positioned floats.
Resolution:
Change "All floating descendants" in step 5 to "All non-positioned
floating descendants".
Issue closed.
------------------------------------------------------------------------
Issue 139.
Description:
Border corners aren't defined.
=dbaron= Make a proposal so that the WG can discuss it.
Tantek thinks this should not hold up last call. (Ian agrees.)
Resolution:
Move to CSS3.
Issue closed.
------------------------------------------------------------------------
Issue 140.
Description:
Decision made at F2F in Boston.
Resolution:
The contents of fixed positioned elements do not paginate. (normative)
Issue closed.
------------------------------------------------------------------------
Issue 141.
Description:
<Tantek> new CSS2.1 issue: example in 9.6.1  http://www.w3.org/TR/CSS21/visuren.html#fixed-positioning
<Tantek> add media="screen" to the <style> element in the example.
Resolution:
Do what Tantek says above.
Issue closed.
------------------------------------------------------------------------
Issue 142.
Description:
Does min-width apply to tables?
What is a "table element"? Does it mean "inner table element"?
Resolution:
Take the "Applies to" line for 'width' and apply it to 'min-width' and
'max-width', and take the "Applies to" line for 'height' and apply it
to 'min-height' and 'max-height'.
Issue closed.
------------------------------------------------------------------------
Issue 143.
URI: http://www.w3.org/mid/16932.29554.531153.982787@howcome.oslo.opera.com
Description:
Something about defining our "crappy values" for text-align.
Resolution:
Add ", as described in <a href="visuren.html#inline-formatting">the
section on inline formatting</a>" to the end of "Left, right, center,
and justify text, respectively."
Issue closed.
------------------------------------------------------------------------
Issue 144.
Description:
Melinda wants to talk about margin collapsing and print.
Resolution:
=Melinda= Send something out if you think we need to discuss further.
Issue closed.
------------------------------------------------------------------------
Issue 145.
Description:
Drop 'quotes'?
Resolution:
Put the 'quotes' stuff in the at-risk section.
Issue closed.
------------------------------------------------------------------------
Issue 146.
Description:
The following text on body->html propagation of bgs is rather ambiguous:
# User agents should observe the following precedence rules to fill in
# the background of the canvas of HTML documents: if the value of the
# 'background' property for the HTML element is different from
# 'transparent' then use it, else use the value of the 'background'
# property for the BODY element. If the resulting value is
# 'transparent', the rendering is undefined.
Resolution:

Replace above text with:

  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.

Issue closed.
------------------------------------------------------------------------
Issue 147.
URI: http://www.w3.org/mid/20050320000004.GA8051@ridley.dbaron.org
Description:
Computed values of 'cursor' propery.
Resolution:
Use the following computed value for 'cursor':
| As specified, except with any relative URLs converted to absolute
Issue closed.
------------------------------------------------------------------------
Issue 148.
URI: http://lists.w3.org/Archives/Public/www-style/2005Mar/0087.html
Description:
If 'overflow' propagation to viewport is a MAY, we'll have some
interoperability issues, since the two possible layouts are radically
different.
Resolution:
Replace this paragraph in 11.1.1:

  UAs may apply the 'overflow' property set on the root element to the
  viewport (instead of the root element). The 'visible' value in this
  case must be interpreted as 'auto'. HTML UAs may also apply the
  'overflow' property from the BODY element to the viewport, if the
  value on the HTML element is 'visible'.

...with this paragraph:

  UAs must apply the 'overflow' property set on the root element to
  the viewport. HTML UAs must instead apply the 'overflow' property
  from the BODY element to the viewport, if the value on the HTML
  element is 'visible'. The 'visible' value when used for the viewport
  must be interpreted as 'auto'. The element from which the value is
  propagated must have a used value for 'overflow' of 'visible'.

=Tantek= Edit.
------------------------------------------------------------------------
Issue 149.
Description:
<roc> Hixie: do you think it's clear from section 11.1 that outlines
contribute to overflow?
<roc> perhaps you could mention that overflow includes everything
rendered by the children of the element, or something like that
<roc> someone might argue that the outline is not 'content'

Resolution:
Add "or overflow" to the end of "The outline created with the outline
properties is drawn "over" a box, i.e., the outline is always on top,
and doesn't influence the position or size of the box, or of any other
boxes. Therefore, displaying or suppressing outlines does not cause
reflow." in 18.4.
=Tantek= Edit.
------------------------------------------------------------------------
Issue 150.
URI: http://www.w3.org/mid/3F6865DB7477EF4A8F79ABCB18DC7E5BBC9D2D@cacexc06.americas.cpqcorp.net
Description:
What should overflow:auto/scroll do for print media.

One possible resolution is:

Remove this text from 'scroll' definition of 'overflow':

   When this value is specified and the target medium is 'print',
   overflowing content may be printed.

Add this text to 'auto' and 'scroll' definitions of 'overflow': 

   When the UA cannot scroll (e.g. the media is 'print') then the UA
   must treat this value as 'visible'.

Add note to the "at risk" section saying 'visible' above will change
to 'hidden'.

Resolution:
=Melinda= Examine again and suggest new text with at least one example.
In the meantime:
Issue closed.
------------------------------------------------------------------------
Issue 151.
Description:
(Editorial.)

Section 3.2 says:

6. User agents must give the user the ability to turn off the
   influence of specific author style sheets. Conformance to UAAG 1.0
   checkpoint 4.14 satisfies this condition [[-UUAG]].

7. The UA must allow the user to turn off the influence of author
   style sheets.

I recommend we drop point number 6, since it is basically redundant
with point 7 and in any case is almost identical to a sentence in
section 6.4.3. (If we don't drop it we should at least correct the
broken reference -- it should be "[[UUAG10]]".)

Resolution:
Assumed editorial and resolved without group consensus.
Issue closed.
------------------------------------------------------------------------
Issue 152.
Description:
In appendix G we say:

"CSS2 parses a number immediately followed by an identifier as a DIMEN
token (i.e., an unknown unit), CSS1 parsed it as a number and an
identifier. That means that in CSS1, the declaration 'font:
10pt/1.2serif' was correct, as was 'font: 10pt/12pt serif'; in CSS2, a
space is required before "serif". (Some UAs accepted the first
example, but not the second.)"

...but we've now dropped the DIMEN token. Does this reintroduce those
problems? Should we update the text above?

Resolution:
Fix grammar.
Issue closed.
------------------------------------------------------------------------
Issue 153.
URI: https://bugzilla.mozilla.org/show_bug.cgi?id=286385
Description:
We should have some text in the :first-letter definition that
positively says that the pseudo-element styles the first letter of
the first line of an element. We currently do not say this although we
detail many cases that it does _not_ match.

When we define this, we should say whether a replaced element at the
start of the line counts as a letter for these purposes, or if it
simply stops the first-letter-ness.

Testcase: https://bugzilla.mozilla.org/attachment.cgi?id=177593

Resolution:

Add at the start of the first paragraph of 5.12.2:

  The :first-letter pseudo-element must select the first letter of the
  first line of a block, if it is not preceded by any other content
  (such as images or inline tables) on its line.

Issue closed.
------------------------------------------------------------------------
Issue 154.
URI: http://www.w3.org/mid/200504041517.01213.bert@w3.org
Resolution:
Clear enough for 2.1, maybe address for CSS3.
Issue closed.
------------------------------------------------------------------------
Issue 155.
URI: http://www.w3.org/mid/36f7235805030419141a7b701@mail.gmail.com
Resolution:
Not reasonable to address for 2.1.
Issue closed.
------------------------------------------------------------------------
Issue 156.
URI: http://www.w3.org/mid/3F6865DB7477EF4A8F79ABCB18DC7E5BBC9C87@cacexc06.americas.cpqcorp.net
Resolution:
Already resolved (text already added to 10.1).
Issue closed.
------------------------------------------------------------------------
Issue 157.
URI: http://www.w3.org/mid/20050222222518.GA8957@ridley.dbaron.org
Resolution:
(See e-mail for context.)
Remove "If the property is set", capitalize the "o", and change "it
specifies" to "'line-height' specifies".
Issue closed.
------------------------------------------------------------------------
Issue 158.
URI: http://www.w3.org/mid/2457.1108461756@www59.gmx.net
Resolution:
Typo, no change, up to you, respectively.
Fix remaining "this this" typo in the tables chapter.
Issue closed.
------------------------------------------------------------------------
Issue 159.
URI: http://www.w3.org/mid/BAY13-F13AEF67785853B74848885B96A0@phx.gbl
Resolution:
2.1 spec already defines this.
=Tantek= Edit CSS3 to match.
Issue closed.
------------------------------------------------------------------------
Issue 160.
URI: http://www.w3.org/mid/423E92CF.7040306@annevankesteren.nl
URI: http://www.w3.org/mid/426dd948.1085237187@smtp.bjoern.hoehrmann.de
Description:
Impact of IRIs on CSS2.1.
Resolution:
CSS2.1 just has URIs.
We'll deal with IRIs and IDN in CSS3 when we have more implementation
experience.
Issue closed.
------------------------------------------------------------------------
Issue 161.
URI: http://www.w3.org/mid/20050322232721.2649@mail.visualclick.de
Resolution:
No change. It's fine.
Issue closed.
------------------------------------------------------------------------
Issue 162.
URI: http://bugzilla.mozilla.org/show_bug.cgi?id=237770
URI: http://www.w3.org/mid/200504271928.11759.bert@w3.org
Description:
This may be a non-issue, but we should check that interaction of
top:auto/left:auto (static position) on abs pos blocks is defined when
the static position would be a floated element.
Resolution:
After "if its 'position' property had been 'static'", add "and 'float'
had been 'none'" in sections 10.3.7 and 10.6.4.
And patch 10.6.5 so "static position" is a hyperlink (to 10.6.4) like
it is in 10.3.8 (to 10.3.7).
Issue closed.
------------------------------------------------------------------------
Issue 163.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0027.html
URI: http://www.w3.org/mid/200504271928.11759.bert@w3.org
Description:
> > Actually, no. No anonymous boxes are created inside that table because
> > that table is empty and so has no child boxes. Ergo it's just a table
> > box,
>
> Yikes.  I never noticed that before.  I'd like to raise *that* as an
> issue.  I think every table should have at least one row, and every row
> at least one cell.
Resolution:
Retracted: http://www.w3.org/mid/20050503014320.GA16909@ridley.dbaron.org
Issue closed.
------------------------------------------------------------------------
Issue 164.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0027.html
Description:
> > That said, I disagree with the assertion that blocks and tables have no 
> > baseline -- it's a concept clearly used in table-cell layout and it 
> > ought to be defined.
>
> I wouldn't mind explicitly saying that "except for cells and boxes 
> containing in-flow line boxes as descendants, boxes have no baselines".

Resolution:

In 17.5.3, replace:

"The baseline of a cell is the baseline of the first line box in the
cell. If there is no text, the baseline is the baseline of whatever
object is displayed in the cell, or, if it has none, the bottom of the
cell box."

...with:

"The baseline of a cell is the baseline of the first in-flow line box
in the cell, or the first in-flow table-row in the cell, whichever
comes first. If there is no such line box or table-row, the baseline
is the bottom of content edge of the cell box. For the purposes of
finding a baseline, in-flow boxes with a scrolling mechanisms (see the
'overflow' property) must be considered as if scrolled to their origin
position. Note that the baseline of a cell may end up below its bottom
border, see the example below."

...and take the rest of the paragraph ("The maximum distance between
the top of the cell box and the baseline over all cells that have
'vertical-align: baseline' is used to set the baseline of the row.
Here is an example:") and put it into a new paragraph.

Then add this example at the bottom of the section:

   The cell in this example has a baseline below its bottom border,
   which leaves an empty space below the cell in its table row:

      div { height: 0; overflow: hidden; }

      <table>
       <tr>
        <td>
         <div> Test </div>
        </td>
       </tr>
      </table>

...then change "Note that if there is no cell box aligned at its
baseline, the row will not have (nor need) a baseline." to be its own
paragraph and say:

"If a row has no cell box aligned to its baseline, the baseline of
that row is the bottom content edge of the lowest cell in the row."

Issue closed.
------------------------------------------------------------------------
Issue 165.
Description:
Computed value of 'background-image' should include 'none'
Resolution:
Add "or 'none'" to its computed value line.
(Assumed editorial by Ian. If you disagree, let me know.)
Issue closed.
------------------------------------------------------------------------
Issue 166.
Description:
Bert writes:
As somebody www-style found[1], there is still an occurrence of the word 
"descriptor" in 1.4.1 of CSS 2.1. I propose to remove it. Seems 
editorial to me.

[1] http://lists.w3.org/Archives/Public/www-style/2005Apr/0239.html
Resolution:
Assumed editorial.
Issue closed.
------------------------------------------------------------------------
Issue 167.
Description:
Markup error.
"<li><li>" in syndata section 4.2 at end of list.
=Tantek= Edit.
------------------------------------------------------------------------
Issue 168.
Description:
Minor error in 10.1.
Resolution:
"The containing block in which the root element lives is the viewport
for continuous media" should read "The containing block in which the
root element lives is a rectangle with the dimensions of the viewport,
anchored at the canvas origin, for continuous media".
...since if the ICB was the viwewport itself, you could never scroll.
(Assumed by Bert and Ian without WG consensus.)
Issue closed.
------------------------------------------------------------------------
Issue 169.
Description:
Non-semantic markup.
There are a number of <blockquote>s in section 10 (visudet) that are
clearly not quotations and therefore should not use the <blockquote>
element.
Resolution:
Bert says: no change.
Issue closed.
------------------------------------------------------------------------
Issue 170.
URI: http://www.w3.org/mid/Pine.LNX.4.58.0504221130200.9622@localhost.localdomain
URI: http://www.w3.org/mid/20050422075335.GB6462@ridley.dbaron.org
URI: http://www.w3.org/mid/200504271928.11759.bert@w3.org
Resolution:
   Bert: I suggest replacing the phrase "top of the parent element" with
   Bert "top of the parent's content area"
   Bert: which is what David wanted as well, iirc
   Bert: that's for defining what it meanst for vertical-aligning to text-top and
         text-bottom
And linkify to 10.6.1.
Issue closed.
------------------------------------------------------------------------
Issue 171.
Description:
Problem with earlier resolution in 17.5.3 (issue 164).
Resolution:
Remove "which leaves an empty space below the cell in its table row"
in 17.5.3 last example.
Issue closed.
------------------------------------------------------------------------
Issue 172.
Description:
1.4.1 says "Document language element names are in uppercase letters."
17.5 has an XHTML example, and other parts of the spec have other
examples that aren't in uppercase.
Resolution:
Remove the convention for tag names in 1.4.1.
Assumed editorial by Ian.
Issue closed.
------------------------------------------------------------------------
Issue 173.
Description:
ishida says:
> Note that http://www.ietf.org/rfc/rfc3986 now obsoletes rfc 1808 and updates
> rfc 1738.
Resolution:
Update all mentions of those references.
Assumed editorial by Ian.
Issue closed.
------------------------------------------------------------------------
Issue 174.
URI: http://www.w3.org/mid/427745C0.8020401@fmi.uni-sofia.bg
Description:
| 
| In "4.3.4 URL + URN = URI" of CSS21, there is such paragraph:
| 
|| Parentheses, commas, whitespace characters, single quotes (') and double
|| quotes (") appearing in an unquoted URI must be escaped with a
|| backslash: '\(', '\)', '\,'.
| 
| Shouldn't backslash itself be included in the must-be-escaped list?
| 
| Isn't it better example list to include all these characters (incl.
| whitespace, single quotes and double quotes)?
Resolution:

In 4.3.4:

 Some characters appearing in an unquoted URI, such as parentheses,
 commas, whitespace characters, single quotes (') and double quotes
 ("), must be escaped with a backslash: '\(', '\)', '\,'.

=Tantek= Edit.
------------------------------------------------------------------------
Issue 175.
URI: http://www.w3.org/mid/043a01c55a4b$2da3be40$6a00a8c0@msa
Resolution:
Reply to e-mail. Probably not an issue.
Issue closed.
------------------------------------------------------------------------
Issue 176.
URI: http://www.w3.org/mid/4289e8e9.4323640@smtp.bjoern.hoehrmann.de
URI: http://www.w3.org/mid/42882e25.252959750@smtp.bjoern.hoehrmann.de
URI: http://www.w3.org/mid/200505191843.52845.bert@w3.org
Description:
CSS and URIs.
Resolution:
Fixing the use of terminology (first e-mail) is too much work and
won't be done for CSS2.1 unless we have a team of volunteers who are
willing to do the work and cross-check each other and take
responsibility for fixing any of the fall-out that will occur.

Remove "valid relative" from paragraph 1 of 6.1.2, and change "The
computed value of invalid and absolute URIs is the specified value."
to read:

   The computed value of URIs that the UA cannot resolve to absolute
   URIs is the specified value.

Issue closed.
------------------------------------------------------------------------
Issue 177.
URI: http://www.w3.org/mid/4284D1AB.2080305@mit.edu
Resolution:
Assumed editorial by Ian.
Issue closed.
------------------------------------------------------------------------
Issue 178.
URI: http://www.w3.org/mid/Pine.LNX.4.61.0505101435560.24335@dhalsim.dreamhost.com
Description:
Testcase: http://junkyard.damowmow.com/198
Do cells shrink wrap around the contents or the extent?
Resolution:
No issue.
=Ian= Rewrite test.
Issue closed.
------------------------------------------------------------------------
Issue 179.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0138.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0130.html
Description:
17.5 says:
| Note. Table cells may be positioned, but this is not recommended:
| absolute and fixed positioning, as well as floating, remove a box
| from the flow, affecting table size.
Resolution:
Change the above note to:

 Note. Positioning and floating of table cells can cause them not to
 be table cells any more, according to the rules in <a>section
 9.7</a>. When floating is used, the <a>rules on anonymous table
 objects</a> may cause an anonymous cell object to be created as well.

Issue closed.
------------------------------------------------------------------------
Issue 180.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0138.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0130.html
Description:
The specification does not define what happens if you assign
table-header-group to multiple elements.
| Use of multiple elements with 'display: table-header-group' is
| undefined.
Resolution:
Replace "Use of multiple elements with 'display: table-header-group'
is undefined." with "If a table contains multiple elements with
'display: table-header-group', only the first is rendered as a header;
the others are treated as if they had 'display: table-row-group'."
Issue closed.
------------------------------------------------------------------------
Issue 181.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0138.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0130.html
Description:
Same as 180 but for table footers.
Resolution:
Replace "Use of multiple elements with 'display: table-footer-group'
is undefined." with "If a table contains multiple elements with
'display: table-footer-group', only the first is rendered as a footer;
the others are treated as if they had 'display: table-row-group'."
Issue closed.
------------------------------------------------------------------------
Issue 182.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0138.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0130.html
Description:
Rendering of 'table-caption' width is undefined.
Resolution:

Replace 17.4 with:

  In terms of the visual formatting model, a table can behave like a
  block-level (for 'display: table') or inline-level (for 'display:
  inline-table') element.

  In both cases, the table box generates an anonymous box that
  contains the table box itself and any caption boxes (in document
  order). The caption boxes are block-level boxes that retain their
  own content, padding, margin, and border areas, and are rendered as
  normal blocks inside the anonymous box. Whether the caption boxes
  are placed before or after the table box is decided by the
  'caption-side' property, as described below.

  The anonymous box is a 'block' box if the table is block-level, and
  an 'inline-block' box if the table is inline-level, except that this
  block is never considered as a block for 'run-in' interaction, and
  that the table box (not the anonymous box) is used when doing
  baseline vertical alignment for an 'inline-table'. The width of the
  anonymous box is the border-edge width of the table box inside it,
  as described by section 17.5.2. Percentages on 'width' on the table
  are relative to the anonymous box's containing block, not the
  anonymous box itself.

  The computed values of properties 'position', 'float', 'margin-*',
  'top', 'right', 'bottom', and 'left' on the table box are used on
  the anonymous box instead of the table box. The table box uses the
  initial values for those properties.

  [new image]

Replace the first two paragraphs after the <dl> in 17.4.1 with the
following note:

   Note: CSS2 described a different width and horizontal alignment
   behavior. That behavior will be introduced in CSS3 using the values
   'top-outside' and 'bottom-outside' on this property.

Issue closed.
------------------------------------------------------------------------
Issue 183.
Description:
dbaron wants inline-table to be at risk
Resolution:
No.
Issue closed.
------------------------------------------------------------------------
Issue 184.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0138.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0130.html
Description:
Rendering of multiple 'table-caption's is undefined.
Resolution:

Replace "Use of multiple elements with 'display: table-caption' is
undefined; authors should not put more than one element with 'display:
table-caption' inside a table or inline-table element." in 17.2 with
"All elements with 'display: table-caption' must be rendered, as
described in section 17.4.". (See issue 182 for the text that affects
that.)

Issue closed.
------------------------------------------------------------------------
Issue 185.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0138.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0130.html
Description:
"User agents must find a consistent rule for rounding off in the case
of an odd number of discrete units (screen pixels, printer dots)." is
vague.
Resolution:
Leave as is.
Issue closed.
------------------------------------------------------------------------
Issue 186.
Description:
Section 17.5.2 should have numbered subsections.
Resolution:
Yes, they should.
Issue closed.
------------------------------------------------------------------------
Issue 187.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0138.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0130.html
Description:
"If the table has 'width: auto', a percentage represents a constraint
on the column's width, which a UA should try to satisfy." is vague.
Resolution:

  In section "Automatic table layout" (17.5.2.2):

  In paragraph 1, change "they can use any other algorithm" to "they
  can use any other algorithm even if it results in different
  behavior".

  Change "Input to this algorithm" to "Input to the automatic table
  layout" in the third paragraph.

  Move that third paragraph (now "Input to the automatic table
  layout") to before the second paragraph ("This algorithm may be
  inefficient").

  After that (now second) paragraph ("Input to the automatic table
  layout"), add a note that reads "This may be defined in more detail
  in CSS3." followed by a paragraph that reads: "<em>The remainder of
  this section is non-normative.</em>".

Issue closed.
------------------------------------------------------------------------
Issue 188.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0138.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0130.html
Description:
(Fallout from issue 142.) 'min-width' shouldn't apply to tables.
Resolution:
Keep it.
Issue closed.
------------------------------------------------------------------------
Issue 189.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0138.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0130.html
Description:
What does 'width' mean on 'table-column-group'.
Resolution:
Make 'width' on 'table-column-group' set the width of the column
group, not the individual columns.
Issue closed.
------------------------------------------------------------------------
Issue 190.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0138.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0130.html
Description:
What do percentages on 'width' mean on 'table-column-group'.
Resolution:
Resolve in CSS3.
Issue closed.
------------------------------------------------------------------------
Issue 191.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0138.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0130.html
Description:

CSS2.1 spec explicitly refuses to define the case in which the height
is set but the number of rows is taller or smaller. It is noted that
this will be defined in future versions of CSS. We should define this
now.

If the table height is bigger than the height, ignore the height.

Resolution:

Replace, in 17.5.3 (note: the note remains after this edit):

   "CSS 2.1 does not specify rendering when the specified table height
   differs from the content height, in particular whether content
   height should override specified height; if it doesn't, how extra
   space should be distributed among rows that add up to less than the
   specified table height; or, if the content height exceeds the
   specified table height, whether the UA should provide a scrolling
   mechanism."

...with:

   "The 'height' property on 'table' boxes is treated as a minimum
   height. CSS 2.1 does not define how extra space is distributed when
   the 'height' property to be taller than it otherwise would be."

Issue closed.
------------------------------------------------------------------------
Issue 192.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0138.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0130.html
Description:
Percentage heights on table cells are undefined.
Percentage heights on table rows and row groups are undefined.
http://damowmow.com/playground/demos/percentages/003.html
Resolution:

Change 17.5.3:

  CSS 2.1 does not define what percentage values of 'height' refer to
  when specified for table rows and row groups.

...to:

  Percentage heights on table cells, table rows, and table row groups
  compute to 'auto'.

Issue closed.
------------------------------------------------------------------------
Issue 193.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0062.html
Description:
   DBaron: two issues raised on the mailing list
   DBaron: one was a typo that I don't think was a typo
   DBaron: I think it just needs a reply on list
   DBaron: then there's an issue about URIs
   DBaron: some characters need to be escaped with a backslash
   Markus: We should add a link to Appendix E in Section 9.9.1 to better explain
           the stacking order
Resolution:
Add link to Appendix E somewhere in 9.9.1
=Tantek= Edit.
------------------------------------------------------------------------
Issue 194.
URI: http://www.w3.org/mid/3F6865DB7477EF4A8F79ABCB18DC7E5B01AFCE14@cacexc06.americas.cpqcorp.net
Description:
The page property was removed from CSS 2.1 because there were
insufficient implementations. Is it possible to revisit that at this
point?
Resolution:
No.
Issue closed.
------------------------------------------------------------------------
Issue 195.
Description:
There is a "the the" typo in 17.6.1.
Resolution:
Assumed editorial.
Issue closed.
------------------------------------------------------------------------
Issue 196.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0138.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0130.html
Description:
How a row-spanning cell affects the heights of the rows that are
spanned, except that the rows have to contain the spanning cell, is
not defined.
 +----+----+
 |100 | 30 |
 |    +----+
 |    | 30 |
 +----+----+
Resolution:

Add the following as a non-normative note at the top of chapter 17:

  This chapter defines the processing model for tables in CSS. Part of
  this processing model is the layout. For the layout, this chapter
  introduces two algorithms; the first, the fixed table layout
  algorithm, is well-defined, but the second, the automatic table
  layout algorithm, is not fully defined by this specification.

  For the automatic table layout algorithm, some widely deployed
  implementations have achieved relatively close interoperability.

Issue closed.
------------------------------------------------------------------------
Issue 197.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0138.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0130.html
Description:
It is undefined for table-layout:fixed what happens if a subsequent
row has more columns than the first.

Proposal1: Ignore (display:none) any additional columns and
column-spans defined on the second row beyond the number defined on
the first row will be truncated to the number in the first row.

Proposal2:

Change:

  It is undefined what happens if a subsequent row has more columns
  than the first. When using 'table-layout: fixed', authors should not
  omit columns from the first row.

...to:

  If a subsequent row has more columns than the first, then additional
  columns are rendered off the (original) edge of the table. New
  columns either have the widths specified for the cells in the first
  row that has that column, or, if that is 'auto', the width given by
  the (original) width of the table divided by the number of columns
  in the first row (i.e. the width that you would give a column in the
  first row if none of the cells had any widths specified).

  When using 'table-layout: fixed', authors should not omit columns
  from the first row.

Resolution:
Proposal3:

Change:

  It is undefined what happens if a subsequent row has more columns
  than the first.

...to:

  If a subsequent row has more columns than the first, then additional
  columns must not be rendered.

Issue closed.
------------------------------------------------------------------------
Issue 198.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0138.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0130.html
Description:
How do you set scrollbars for a row-group? Should we not be allowed to
scroll a row-group (tbody)?
Overflow property is not defined on row-groups.
Proposal: Consider for CSS3.
Resolution:
Do nothing.
Issue closed.
------------------------------------------------------------------------
Issue 199.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0138.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0130.html
Description:
What if spanned rows and columns intersect a collapsed column or row?
Resolution:
Contents of spanned rows and columns that intersect the collapsed
column or row are clipped.
Issue closed.
------------------------------------------------------------------------
Issue 200.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0138.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0130.html
Description:
What does url() mean on 'content'.
i.e. what are the media types UAs are required to support in 'content'
and other properties.
Resolution:

12.2: Change:

  "The value is a URI that designates an external resource."

To:

  "The value is a URI that designates an external resource (such as an
  image)."

Issue closed.
------------------------------------------------------------------------
Issue 201.
Description:
cover.html uses CSS3LISTS and refs.html uses CSS3LIST.
Resolution:
Assumed editorial by Ian.
Issue closed.
------------------------------------------------------------------------