csswg-drafts/css2/issues/issues-2 at f3794fd3e28860195004639497a3019e3e42153d · w3c/csswg-drafts

3065 lines (2797 loc) · 119 KB
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.$
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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
This makes print-preview non-conformant according to some people.
Resolution:
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> 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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
Section: 5.12.1 The :first-line pseudo-element
URI: http://lists.w3.org/Archives/Public/www-style/2004Feb/0330.html
Resolution:
# A UA should act as if the fictional start tag of the first-line
# pseudo-element is just inside the innermost enclosing block-level
| 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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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).
| 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.
------------------------------------------------------------------------
Section: 4.4.1 Referring to characters not represented in a character encoding
URI: http://www.w3.org/mid/1488001767.20040224031102@w3.org
------------------------------------------------------------------------
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
Issue closed.
------------------------------------------------------------------------
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...
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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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:
Issue closed.
------------------------------------------------------------------------
Description:
Kimberly should either be an editor or an acknowledged.
Resolution:
Acknowledge.
Issue closed.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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: 
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>
 <dt>New 'list-style-type' values</dt>
   <li>'armenian'</li>
   <li>'georgian'</li>
   <li>'lower-greek'</li>
  <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>
Remove from 12.5.1:
# A user agent that does not recognize a numbering system should use
# 'decimal'.
Issue closed.
------------------------------------------------------------------------
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.
| 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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
Section: 3.2 Conformance
Description:
It's unclear that CSS requires that UAs let authors disable all author
stylesheets.
Issue closed.
------------------------------------------------------------------------
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
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.
------------------------------------------------------------------------
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
: 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. 
: 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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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,
------------------------------------------------------------------------
Description:
<exclipy> In CSS2.1:12.5.1, the list-style-type values "lower-alpha"
and "upper-alpha" aren't listed formally.
Issue closed.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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.
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:
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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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
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.
  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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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
...which is good enough.
Issue closed.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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
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
This may be a consistent compromise:
section 15.7
font-size      xx-small x-small small  medium  large  x-large xx-large
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: 
6197
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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
URI: http://www.w3.org/mid/5365489$10804178564065de40129434.27614134@config21.schlund.de
Description:
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.
------------------------------------------------------------------------
URI: http://www.w3.org/mid/5365489$10804178564065de40129434.27614134@config21.schlund.de
Description:
section 4.1.2: -khtml- is a known vendor-specific extension too.
Resolution:
Do nothing.
Issue closed.
------------------------------------------------------------------------
URI: http://www.w3.org/mid/20040504012730.GA8545@darby.dbaron.org
Resolution:
   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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
URI: http://www.w3.org/mid/408AC1C4.4060106@mit.edu
Resolution:
Issue closed.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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'
Issue closed.
------------------------------------------------------------------------
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.
# 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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
Description:
CSS2.1 should clarify the ability for implementations and
specifications to extend the CSS language.
Resolution:
| 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
...at an appropriate place in chapter 4 (e.g. first paragraph of 4.2,
or in 4.1).
Issue closed.
------------------------------------------------------------------------
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
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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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:
Issue closed.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
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.
View remainder of file in raw view
Provide feedback

Saved searches

Use saved searches to filter your results more quickly

FilesExpand file tree

issues-2

Latest commit

History

issues-2

File metadata and controls
