issues-3

CSS2.1 Second Last Call Issues List
===================================

OPEN ISSUES have the marker =WG= in them.

TO RESOLVE AN ISSUE add the line "Resolution:" followed by the
description of the resolution, and then a line on its own with either
one of "=Bert= Edit.", "=howcome= Edit.", and "=Tantek= Edit.", if an
edit is to be made, or just the line "Issue closed." if the issue is
closed. See other issues for examples.

------------------------------------------------------------------------
Issue 1.
URI: http://lists.w3.org/Archives/Public/www-style/2005Jun/0034.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2004JulSep/0062
Description:
img:before not defined
Resolution:
img:before explicitly not defined in CSS2.1 because we are looking for
implementation and author feedback and will define this in more detail
in CSS3.
We never actually put our resolution in the spec, though.

Add the following sentence to the end of section 12.1 "The :before and
:after pseudo-elements":

   This specification does not fully define the interaction of :before
   and :after with replaced elements (such as IMG in HTML). This will
   be defined in more detail in CSS3.

Issue closed.
------------------------------------------------------------------------
Issue 2.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0157.html
Description:
> Hyatt wrote:
> > I definitely think CSS 2.1 should not be dictating the precise position of
> > the tab stops.  I would prefer it be reworded as a guideline/advisory.  How
> > about changing the text at
> > http://www.w3.org/Style/Group/css2-src/text.html#q8
> > 
> > to:
> >    
> > "All tabs (U+0009) are rendered as a horizontal shift that lines up the
> > start edge of the next glyph with the next tab stop. Tab stops occur at
> > points determined by the user agent.  One possible algorithm for user agents
> > to use when determining tab stops is at multiples of 8 times the width of a 
> > space (U+0020) rendered in the block's font from the block's starting
> > content edge."
Resolution:
No change.
------------------------------------------------------------------------
Issue 3.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0165.html
Description:
Unclear that word-spacing applies to NBSP characters.
Proposed changes (text.html, section "Letter and word spacing"):
  change
   "When white space is preserved, e.g. with 'white-space:pre', all
    space characters are affected by word-spacing."
  to
   "Word spacing affects each space (U+0020), non-breaking space
    (U+00A0), and ideographic space (U+3000) left in the text after
    the white space processing rules have been applied."
Resolution:
Apply change described above.
Issue closed.
------------------------------------------------------------------------
Issue 4.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0175.html
Description:
I was just looking at the HTML diffs, and noticed that the computed
value for 'content' probably needs to reflect what is stated in the
definition of the 'normal' value:  that a specified value of 'normal'
computes to 'none' for pseudo-elements:

  http://www.w3.org/TR/2005/WD-CSS21-20050613/generate.html#content

(Should it also say that the computed value for elements is always
normal?  Are we consistent about how we describe computed values in
cases where a property doesn't apply?)

Proposal: Change the 'computed value' line to:

  On elements, always computes to 'normal'. On :before and :after, if
  'normal' is specified, computes to 'none'. Otherwise, for URI
  values, the absolute URI; for attr() values, the resulting string;
  for other keywords, as specified.

Resolution:
Apply change described above.
Issue closed.
------------------------------------------------------------------------
Issue 5.
URI: http://weblogs.mozillazine.org/roc/archives/2005/06/displayinline_a.html
Description:
Authors use 'display:inline' on <table> elements to make inline
tables, which works in IE but breaks in compliant UAs.

Proposal: Add the following statement in 17.2.1 in points 2, 3, and 4
after the sentences ending in "P and T":

   If P is an 'inline' box, then the generated box must be an
   'inline-table' box instead of a 'table' box.

Resolution:
Accept proposal.
Issue closed.
------------------------------------------------------------------------
Issue 6.
Description:
(o173071)
The grammar definition of an identifier differs from the prose
definition. The prose, in fact, has two separate definitions for
different things.

Resolution:
=David= Come up with better text to replace 4.1.3 bullet 2.
=Hixie= Come up with better text to replace 4.1.3 bullet 2.
------------------------------------------------------------------------
Issue 7.
Description:
The following note is repeated twice in the current draft. (Section 5.8.3)
# Note: If an element has multiple class attributes, their values must
# be concatenated with spaces between the values before searching for
# the class. As of this time the working group is not aware of any
# manner in which this situation can be reached, however, so this
# behavior is explicitly non-normative in this specification.
At least a bazillion people reported this duplicate paragraph.
Resolution:
Assumed editorial.
Issue closed.
------------------------------------------------------------------------
Issue 8.
URI: http://www.w3.org/mid/Pine.GSO.3.96.1050615183256.27687C-100000@rmi-sun.rmi.acnet.ge
Description:
Request for CSS2.1 to address namespaced selectors.
Resolution:
Rejected, too late. Proposed text already in CR.
Issue closed.
------------------------------------------------------------------------
Issue 9.
URI: http://www.w3.org/mid/Pine.GSO.3.96.1050615185433.27687D-100000@rmi-sun.rmi.acnet.ge
Description:
Interaction of lists and counters.
Resolution:
Response: http://www.w3.org/mid/20050615164224.GA29310@ridley.dbaron.org
Issue closed.
------------------------------------------------------------------------
Issue 10.
URI: http://www.w3.org/mid/42B07254.6039.F863E@localhost
URI: http://www.w3.org/mid/42FA474B.6855.268DB0@localhost
Response: http://www.w3.org/mid/200509131657.33583.bert@w3.org
URI: http://www.w3.org/mid/43296F0E.3000507@comhem.se
Response: http://lists.w3.org/Archives/Public/www-style/2005Sep/0135.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Sep/0178.html
Description:
Discussion about the replaced element intrinsic sizing rules,
concluding with the following question: "does the table under
'max-width' still work when the replaced elements use the intrinsic
ratio?"

Resolution:

  Replace "In this table, w and h stand for the intrinsic width and
  height, respectively." with:

  "In this table <var>w</var> and <var>h</var> stand for the results
  of the width and height computations ignoring the 'min-width',
  'min-height', 'max-width' and 'max-height' properties. Normally
  these are the intrinsic width and height, but they may not be in the
  case of replaced elements with intrinsic ratios."

Issue closed.
------------------------------------------------------------------------
Issue 11.
Description:

It was pointed out in [1] that there is an error in the first example
in section 12.4 [2]. The simplest fix is to add a style rule to the
example:

  body { counter-reset: chapter; }   /* create a chapter counter scope */

so that the implicit counter creation rules don't create a separate
counter for each header.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=288946
[2] http://www.w3.org/TR/2005/WD-CSS21-20050613/generate.html#counters

Resolution:
Make edit as suggested.
Issue closed.
------------------------------------------------------------------------
Issue 12.
URI: http://www.w3.org/mid/Pine.LNX.4.61.0506181311570.32467@tuomi.oulu.fi
Description:
http://www.w3.org/TR/CSS21/conform.html#x22
| For example, table-column-group elements cannot have borders around
| them, so the border properties must be ignored.

As table-column-group can have borders around them in collapsed border
Better example might be: table-column elements can't affect to font of
column, so the font properties must be ignored.

Resolution:
Make edit as suggested.
Issue closed.
------------------------------------------------------------------------
Issue 13.
URI: http://www.w3.org/mid/op.sskju0zvk4suho@briann.wlfdle.phub.net.cable.rogers.com
Description:
The note near the end of the section is not closed. This has the
unfortunate side-effect of propagating the element's green styling to
the rest of the document in some agents. :(

Resolution:
Fix markup.
Issue closed.
------------------------------------------------------------------------
Issue 14.
URI: http://www.w3.org/mid/20050623172020.GA5947@ridley.dbaron.org
Description:
On Thursday 2005-06-23 21:05 +1000, Michael Day wrote:
> Can pseudo-elements that are not generated still affect counters?
>
> For example:
>
> h1::before {
>     content: normal;
>     counter-increment: heading;
> }

I think not.  I thought 12.4.3 said so explicitly, but apparently it
doesn't.  It probably should.

Resolution:
Make edit as suggested.
Issue closed.
------------------------------------------------------------------------
Issue 15.
URI: http://www.w3.org/mid/ef5d0f2f05062802487bdc96da@mail.gmail.com
Description:
'Implementors are urged to implement these features, or correct bugs
in their implementations, if they wish to see thsse features remain in
this specification.'

'thsse' should be 'these', I believe.
Resolution:
Fix typo.
Issue closed.
------------------------------------------------------------------------
Issue 16.
URI: http://www.w3.org/mid/42C69AC2.4050504@lachy.id.au
Description:
While attempting to greatly improve upon some CSS tests I had
written previously for the border collapse conflict resolution
algorithm, I've come across an issue in the spec. Step 4 of the
conflict resolution algorithm states [1]:

4. If border styles differ only in color, then a style set on a cell
   wins over one on a row, which wins over a row group, column, column
   group and, lastly, table. It is undefined which color is used when
   two elements of the same type disagree.

It needs to be defined which border of two elements of the same type
takes precedence when they only differ by colour. Both Firefox and
Opera take a completely different approach, yet because the behaviour
is undefined, both are correct. See the test case [2].

Firefox seems to apply the border colour from the cell above or the
left, while Opera seems to apply the border colour from the cell below
or to the right. I think it makes more sense the way Firefox
implements it, but either way, I think it should be defined.

[1] http://www.w3.org/TR/CSS21/tables.html#border-conflict-resolution
[2] http://lachy.id.au/dev/css/tests/bordercollapse/012

Testcase demo: http://junkyard.damowmow.com/207

Resolution:

In 17.6.2.1: Change

 4. If border styles differ only in color, then a style set on a cell
    wins over one on a row, which wins over a row group, column,
    column group and, lastly, table. It is undefined which color is
    used when two elements of the same type disagree.

...to:

 4. If border styles differ only in color, then a style set on a cell
    wins over one on a row, which wins over a row group, column,
    column group and, lastly, table. When two elements of the same
    type conflict, then the one further to the left (if the table's
    'direction' is 'ltr'; right, if it is 'rtl') and further to the
    top wins.

Issue closed.
------------------------------------------------------------------------
Issue 17.
URI: http://www.w3.org/mid/Pine.LNX.4.61.0507022020550.11931@dhalsim.dreamhost.com
Description:

9.4.2, para 4:

> "If that property has the value 'justify', the user agent may stretch
> the inline boxes as well."
>
> Does UA allowed to stretch *all* inline boxes (including inline blocks) ?

Resolution:

inline-blocks and inline-tables and their contents shouldn't be
affected here, only actual display:inlines.

In 9.4.2, change "the user agent may stretch the inline boxes as
well." to "the user agent may stretch spaces and words in
display:inline boxes as well." In 16.2, change "the UA may stretch the
inline boxes in addition to adjusting their positions" to "this
property specifies that the text is to be made flush with both sides
of the block".

Further discussion at:
   http://www.w3.org/mid/43271016.6010701@inkedblade.net
   http://www.w3.org/mid/200509141456.08425.bert@w3.org
...which may suggest better text.

=Tantek= Edit. If you can find better ways of solving this, let us know.
------------------------------------------------------------------------
Issue 18.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0034.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0038.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0039.html
Description:

Proposal to use 'padding edge' not 'content edge' in 10.1, for
inlines.

Resolution:

Specifically, the three occurances of "content" in 10.1 list item 4
should be changed to "padding" (and then change "right edges" to
"right padding edges" in the second sub-list item).

Issue closed.
------------------------------------------------------------------------
Issue 19.
URI: http://www.w3.org/mid/8E265F97-14C9-44D0-9BF5-37D4E8377447@w3.org
Response: http://lists.w3.org/Archives/Public/www-style/2005Jul/0329.html
Description:
Versioning information story.
Resolution:
Assumed by Bert, Ian: Do nothing as per Sophia F2F.
Issue closed.
------------------------------------------------------------------------
Issue 20.
URI: http://www.w3.org/mid/A0700B54-BD9F-4C0A-BDE0-D5C3A64B707C@w3.org
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0171.html
Description:
Request for implementation report of CSS2 in terms of CSS2.1.
Resolution:
Assumed by Ian that this would be WAY too much work and that we don't
want to do it.
Asked Karl if Appendix C is enough.
Issue closed.
------------------------------------------------------------------------
Issue 21.
URI: http://www.w3.org/mid/20050712214143.GB671@ridley.dbaron.org
Description:

I just noticed one more change that I think we need to make in section
10.4.  We should change the sentence:

  However, for replaced elements with both 'width' and 'height'
  specified as 'auto', the algorithm is as follows:

to be:

  However, for replaced elements with an intrinsic ratio and both
  'width' and 'height' specified as 'auto', the algorithm is as follows:

because I don't think these rules are intended to apply to IFRAMEs or
OBJECTs that embed HTML documents.  (It was clearer that they didn't
make sense before the change we agreed to this morning that made them
work for the intrinsic-ratio-but-no-intrinsic-size case.)

-David

Resolution:

Agreed.

Issue closed.
------------------------------------------------------------------------
Issue 22.
URI: http://www.w3.org/mid/EDECFB54-2989-465B-AA38-088DD3F5011C@w3.org
Description:

It is said that

[[[
Conforming user agents must correctly map to Unicode all characters in
any character encodings that they recognize (or they must behave as if
they did).
]]] - http://www.w3.org/TR/2005/WD-CSS21-20050613/syndata.html

The way you define references is very important. The sentence is a bit
vague here with regards to Unicode.
See   http://www.w3.org/TR/qaframe-spec/#ref-define-practice

For unicode specifically, the specification Charmod explains how to
reference Unicode.
http://www.w3.org/TR/2005/REC-charmod-20050215/#sec-RefUnicode

-Karl

Resolution:

Editorial.

For Unicode, resolution is to refer to latest (dynamic).

Issue closed.
------------------------------------------------------------------------
Issue 23.
URI: http://www.w3.org/mid/AAAB784B-9C78-4C1C-9403-092E7BA57916@w3.org
URI: http://www.w3.org/mid/i51ekacjbi2.wl@w3.mag.keio.ac.jp
URI: http://www.w3.org/mid/9750588.1121456022734.JavaMail.servlet@kundenserver
URI: http://www.w3.org/mid/op.svanzwqtsmjzpq@r600
Description:

Request to update HTML4.0 references to HTML4.01.

Resolution:

Done.

Issue closed.
------------------------------------------------------------------------
Issue 24.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> Use of terms: "version" vs. "level" vs. "revision"
>
> For me, the use of terms "version" and "level" is confusing, especially
> since "version" is not defined in the specification. Is "version" to
> mean ("level"|"revision")?

Resolution:

Change "any version of CSS" to "any level of CSS".

   syndata: 4.1, 4.1.4

Change "future version of CSS" to "future update of CSS".

   syndata: 4.1, 4.1.7, 4.2 (twice)
   media: 7.3
   visfx: 11.1.2
   tables: 17.5, 17.5.2, 17.5.3

Change "a previous version of this specification" to "a previous
revision of this specification".

   visfx: 11.1.2

Change "updated version" to "updated revision".

   changes: C

Issue closed.
=Hixie= Search for "version" when the spec is done.
------------------------------------------------------------------------
Issue 25.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> Missing: List of special CSS characters
>
> The specification refers to "special CSS characters" that e.g. need
> escaping. I haven't found a list of these special characters. Have these
> to be inferred from parsing context and the core grammar?
> <http://www.w3.org/TR/CSS21/syndata.html#q6> (third bullet)

Resolution:

You have to derive it. In practice you don't need it; as an
implementor you just implement the grammar and make "\" skip past the
part of the code that looks for special characters. As an author you
just stick a "\" in when things don't work.

Issue closed.
------------------------------------------------------------------------
Issue 26.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> Missing: Resolving escapes
>
> Though probably not absolutely required, it would be helpful to have it
> explained that character escapes in tokens must be resolved before
> performing any (mostly: comparison-) operation, so that i.e. an
> identifier written as "te\st" is considered the same as if it had been
> written as "test". This would complement the already existing note that
> pre-processors must not resolve quotes.
> <http://www.w3.org/TR/CSS21/syndata.html#q6> (third bullet)

Resolution:

At the end of 4.1.3, add a sentence saying something like "The
identifier "te\st" is exactly the same identifier as "test".".

Issue closed.
------------------------------------------------------------------------
Issue 27.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> Use of terms: "ISO 10646" vs. "Unicode"
>
> In most places in chapter 4, ISO 10646 is referenced for character set.
> However, in two places the term "Unicode" is used (4.3.7 and 4.4.1). For
> consistency reasons, ISO 10646 should be used in those two places instead.
> <http://www.w3.org/TR/CSS21/syndata.html#strings>
> <http://www.w3.org/TR/CSS21/syndata.html#q24>

Resolution:

Editorial.

Issue closed.
------------------------------------------------------------------------
Issue 28.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> Inconsistent spelling
>
> Throughout chapter 4, spelling of the following terms is changes randomly:
>
>        style sheet  <-->  stylesheet
>             CSS2.1  <-->  CSS 2.1
>  declaration block  <--> declaration-block
>
> I suggest picking one and sticking with it.

Resolution:

"style sheet" two words, "declaration block" two words, "CSS 2.1" with
a space.

Be careful not to change the grammar token "stylesheet"!!

Issue closed.
=Hixie= Verify when the spec is done.
------------------------------------------------------------------------
Issue 29.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> Concern: starting identifiers with hyphens
>
> I have voiced my concerns and objection to allowing identifiers to start
> with an unquoted hyphen vehemently in the past and will leave it
> therefore at it.

Resolution:
Ok then...
Issue closed.
------------------------------------------------------------------------
Issue 30.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> All levels of CSS -- level 1, level 2, and any future levels -- use the
> same core syntax. This allows UAs to parse (though not completely
> understand) style sheets written in levels of CSS that didn't exist at
> the time the UAs were created.
> ]]]
>   and
> [[[
> The list of tokens for CSS2.1 is as follows.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#tokenization>
> 
> If all levels of CSS use this *same* core syntax, then why is it only the
> list of tokens for *CSS 2.1* and not all versions of CSS? Remove the
> reference to CSS 2.1 in the second sentence.

Resolution:

Change "The list of tokens for CSS 2.1 is as follows." to "The list of
tokens for CSS is as follows."

=Tantek= Edit.
------------------------------------------------------------------------
Issue 31.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> Appendix G describes a more restrictive grammar that is closer to the CSS
> level 2 language.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#tokenization>
> 
> I have three issues with the wording of this sentence:
> 
> (1) The reader is aware that he is reading the description for the core
> syntax. This reference has potential making him wonder whether what he
> reads is something normative or is not "the real" grammar he has to observe.
> 
> Suggestion: Remove this reference to Appendix G completely.

Resolution:

In section 4.1.1 Tokenization, at the end of the paragraph starting
"Below is the core syntax for CSS", add "Parts of style sheets that
can be parsed according to this grammar but not according to the
grammar in Appendix G are among the parts that will be ignored
according to the <a>rules for handling parsing errors</a>."

=Tantek= Edit.
------------------------------------------------------------------------
Issue 32.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> Appendix G describes a more restrictive grammar that is closer to the CSS
> level 2 language.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#tokenization>
> 
> I have three issues with the wording of this sentence:
> 
> (2) When Appendix G describes a more restrictive grammar that is closer
> to CSS level 2 language (or isn't it CSS 2.1 ?), but still not CSS level
> 2, then why bother to specify it at all? Just describe the constructs in
> detail and unambigously in the description of the various parts (sections
> 4.1.2 ff.) - which you have done already - and don't bother to give a
> grammar at all. Why? Giving this grammar may lead implementors into
> believing they can use that grammar as-is for their implementation, when
> in fact they can't due to the many restrictions and error handling
> requirements which are not implementable by throwing the grammar at a
> scanner/parser generator. They might waste their time in doing this, just
> to find out some time later that a generated parser using the
> normative(!) grammar will not be easily forced into being a conforming
> parser, and that they would have been way better off in implementing the
> spec as described verbally (they'd have probably written a recursive
> descent parser manually right from the beginning, thereby having saved
> several hours of work.)
> 
> Suggestion: Remove this reference to Appendix G completely.

Resolution:
Resolved by issue 31.
Issue closed.
------------------------------------------------------------------------
Issue 33.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> Appendix G describes a more restrictive grammar that is closer to the CSS
> level 2 language.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#tokenization>
> 
> I have three issues with the wording of this sentence:
> 
> (3) <nit-picking> Finally, when you want to give a grammar that is
> "closer to the CSS level 2 language", just how close is it? As far as it
> gets? As far as you managed? Why didn't you specify some more grammars
> that are "reasonably close", "a little closer" and "way close" as well?
> 
> Suggestion: Remove this reference to Appendix G completely.

Resolution:
Resolved by issue 31.
Issue closed.
------------------------------------------------------------------------
Issue 34.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> The meaning of input that cannot be tokenized or parsed is undefined in
> CSS2.1.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#tokenization>
> 
> I suggest removing the reference to CSS 2.1 here. This is the section on
> core grammar valid for all levels of CSS: there should not be a reference
> to the current level. When you need to apply restrictions to the core
> grammar, make it a specific section, "CSS 2.1 Grammar restrictions". This
> way, when there are several levels of CSS available to be implemented,
> readers of the spec have a chance to easily compare restrictions between
> levels they need to implement without having to browse through the
> otherwise identical descriptions of the core grammar, which - due to its
> nature - should never change in the future.

Resolution:
No change.
<David> I think this should stay the same. I think me may define this in
future versions.
<Ian> I agree.
<David> It can change as along as it is a backwards compatible change.
<Bert> No change.
Issue closed.
------------------------------------------------------------------------
Issue 35.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0141.html
Description:

> Suggestion of sectioning:
> - 4.1 CSS Core grammar: consists essentially of current 4.1.1 with
> references to CSS 2.1 removed.
> - 4.2 Grammar of CSS 2.1: consists of 4.2.1 with restrictions to the core
> grammar now in 4.1.1, and continues with 4.1.2, ... relabelled to 4.2.2, ...
> 
> Of course, it would even be better to separate general constructs'
> descriptions which will not change (e.g. "Statement", "At-rule", ...)
> into the core grammar description, and then add restrictions for CSS 2.1
> in the CSS 2.1 grammar's section. It makes it much easier for
> implementors to decide on factorings and identifying features to be put
> into the parser core and which should go into configurable CSS profile
> support.

Resolution:

We will consider this for CSS3, but it doesn't seem appropriate for
CSS2.1 right now (not a change of functionality, so too late at this
time to change 2.1).

Issue closed.
------------------------------------------------------------------------
Issue 36.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> Keywords have the form of identifiers.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#keywords>
> 
> The term "identifiers" is nowhere clearly visibly defined in the
> specification, though a link later in the document suggests that this
> should be the second item in the list in 4.1.3. Please add a link here
> since it is a forward reference to the definition.

Resolution:

Add link in 4.1.2 to make this clearer.

=Tantek= Edit.
------------------------------------------------------------------------
Issue 37.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> Keywords and property names,...
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#q4>
> 
> The term "property names" is a *forward* reference to its definition in
> 4.1.8 (although there, only *property* is actually defined, but not
> *property name*). Suggesting to make it link to that section.

Resolution:

Add link.

=Tantek= Edit.
------------------------------------------------------------------------
Issue 38.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> In CSS2.1, identifiers may begin with '-' (dash) or '_' (underscore).
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#q4>
> 
> According to the core grammar, identifiers (assuming this being IDENT
> tokens) may start with these characters in *all* versions and levels of
> CSS, not just CSS 2.1 . I guess you mean to say that it is in the
> *keywords* and *property names* that CSS 2.1 allows them for use as
> vendor-specific extensions designators, but nowhere else.

Resolution:

Drop "2.1" and make it just "In CSS, identifiers..."

=Tantek= Edit.
------------------------------------------------------------------------
Issue 39.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> An initial dash or underscore is guaranteed never to be used in a
> property or keyword...
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#q4>
> 
> Is "property" a synonym for "property name", or are these two different
> things? If it is the same (and it seems to be when reading 4.1.8), why is
> there the term "property name" used earlier in 4.1.2.1? Looks like it
> should be "property" only.

Resolution:

Answer is "yes", "property" and "property name" mean the same thing.

Change "property" to "property name" in two places in 4.1.8: in first
paragraph and in first paragraph after example.

=Tantek= Edit.
------------------------------------------------------------------------
Issue 40.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> ...consists of a list of statements (see the grammar above).
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#q7>
> 
> Suggestion: Remove "(see the grammar above)" and link "statements" to the
> respective line in the core grammar.

Resolution:

Link "grammar" to the grammar, but leave the bit in parentheses.

=Tantek= Edit.
------------------------------------------------------------------------
Issue 41.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> In this specification, the expressions "immediately before" or
> "immediately after" mean with no intervening whitespace or comments.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#q7>
> 
> This definition is rather buried, especially since it is not at 4.1-
> level, but can be construed to be part of 4.1.4-level. Move this up to
> 4.1, Syntax, introduction.

Resolution:

Editorial, but move it to 4.1.

=Tantek= Edit.
------------------------------------------------------------------------
Issue 42.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> ...after any valid rule other than an @charset or an @import rule.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#at-rules>
> 
> Inconsistent usage of the term "rule" (first occurrence in sentence
> above): Later in 4.1.7, "rule" is defined to be a synonym for "rule set".
> Neither @charset nor @import are a rule set, however; they're at-rules.
> So the first occurrence of "rule" in the above should be changed to
> "statement".

Resolution:

Do exactly what he asks for (in 4.1.5).

=Tantek= Edit.
------------------------------------------------------------------------
Issue 43.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> ...to achieve the effect of only importing a style sheet for 'print' media,
> use the @import with media syntax...
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#at-rules>
> 
> Should probably be: "...use the @import rule with media syntax..." ("rule" added).

Resolution:

Do exactly what he asks for.

=Tantek= Edit.
------------------------------------------------------------------------
Issue 44.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> In between there may be any characters...
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#block>
> 
> Shouldn't this better read: "In between there may be any tokens..."? If
> not, what's the rationale behind using "characters"? Changing to "tokens"
> in the above would also mean you could drop "Single (') and double quotes
> (")  must also occur in matching pairs, and characters between them are
> parsed as a string. See Tokenization above for the definition of a
> string." completely. Honestly, I do not understand why this description
> is falling back onto character level when there is a generally valid
> tokenization definition given already that is also universally valid for
> every style sheet.

Resolution:

Change "characters" to "tokens" in that sentence but do nothing else. (4.1.6)

=Tantek= Edit.
------------------------------------------------------------------------
Issue 45.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> ...followed by a declaration block. A declaration-block...
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#q10>
> 
> Use consistent hyphenation for declaration block (i.e., none).

Resolution:
See issue 28.
Issue closed.
------------------------------------------------------------------------
Issue 46.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> ...also called a {}-block in the following text...
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#q10>
> 
> I think it's unfortunate to use that abbreviation. When reading aloud,
> one always must remember how to pronounce "{}-block": Is it "braces-
> block"...? Or what was it again...? Well, it's a "declaration block", so
> why not keep using that as written? Same goes with the rule set
> abbreviation: Why introduce it? It makes communication more fragile
> between different people when there is a synonym to remember for each
> basic concept.

Resolution:

Replace "{}-block" with "declaration block" throughout that section
(used twice), and remove the "also called a" part that introduces the
term in the first place. (4.1.7)

=Tantek= Edit.
------------------------------------------------------------------------
Issue 47.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> Because of the way selectors work, multiple declarations for the same
> selector may be organized into semicolon (;) separated groups.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#declaration>
> 
> I think when turning around the above sentence, it is more precise:
> 
> "A semicolon (;) separated list of declarations in the declaration block
> for a specific selector may be used as a shorthand for multiple single-
> declaration rule sets with the same selector in the same order.
> 
> Thus, the following rule
> 
> h1 {
>   font-weight: bold;
>   font-size: 12px;
>   line-height: 14px;
>   font-family: Helvetica;
>   font-variant: normal;
>   font-style: normal
> }
> 
> is equivalent to
> 
> h1 { font-weight: bold }
> h1 { font-size: 12px }
> h1 { line-height: 14px }
> h1 { font-family: Helvetica }
> h1 { font-variant: normal }
> h1 { font-style: normal }"

Resolution:

Leave as is. We don't agree that this clarifies anything much.

Issue closed.
------------------------------------------------------------------------
Issue 48.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> A property is an identifier. Any character may occur in the value. ...
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#declaration>
> 
> For better readability and clear separation of descriptions' subjects,
> make this into two paragraphs as follows:
> 
> "A property is an identifier.
> 
> Any character may occur in a property's value. ..."
> 
> Again, I do not understand why you fall back onto character level
> description here when a universal tokenization is available (see above).

Resolution:

Don't split paragraph but change "character" to "token".

=Tantek= Edit.
------------------------------------------------------------------------
Issue 49.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> ...but in any case, values are built from identifiers, strings, numbers,
> lengths, percentages, URIs, and colors.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#declaration>
> 
> This is incorrect as it is written. Even the preceding paragraph says
> that "any character may occur in the value".
> 
> An example: The value
> 
>   counters(item, ".")
> 
> additionally contains the comma (',', a DELIM) and parentheses.
> Suggestion is to drop the above part of the sentence completely, as it
> does not convey any essential information at that point.

Resolution:

Change "and colors" to "colors, etc.".

=Tantek= Edit.
------------------------------------------------------------------------
Issue 50.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> A user agent must ignore a declaration with an invalid property name..."
> ]]]
>   and later
> [[[
> The CSS2.1 parser will ignore these declarations...
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#declaration>
> 
> It's unclear whether the *parser* must ignore the declarations or the
> *user agent* must ignore it. This becomes important when using SAC:
> Should the property be reported or not? Again, due to the structuring of
> this chapter 4, it is extremely hard to separate the required behaviour
> of a general CSS parser from the required behaviour of a CSS parser that
> has been configured to use the CSS 2.1 profile.

Resolution:

That's SAC's problem. We don't really distinguish between "parser" and
"UA" in this spec, that's up to the SAC spec to define.

Issue closed.
------------------------------------------------------------------------
Issue 51.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> A user agent must ignore a declaration with an invalid property name...
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#declaration>
> 
> What's the definition of "invalid name" here? Invalid per the CSS 2.1
> profile? In this case, it should probably better read "illegal property
> name in CSS 2.1", as "illegal" is a well-defined term in the specification.
> 
> Or is it meant to be invalid per the definition for the "identifier" type
> (e.g. as in { 123: 12pt })?
> 
> Also, how does the term "invalid" here relate to the term "unknown" in
> 4.2, "Unknown properties"?

Resolution:

We don't think we should change anything. We think it's fine as it
is. It seems clear enough what we mean here.

Issue closed.
------------------------------------------------------------------------
Issue 52.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> "Illegal values.", third example:
> [[[
> img { background: "red" } /* keywords cannot be quoted */
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#parsing-errors>
> 
> The correct explanation for why this is an *illegal value* is:
> "/* property does not accept a string value */"

Resolution:

We agree that the proposal is more technically correct, but we believe
it would not be as helpful to people new to CSS as the technically
incorrect text currently in the spec.

Issue closed.
------------------------------------------------------------------------
Issue 53.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> Example: Unexpected end of style sheet
> [[[
> @media screen {
>     p:before { content: 'Hello'; }
>   }
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#parsing-errors>
> 
> Though the example is correct in its result, it is confusing: It looks
> like the user agent (btw.: why not the *parser*?) is supposed to add a
> semicolon and an empty declaration after closing the open string. I
> suggest changing the reference style sheet to
> 
> @media screen {
>     p:before { content: 'Hello'}}
> 
> to better hint at what the parser should virtually append at the end of
> the style sheet.

Resolution:

Remove the semicolon (but don't change the spacing).

Issue closed.
------------------------------------------------------------------------
Issue 54.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> ...in a conformant UA.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#parsing-errors>
> 
> As far as I know, there is no such english word "conformant" (but then,
> I'm German...); use "conforming" instead. Note that you use "conforming"
> already in 4.3.6.

Resolution:

If we say it's a word, it's a word!

(More than 2000 documents on w3.org use this word.)

Issue closed.
------------------------------------------------------------------------
Issue 55.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> Unexpected end of style sheet." and "Unexpected end of string.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#parsing-errors>
> 
> Is there anywhere a rationale given for these two amendments in CSS 2.1?
> At first sight, it looks like it might encourage sloppy style sheet authoring.

Resolution:

We need to define error handling to ensure interoperability.

Issue closed.
------------------------------------------------------------------------
Issue 56.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> Some characters appearing in an unquoted URI, such as parentheses,
> commas, whitespace characters, single quotes (') and double quotes ("),
> must be escaped with a backslash: '\(', '\)', '\,'.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#uri>
> 
> Is this meant to be the comprehensive list of characters that need
> quoting? Then it should be made clear.
> 
> If it is not a comprehensive list, there should be a hint as to where to
> deduct the characters needing quoting from, i.e. the token definition for
> URI. Suggested wording:
> 
> "All characters appearing in an unquoted URI must be quoted so that the
> resulting URI value matches an URI token."

Resolution:

Append "so that the resulting URI value is a URI token" to the end of
the existing sentence.

=Tantek= Edit.
------------------------------------------------------------------------
Issue 57.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> I also do not see the requirement for restricting quoting to using the
> backslash - it will just complicate parser implementations to enforce
> this requirement, which is not even necessary according to the core grammar.

Resolution:

You misunderstood the spec -- because some characters must be quoted
does not mean others must not be.

Issue closed.
------------------------------------------------------------------------
Issue 58.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> In CSS2, the values of counters can only be referred to from the
> 'content' property.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#counter>
> 
> What about CSS *2.1*, the specification at hand? Does it hold the same
> restriction?

Resolution:

Change CSS2 to CSS 2.1 here.

=Tantek= Edit.
------------------------------------------------------------------------
Issue 59.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> To refer to the value of a counter, the notation 'counter(<identifier>)'
> or 'counter(<identifier>, <list-style-type>)' is used.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#counter>
> 
> In contrast to the wording in 4.3.4 or 4.3.6, there is no indication that
> any optional whitespace is allowed in the counter(...)/counters(...) syntax.
> Is it intended that exactly one space character must follow each comma,
> and no further whitespace is allowed within the parentheses? If this is
> not the case, please add appropriate text.

Resolution:

Append "with optional whitespace separating the tokens" at the end of
the two sentences introducing counter syntax in 4.3.5.

=Tantek= Edit. (Ask me if this makes no sense to you. -Hixie)
------------------------------------------------------------------------
Issue 60.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> The list of keyword color names is:...
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#color-units>
> 
> Maybe change to: "The list of color name keywords is: ..." or even just
> "The list of color keywords is: ...". Especially, since the next paragraph
> starts calling them "color keywords", anyway.

Resolution:

Accepted.

=Tantek= Edit.
------------------------------------------------------------------------
Issue 61.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:

> [[[
> Conforming user agents...
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#color-units>
> 
> This text is not a link to the conformance section, whereas the later one
> in 4.4.1 is. Either link both places or link only the first occurrence in
> document order (i.e. this one).

Resolution:

Make both a link.

=Tantek= Edit.
------------------------------------------------------------------------
Issue 62.
URI: http://www.w3.org/mid/Pine.LNX.4.58.0507151120300.8454@localhost.localdomain
Description:

The description of the empty-cells property begins like this:

    In the separated borders model, this property controls the rendering
    of borders and backgrounds around cells that have no visible content.

Why does it say "in the separated borders model"? There is nothing in the
description of the property that implies that it cannot also apply to the
collapsing border model, and in fact it is used in an example with the
collapsing border model earlier in the spec (17.5.1).

-Michael

Resolution:
Keep definiton of 'empty-cells' as is (i.e., doesn't apply to
collapsed borders).

Elika came up with replacement text and images:
   http://www.w3.org/mid/438820C2.6060800@inkedblade.net

=Bert= Edit. [The example is fixed, but the list at the top of 17.5.1
still mentions empty-cells without saying it is only relevant in the
separate border model.]
------------------------------------------------------------------------
Issue 63.
URI: http://www.w3.org/mid/Pine.LNX.4.58.0507151327520.10214@localhost.localdomain
Description:

Another empty-cells related question: the spec has the following
statement:

    if all the cells in a row have a value of 'hide' and have no visible
    content, the entire row behaves as if it had 'display: none'.

Is this a strict statement, in that a row in this situation will not
increment any counters, nor will the table cells within it?

Or is it a loose statement, in that a row in this situation just won't be
drawn, similar to the effect produced with display: none?

-Michael

Resolution:
Change quotes sentence to:
"If all the cells in a row have a value of 'hide' and have no visible
content, then the row has zero height and there is vertical
border-spacing on only one side of the row."

Issue closed.
------------------------------------------------------------------------
Issue 64.
URI: http://www.w3.org/mid/i51ekacjbi2.wl@w3.mag.keio.ac.jp
URI: http://www.w3.org/mid/op.svanzwqtsmjzpq@r600
Response: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0169.html
Resolution:
Made it refer to XHTML1 only.
Issue closed.
------------------------------------------------------------------------
Issue 65.
Folded into issue 92.
Issue closed.
------------------------------------------------------------------------
Issue 66.
URI: http://www.w3.org/mid/i51ekacjbi2.wl@w3.mag.keio.ac.jp
URI: http://www.w3.org/mid/op.svanzwqtsmjzpq@r600
Response: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0169.html
Issue closed.
------------------------------------------------------------------------
Issue 67.
URI: http://www.w3.org/mid/42D266E6.70404@lachy.id.au
Description:

The spec states:

| If a subsequent row has more columns than the first, then additional
| columns must not be rendered. When using 'table-layout: fixed',
| authors should not omit columns from the first row.

That indicates that the total number of columns in the table is
determined from the number of columns spanned by the cells in the
first row. However, what if there are more 'table-column' elements
than the first row? Should a UA still determine the number of columns
from the first row or can that be determined from the number of
table-columns?

For example:
<table>
  <col>
  <col>
  <col>
  <col> <!-- 4 columns -->
  <tr>
    <td>test</td>
    <td>test</td>
    <td>test</td> <!-- 3 cells -->
  </tr>
</table>

with this style:
table { table-layout: fixed; width: 100%; }

I tested Firefox 1.0.4, IE6 and Opera 8 and each of them leave space for the 4th cell.

Can the spec be clarified to either explicity allow or disallow this behaviour?

Resolution:
s/If a subsequent row has more columns than the first,/If a subsequent
row has more columns than the greater of the number determined by the
table-column elements and the number determined by the first row,"

Issue closed.
------------------------------------------------------------------------
Issue 68.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0064.html
Description:

Clarification: Section 9.4.3 states that if a relative positioned
element causes an overflow:auto box to overflow, the UA must allow the
user access to the content, with the effect of adding scrollbars (and
possibly forcing re-layout).  Does this also apply to overflow:scroll?

Recommended change:

Section 9.4.3; replace: "However, if relative positioning causes an
'overflow:auto' box to have overflow, ..." with "However, if relative
positioning causes an 'overflow:auto' or 'overflow:scroll' box to have
overflow, ..."

-Markus

Resolution:
Accepted.

=Tantek= Edit.
------------------------------------------------------------------------
Issue 69.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0064.html
Description:

Clarification: In Section 9.4.3, should the scrolling mechanism that is
used allow the user to scroll to the UNOFFSET position of the relative
element, or the final, offset position?  As written, the text implies
that it is the final, offset position that must be accessible.

Recommended change:

Section 9.4.3; at end of first paragraph add: "The UA must provide
access to the content as if the value of the 'left', 'right', 'top'
and 'bottom' properties of relatively positioned elements were all
zero."

-Markus

I disagree. I think you should be able to move to the final position
to see the actual content. -Ian

Bert disagrees too.

Resolution:
s/must allow the user to access this content/must allow
the user to access this content (at its offset position)/

=Tantek= Edit.
------------------------------------------------------------------------
Issue 70.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0064.html
Description:

Clarification: Can the initial containing block be the block defined
by the HTML element? Section 10.1 says the UA chooses, but can it
choose the HTML box? In other words, can absolutely positioned
elements under the initial containing block be offset by any borders
and margins on the HTML element, or must they be offset from 0,0 of
the viewport?

Recommended change:

Section 9.4.3; Drop issue. No change/clarification required.

-Markus

Resolution:
Reporter retracted issue.
Issue closed.
------------------------------------------------------------------------
Issue 71.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0064.html
Description:

Clarification: The CSS 2.1 spec makes no statement regarding special
treatment for the size of the HTML element.  Should it be:

1. sized as if it were a normal block box (which means it might be
smaller than the available viewport? Opera appears to follow this
approach.

2. increased in size (if smaller than the viewport) to fill the
viewport?

3. increased in size to enclose all absolutely positioned content
whose containing block is the initial containing block? Firefox and
IE6 appear to follow this approach, but there is nothing in the speec
to support this behavior.

Recommended change:

No change required. Just a clarification. The spec is very explicit
that a border of a block box does not extend around an absolute
positioned. Therefore IE and Firefox are misbehaving. Am I right?

-Markus

Yes. For Firefox this is fixed in the latest builds. -Ian

Resolution:

add right before "10.6.1":  Note:  these rules apply to
the root element just as to any other element.

Issue closed.
------------------------------------------------------------------------
Issue 72.
URI: http://www.w3.org/mid/op.svanzwqtsmjzpq@r600
URI: http://www.w3.org/mid/i51zmsnrgqd.wl@w3.mag.keio.ac.jp
Description:

Many references in CSS 2.1 Last Call Working Draft are out of date.

Resolution:

Assumed editorial. (See e-mail, it has a list.)

Issue closed.
------------------------------------------------------------------------
Issue 73.
Description:
(from karlo@opera)

Does 'table-caption' introduce a new block formatting context?

Proposal: Yes. Add them to 9.4.1.

Resolution:
Accepted.

=Tantek= Edit
------------------------------------------------------------------------
Issue 74.
URI: http://www.w3.org/mid/927958.1121607979084.JavaMail.servlet@kundenserver
Description:
In section 15.7 HTML headings should have absolute font-sizes:
http://www.w3.org/TR/2005/WD-CSS21-20050613/fonts.html#font-size-props

but Appendix D. (Default style sheet for HTML 4.0)
recommends to use em units for h1-h6:
http://www.w3.org/TR/2005/WD-CSS21-20050613/sample.html

This is not conistent and should be chanced. [sic]

David: This is very closely related to Issue #41 in issues-2, where we
did resolve to leave Appendix D as it is.  It's not entirely clear what
the resolution regarding the table, was, and this probably needs some
further discussion.

Resolution:
Remove the <hx> row.
=Tantek= Edit.
------------------------------------------------------------------------
Issue 75.
URI: http://www.w3.org/mid/1121876815.7387.12.camel@c-gsoutter.uk.volantis.com
Description:
> In the latest WD, It appears that:
>
> http://www.w3.org/TR/2005/WD-CSS21-20050613/syndata.html#counter
>
> conflicts with:
>
> http://www.w3.org/TR/2005/WD-CSS21-20050613/generate.html#scope
>
> in that the former refers to out of scope counter-reset operating on the
> root element and the latter refers to it operating on the the element in
> question.
>
> As I understand it this behaviour has recently changed so it may have
> been overlooked.

The latter is correct.  When proposing edits for some decisions we made
regarding counters, I didn't even realize that the former section
existed.  Probably the sentence should just be removed (and perhaps much
of the section).

-David

Resolution:

 1. Remove the paragraph:

    # Counters that are not in the scope of any 'counter-reset', are
    # assumed to have been reset to 0 by a 'counter-reset' on the root
    # element. 

 2. Take the sentence at the end of the second paragraph:

    # See "Nested counters and scope" in the chapter on generated
    # content.

    and make it its own paragraph (i.e., the third), and add to the end
    so that it reads:

    # See "Nested counters and scope" in the chapter on generated
    # content for how user agents must determine the value or values of
    # the counter. See the definition of counter values of the
    # <a>'content' property</a> for how it must convert these values to
    # a string.

=howcome= Edit.
------------------------------------------------------------------------
Issue 76.
URI: http://www.w3.org/mid/42DFD435.7070702@mit.edu
Description:

> What exactly is meant by a "later 'counter-reset' on the same element"?

p { counter-reset: mycounter 1 mycounter 2 mycounter; }

That has three counter-resets on the same element for the same
counter; the scope of the reset to 1 does not include nodes that are
in the scope of the reset to 2; the scope of the reset to 2 does not
include nodes that are in the scope of the reset to 0.

That said, I think the wording of this section should be changed to:

  However, it does not include any elements in the scope of a counter
  _with_the_same_name_ created by a 'counter-reset' on a later sibling
  of the element or by a later 'counter-reset' on the same element.

(note addition of "with the same name"; without that I don't believe
the spec is saying what it wants to be saying).

-Boris

Resolution:
Accepted.

Issue closed.
------------------------------------------------------------------------
Issue 77.
URI: http://www.w3.org/mid/1121938871.7387.24.camel@c-gsoutter.uk.volantis.com
Description:

Also, it would be helpful if the example in 12.4.1 was extended to cover
the aspects of counters explained in the new text. It appears that it
has not changed since the old CR.

-Geoff

Resolution:
Leave example, but David to write an extra example.

=David= Propose additional example.
=howcome= Edit.
------------------------------------------------------------------------
Issue 78.
URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-1
Description:
i18n review comment 1: Request for examples of i18n fonts.
Not clear exactly what the request is asking for. -Ian

#1 is probably asking to re-introduce "15.2.6 Generic font families"
of CSS 2.0; I'm not sure why it's not in CSS 2.1.
-Bjoern

Discussion:
http://lists.w3.org/Archives/Member/w3c-css-wg/2005OctDec/0010
http://www.w3.org/mid/BF68580E.618ED%25tantek@cs.stanford.edu

Would I use 'width' and 'height' properties in the @page rule?

Resolution:
Elika, David, Tim and Bert agree to add the old 15.2.6 from CSS2

=Tantek= Add CSS2 15.2.6 back to CSS2.1.
------------------------------------------------------------------------
Issue 79.
URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-2
URI: http://www.w3.org/mid/430DB962.5060700@cisra.canon.com.au
Response: http://www.w3.org/mid/njfrg1da98i14ou9u48vh43tttvq3mhlm6@hive.bjoern.hoehrmann.de
Response: http://www.w3.org/mid/200510101501.15289.bert@w3.org
Description:
i18n review comment 2: Request to use IRIs.
See issues-2 issue 160.

I don't think we can do #2 (adopt IRIs) for the reasons I cited in
<http://lists.w3.org/Archives/Public/public-i18n-core/2005AprJun/0050>,
in particular, we would violate <http://www.w3.org/TR/charmod/#C014>
(C014 requires that processing is equivalent regardless of the encoding
but the IRI specification requires that processing is different if the
style sheet is in a non-Unicode encoding).
-Bjoern

Resolution:

We've already agreed that we're not doing IRIs this time. Bjoern
replied to SVG, we need someone to point i18n to that reply.

Awaiting further reply.
Issue closed.
------------------------------------------------------------------------
Issue 80.
URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-3
Description:
i18n review comment 3: Does ':lang()' match elements that have
language set to the empty tag?
Spec currently says this is explicitly undefined. -Ian

#3 seems http://www.w3.org/TR/2005/WD-CSS21-20050613/selector.html#lang
to be addressed in the WD, :lang is defined in terms of the document
language and we do discuss :lang() with no language. Seems they either
missed that or they want that :lang() is not undefined in CSS 2.1.
-Bjoern

Resolution:
:lang() (no argument) is a syntax error and causes the rule
to be ignored.  Change
  Exception: C may be empty, but it is undefined in CSS 2.1 what it
  matches in that case. (This is likely to be defined in CSS level 3.)
to say that C must not be empty (and perhaps that it should be an
identifier).

Issue closed.
------------------------------------------------------------------------
Issue 81.
URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-4
Description:
i18n review comment 4: Phrasing of RFC3066 reference.
Resolution:
Assumed editorial.
Issue closed.
------------------------------------------------------------------------
Issue 82.
URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-5
Description:
i18n review comment 5: Phrasing of bidi algorithm requirement.
See also http://lists.w3.org/Archives/Member/w3c-i18n-ig/2003Oct/0227

Elika proposes:

http://www.w3.org/TR/CSS21/visuren.html#direction

   # Conforming user agents that do not support bidirectional text may
   # ignore the 'direction' and 'unicode-bidi' properties described in
   # this section.

Append to this paragraph:
   | This exception includes UAs that render right-to-left characters
   | simply because a font on the system contains them but do not
   | support the concept of right-to-left text direction.
which is lifted from the end of the fourth paragraph in this section.

   # The characters in certain scripts are written from right to left
   # In some documents, in particular those written with the Arabic or
   # Hebrew script, and in some mixed-language contexts, text in a single
   # (visually displayed) block may appear with mixed directionality.
   # This phenomenon is called bidirectionality, or "bidi" for short.
   #
   # The Unicode standard ([UNICODE], section 3.11) defines a complex
   # algorithm for determining the proper directionality of text. The
   # algorithm consists of an implicit part based on character properties,
   # as well as explicit controls for embeddings and overrides. CSS 2.1
   # relies on this algorithm to achieve proper bidirectional rendering.
   # The 'direction' and 'unicode-bidi' properties allow authors to
   # specify how the elements and attributes of a document language map
   # to this algorithm.

Strike the entire paragraph below:
   # If the rendered content contains right-to-left characters, and if
   # the user agent displays these characters in right-to-left order,
   # the user agent must apply the bidirectional algorithm. (UAs that
   # render right-to-left characters simply because a font on the system
   # contains them but do not support the concept of right-to-left text
   # direction are exempt from this requirement.)

Replace it with:

   | User agents that support bidirectional text must apply the Unicode
   | bidirectional algorithm to every sequence of inline boxes uninterrupted
   | by a forced line break or block boundary. This sequence forms the
   | "paragraph" unit in the bidirectional algorithm. The paragraph
   | embedding level is set according to the value of the 'direction'
   | property of the containing block rather than by the heuristic given
   | in steps P2 and P3 of the Unicode algorithm.

Markus agrees with proposal
 ( http://lists.w3.org/Archives/Member/w3c-css-wg/2005OctDec/0030 )

Resolution:
=Tantek= Edit.
------------------------------------------------------------------------
Issue 83.
URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-6
Description:
i18n review comment 6: Update Unicode and other i18n references.
See also issues 22 (Unicode) and 72 (General).
Resolution:
Assumed editorial.
Issue closed.
------------------------------------------------------------------------
Issue 84.
URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-7
Response: http://lists.w3.org/Archives/Member/w3c-css-wg/2005OctDec/0022
Description:
i18n review comment 7: @font-face
See also issue 136b in issues-1.

http://lists.w3.org/Archives/Public/www-style/2004Feb/0208 already
addressed #7, I'm not sure how that is not acceptable or why they
did not point this out 1 1/2 years ago. Adding @font-face now would
require going back to Last Call and we would probably have to use
SVG implementations to exit CR if at all possible.
-Bjoern

Awaiting further reply.
Issue closed.
------------------------------------------------------------------------
Issue 85.
URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-8
Response: http://lists.w3.org/Archives/Member/member-i18n-core/2005Oct/0017.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005OctDec/0107
Description:
i18n review comment 8: Request for UTF-16 to be mandatory
(Since XML implementors often try to get out of implementing UTF-16,
and since UTF-16 doesn't add anything UTF-8 doesn't have, it doesn't
seem clear why we would want to do this. -Ian)

#8 seems to suggest we should require UTF-16 support. I don't mind
doing that but UTF-16 is of little use in practise for CSS and the
argument http://lists.w3.org/Archives/Public/www-tag/2005Jun/0017
that this is to align CSS with XML is flawed; as pointed out on
www-tag, many formats and applications either ignore or circumvent
the requirement to support UTF-16.
-Bjoern

Resolution:
No change.

Issue closed.
------------------------------------------------------------------------
Issue 86.
URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-9
Description:
i18n review comment 9: list-style-types
No change requested.
Issue closed.
------------------------------------------------------------------------
Issue 87.
URI: http://www.w3.org/International/2005/05/css2-1-review.html#comt2-10
Description:
i18n review comment 10: Editorial issue to do with encodings of the spec.

#10 is a bug,
http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0168 it
seems the .htaccess did not make it...
-Bjoern

Resolution:
Assumed editorial.
Issue closed.
------------------------------------------------------------------------
Issue 88.
URI: https://bugzilla.mozilla.org/show_bug.cgi?id=295309
Description:

In http://www.w3.org/TR/CSS21/box.html#collapsing-margins

Change

  The bottom margin of an in-flow block-level element with a 'height'
  of 'auto' and 'min-height' less than the element's used height is
  adjoining to its last in-flow block-level child's bottom margin if
  the element has no bottom padding or border.

...to:

  The bottom margin of an in-flow block-level element with a 'height'
  of 'auto' and 'min-height' less than the element's used height and
  'max-height' greater than the element's used height is adjoining to
  its last in-flow block-level child's bottom margin if the element
  has no bottom padding or border.

(This adds 'max-height' to the equation.)

-Ian

Tentative resolution: agreed, except with significant discussion about
whether there should be "or equal".

Elika proposes:
  and a used height within the limits of its 'min-height' and
  'max-height'
David: "within or equal to"?

"x or equal to" would always be true, so can't do that.

Resolution:

Use Ian's original proposal.

Issue closed.
------------------------------------------------------------------------
Issue 89.
URI: http://www.w3.org/mid/200508022034.03732.bert@w3.org
URI: http://www.w3.org/mid/200508092004.26826.bert@w3.org
Description:
Richard Ishida was writing a tutorial on using language in CSS and had
trouble understanding the difference between :lang(x) and [lang|=x].

If he has trouble, than maybe others have, too. He suggested addding a
note to the spec to point out at least that the two selectors are
different. He was confused by the text that :lang worked "in the same
way" as |=.

Here is a possible text to add at the end of 5.11.4:

    *Note* the difference between [lang|=xx] and :lang(xx). In this
    HTML example, a rule for styling the paragraph for French would
    match the paragraph if the selector was 'p:lang(fr)', but
    'p[lang|=fr]' will not match against this paragraph.

        <body lang=fr>
          <p>Je suis fran&ccedil;ais.</p>
        </body>

Here is an alternative wording:

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

        <body lang=fr>
          <p>Je suis fran&ccedil;ais.</p>
        </body>

-Bert

Resolution:
The second version is better.  Add it.
Issue closed.
------------------------------------------------------------------------
Issue 90.
URI: http://www.w3.org/mid/42F8DBE8.3060801@us.ibm.com
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0099.html
Description:
Float rules.
Resolution:
Adding an example to the spec will be very useful.
Issue closed.
------------------------------------------------------------------------
Issue 91.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0060.html
Description:

The following two paragraphs in [1]:

# The background of the root element becomes the background of the
# canvas and covers the entire canvas, anchored at the same point as it
# would be if it was painted only for the root element itself. The root
# element does not paint this background again.

# For HTML documents, however, we recommend that authors specify the
# background for the BODY element rather than the HTML element. For HTML
# documents whose root HTML element has computed values of 'transparent'
# for 'background-color' and 'none' for 'background-image', user agents
# must instead use the computed value of those properties from that HTML
# element's first BODY element child when painting backgrounds for the
# canvas, and must not paint a background for that BODY element. This
# does not apply to XHTML documents. 

make it clear at what position a canvas background is painted when it
comes from the root element ("anchored at the same point as..."), but do
not state the position used when it comes from the BODY element.  They
should do so.  I think it should be the same, but it's worth checking
implementations.

[1] http://www.w3.org/TR/2005/WD-CSS21-20050613/colors.html#q2

-dbaron

The intention was that you'd use the computed values of the background
properties of the BODY element, but paint everything relative to the
HTML element, and do so across the entire canvas. In theory that's
what browsers have implemented, too. -Ian

Resolution:

Add "(for 'background-position')" after the first occurance of
"anchored".

Add "Such backgrounds must also be anchored at the same point as they
would be if they were painted only for the root element." between
"must not paint a background for that BODY element." and "This does
not apply".

=Tantek= Edit.
------------------------------------------------------------------------
Issue 92.
URI: http://www.w3.org/mid/op.svanzwqtsmjzpq@r600
URI: http://www.w3.org/mid/i51ekacjbi2.wl@w3.mag.keio.ac.jp
Description:

> - 4.3.4 URL + URN = URI
>   http://www.w3.org/TR/2005/WD-CSS21-20050613/syndata.html#uri
>
> This (URL + URN = URI) is now considered the "Classical View".  Maybe
> CSS 2.1 should adopt the "Contemporary View".
>
> cf. http://www.w3.org/TR/2001/NOTE-uri-clarification-20010921/#contemporary

-HTMLWG

Resolution:

Change the title to "4.3.4 URLs and URIs".
Remove the first paragraph of the section.
Change "URI values" to "URI values (Uniform Resource Identifiers, see
[RFC3986], which includes URLs, URNs, etc)" in the next paragraph.

=Tantek= Edit.
------------------------------------------------------------------------
Issue 93.
URI: http://www.w3.org/mid/4546CB8F-CE65-4C80-8FC4-EB737B57961E@apple.com
URI: http://www.w3.org/mid/ED86FF2C-94FE-42D2-89F3-31B1051C181B@apple.com
Description:

The CSS2.1 draft states that the baseline of an inline block is the
baseline of the last line box in the inline block. I just made this
change and broke some Dashboard widgets. :)

The problem is that the draft doesn't mention what to do if overflow
is hidden/auto/scroll (and I didn't think of it either). Similarly,
the first row of an inline table could be inside a scrolling table
body. Should overflow != visible cause the inline block to align on
its bottom margin edge always? Only if scrolled? Only if the last line
is clipped?

Another question I had was why use the first row for tables but the
last line for inline blocks? That seems completely inconsistent to me.

-hyatt
(further comments at second URI)
Resolution:

Change:

   A UA should use the baseline of the last line box in the normal flow
   in the element as the baseline of an 'inline-block', or the element's
   bottom margin edge, if there is none.

...to:

   The baseline of an 'inline-block' is the baseline of its last line
   box in the normal flow, unless it has either no in-flow line boxes
   or if its 'overflow' property has a computed value other than
   'visible', in which case the baseline is the bottom margin edge.

Issue closed.
------------------------------------------------------------------------
Issue 94.
URI: http://www.w3.org/mid/20050812151904.CE7B91BEBE@localhost.localdomain
URI: http://www.w3.org/mid/3F6865DB7477EF4A8F79ABCB18DC7E5B02562635@cacexc06.americas.cpqcorp.net
URI: http://www.w3.org/mid/17152.49397.380005.652527@localhost.localdomain
Description:
Some paged media stuff. (abs pos and page breaks)
Third URI has proposals.

Replace third sentence of first bullet point of 13.2:

   The edges of the first page area act as the initial containing
   block for layout that occurs between page breaks.

...with:

   The edges of the first page area establish the rectangle that is
   the initial containing block of the document.

Issue closed.
------------------------------------------------------------------------
Issue 95.
URI: http://www.w3.org/mid/Pine.LNX.4.62.0508201136250.32132@dhalsim.dreamhost.com
URI: http://www.w3.org/mid/200508221756.31163.bert@w3.org
Description:
On Mon, 1 Aug 2005, Michael Day wrote:
>
> On the subject of ex units, how would they work in the following
> situation:
>
> <div style="width: 10ex; font-family: MissingFont, serif">
> <div style="width: inherit; font-family: sans-serif">
> Hello, world!
> </div>
> <span style="font-family: monospace">Goodbye, world!</span>
> </div>
>
> Which font's x-height is used for the width of the two divs?

Lengths are inherited as absolute values, so the inner <div> doesn't
affect the answer to your question, thus it can't be 'sans-serif'. The
outer div's width doesn't change based on its contents, so the <span>
doesn't affect the answer either, so it can't be 'monospace'. This leaves
a MissingFont and 'serif'. Well it obviously can't be MissingFont since,
well, it's missing. Thus it must be 'serif'.

This isn't clear in CSS2.1. I suggest we change the following:

   The 'ex' unit is defined by the font's 'x-height'. The x-height is so
   called because it is often equal to the height of the lowercase "x".
   However, an 'ex' is defined even for fonts that don't contain an "x".

...to read:

   The 'ex' unit is defined by the element's first available font's
   'x-height' metric. The x-height is so called because it is often equal
   to the height of the lowercase "x". However, an 'ex' is defined even
   for fonts that don't contain an "x".

-Ian


> However, does every font really have an x-height? Every *TrueType*
> font does, but not all fonts are TrueType fonts: in particular, the
> "serif" font is hardly ever a single TrueType font, it is usually a
> collection of different fonts bundled together under the same name.

I don't like to tie the spec to any specific font technology, at least
not normatively, but TrueType could be mentioned as an example. For
example, in the following algorithm:

1) Look at the first available font in the list, i.e., the first font
that is available to the UA. If that font defines an x-height (e.g.,
sxHeight in OpenType and xheight in TFM), the UA must use that as the
'ex'.

2) If that font doesn't define an x-height, the UA should measure the
height of an "x", as it would be drawn if the element contained an "x".
(Note that that "x" may come from a later font in the list or from the
UA's fallback font.)

3) If it is not possible to measure the "x", a value of 0.45 em should
be used.

-Bert


> If the "first available font" is defined to be the font used by the
> first character found in the element, what about elements that use ex
> units but do not contain any text?

I think the first available font is the first font in the list that the
UA can read, independent of whether the element uses any glyphs from
it.

-Bert

Bert had an action to come up with some text and came up with these
two alternatives:

   http://lists.w3.org/Archives/Member/w3c-css-wg/2005OctDec/0063
   http://www.w3.org/mid/200511071925.10288.bert@w3.org

The latter is:

   The 'ex' unit is defined by the font's 'x-height'. The x-height is
   so called because it is often equal to the height of the lowercase
   "x".  However, an 'ex' is defined even for fonts that don't contain
   an "x".
  
   UAs must follow the following algorithm to establish the 'ex' for a
   given element:
  
      1. Using the algorithm for font selection (section 15.2), find
         the font that would be used for rendering an "x".
  
      2. Set the 'ex' to the x-height defined by that font; or draw
         the "x" (in an off-screen buffer) and measure its height.
  
      3. If it is impossible to find an x-height or measure an "x"
         glyph, use 0.5em.
  
   UAs should take care that the 'ex' they compute in step 2 is
   reasonable.  In many fonts, the height of an "x" is not equal to
   the x-height (e.g., because the x has a decorative flourish). On
   the other hand, experience shows that many fonts don't define an
   x-height or define it incorrectly.

Ian responded to the first of these with a suggestion to change the
following paragraph now in the spec:

   The 'ex' unit is defined by the font's 'x-height'. The x-height is so
   called because it is often equal to the height of the lowercase "x".
   However, an 'ex' is defined even for fonts that don't contain an "x".

...to read:

   The 'ex' unit is defined by the element's first available font's
   'x-height' metric. The element's first available font is the one that
   is found using <a>the font matching algorithm</a>, but without limiting
   the search to fonts that contain particular characters.

   The x-height is so called because it is often equal to the height of
   the lowercase "x". However, an 'ex' is defined even for fonts that
   don't contain an "x". User agent should use font metrics or direct
   glyph measurement if possible, but may fall back on a default of 0.5em
   if the first available font does not contain suitable information.

Ian responded to the second of Bert's ideas above with:

> This would work too. It differs from the alternative proposal in that
> it uses the 'ex' height of the first font _with an x_, rather than
> the first available font. Is that what we want?

To which Bert replied:

That's what I gathered from the minutes:
http://www.w3.org/2005/10/17-css-irc.html#T22-09-17

I think the argument was that, if you use an ex and there is an x in the
content, you would want the two to match. Plus, UAs already know how to
search the font list for the font with an x.

I think that's reasonable, and it made the algorithm nice and short. But
I'm open for suggestions.

Further e-mails on the subject:
SteveZ: http://www.w3.org/mid/6.2.1.2.2.20060207095711.058cbeb0@namailhost.corp.adobe.com
Paul Nelson: http://www.w3.org/mid/49C257E2C13F584790B2E302E021B6F90ED3DF69@winse-msg-01.segroup.winse.corp.microsoft.com
Howcome: http://www.w3.org/mid/17385.2325.554019.960121@localhost.localdomain
Ian: http://www.w3.org/mid/Pine.LNX.4.62.0602141911330.28514@dhalsim.dreamhost.com


Resolution:

>   The 'ex' unit is defined by the element's first available font. The
>   x-height is so called because it is often equal to the height of the
>   lowercase "x". However, an 'ex' is defined even for fonts that don't
>   contain an "x".
> 
>   The x-height of a font can be found in different ways. Some
>   fonts contain reliable metrics for the x-height. If reliable font
>   metrics are not available, UAs may determine the x-height from the
>   height of a lowercase glyph. One possible heuristics is to look at how
>   far the glyph for the lowercase "o" extends below the baseline, and
>   subtract that value from the top of its bounding box. In the cases
>   where it is impossible or impractical to determine the x-height, a
>   value of 0.5em should be used. 

=howcome= Edit.
------------------------------------------------------------------------
Issue 96.
URI: http://www.w3.org/mid/430B4766.8070004@tu-clausthal.de
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0207.html
Description:
Subject: [CSS21] 3.2 Conformance: User Preferences
Issue closed.
------------------------------------------------------------------------
Issue 97.
URI: http://www.w3.org/mid/430DB80F.80504@cisra.canon.com.au
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0358.html
URI: http://www.w3.org/mid/431235A0.2090202@cisra.canon.com.au
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0379.html
Description:
Subject: [CSS21] Examples
From Craig on behalf of SVG.
Awaiting further clarification.
Issue closed.
------------------------------------------------------------------------
Issue 98.
URI: http://www.w3.org/mid/1171770201.20050825154958@w3.org
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0359.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0401.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0422.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0401.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0422.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0425.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0122.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Oct/0126.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0138.html
Description:
Subject: [CSS21] Examples
From Chris on behalf of SVG and CDF.
Awaiting further reply.
Issue closed.
------------------------------------------------------------------------
Issue 99.
URI: http://www.w3.org/mid/430DB839.60106@cisra.canon.com.au
Description:

Section 3.3 Error conditions says we don't define error handling
behaviour. However, this seems to be untrue.

Resolution:

Replace first paragraph with:

   In general, this document specifies error handling behavior
   throughout the specification. For example, see the <a>rules for
   handling parsing errors</a>.

Drop the second and third paragraphs.

Issue closed.
------------------------------------------------------------------------
Issue 100.
URI: http://www.w3.org/mid/430DB861.30309@cisra.canon.com.au
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0254.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0259.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0269.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0274.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0360.html
Description:
Subject: [CSS21] Section 4.1.1
From Craig on behalf of SVG.
Satisfied: http://www.w3.org/mid/43123735.1050408@cisra.canon.com.au
Issue closed.
------------------------------------------------------------------------
Issue 101.
URI: http://www.w3.org/mid/430DB885.6060505@cisra.canon.com.au
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0257.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0265.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0268.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0273.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0361.html
Description:
Subject: Re:\[CSS21] Section 4.1.1 (b)
From Craig on behalf of SVG.
Satisfied: http://www.w3.org/mid/43123735.1050408@cisra.canon.com.au
Issue closed.
------------------------------------------------------------------------
Issue 102.
URI: http://www.w3.org/mid/430DB8AD.3030405@cisra.canon.com.au
Description:

We claim that 4.1.2.2 Informative Historical Notes is informative, but
the last sentence uses RFC2119 terminology in a seemingly normative
manner:

   Vendor/organization specific extensions should be avoided.

We should fix the inconsistency here somehow.

Resolution:

Move the normative line to the previous section and change it to read
"Authors should avoid vendor-specific extensions".

Fix the table as well (-ms- for Microsoft, mso- for Microsoft Office,
-moz- for Mozilla).

=Tantek= Edit.
------------------------------------------------------------------------
Issue 103.
URI: http://www.w3.org/mid/430DB8F1.9010105@cisra.canon.com.au
Response: http://www.w3.org/mid/35grg19rkm7qej471chpjhl3brdqm2k1hv@hive.bjoern.hoehrmann.de
Description:
Subject: Re: [CSS21] ISO10646
From Craig on behalf of SVG.
Awaiting further reply.
Issue closed.
------------------------------------------------------------------------
Issue 104.
URI: http://www.w3.org/mid/430DB91A.2080905@cisra.canon.com.au
URI: http://www.w3.org/mid/430DB941.9060204@cisra.canon.com.au
Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0142.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Oct/0143.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0147.html
Description:

Section 4.2

This section states that CSS reserves all property values and
@-keywords. So any property introduced by other working groups must be
ignored. This also states that only future CSS specifications can
introduce properties. Please remove statements that indicate the CSS WG
owns all property values and @-keyword as this is not true. For instance
SVG 1.1 introduced for instance, the @color-profile keyword.

The last sentence under the illegal values bullet point indicates that
conforming CSS UA's can accept values defined in future specification.
This does not take into account values that could be added by other
grammars. Please allow other grammers (such as SVG) to add property values.

-SVG

Property Resolution:

Rejected. This statement only applies to text/css resources, which is
the responsibility of the CSS working group; it is not a statment
regarding the general W3C property namespace.

SZ sent http://www.w3.org/mid/6.2.1.2.2.20051201104905.0f7e1db0@namailhost.corp.adobe.com
WG discussed but disagreed with the conclusion.

=Bert= Discuss with SVG WG. See minutes of 2005-12-13 telecon.

=Bert= [In http://www.w3.org/mid/200601231818.10354.bert@w3.org you
wrote that you had done edits; I couldn't find what you had
changed. Nothing should have changed. Did you mean you had mailed the
SVG group?]
------------------------------------------------------------------------
Issue 105.  URI:
http://www.w3.org/mid/430DB9F0.7080409@cisra.canon.com.au Description:

Section 4.3.6

Could you specify that users agents may perform higher quality mapping
of colours from one gamut to another? Specifying that they should be
clipped will produce poor results when the output colour space is not
'close' to sRGB, such as a CMYK printer.

For example User Agents may use a process that provides mapping of the
gamut to the device gamut in other ways, such as perceptual or
photometric gamut mapping. This may involve compressing the full gamut
of colours to fit inside the gamut of the output device, rather than
simply clipping those outside the gamut so as to provide a better
visual output. Please allow conformant UA's to perform higher quality
gamut mapping.

Also please specify late clipping of colours as per CSS 2.0. Thus
preserving colours until the final rendering step. This will also
facilitate better colour quality.

-SVG

<Bert> I think the answer is that remapping is not possible without
knowing what gamut the colors were chosen for in the first place
(although it is probably a good guess that colors in an '@media
screen' style sheet are meant for an RGB monitor).
<Bert> There is a property 'rendering-intent' in CSS3 Color, which may
help with remapping.

Resolution:

Insert "Users agents may perform higher quality mapping of colors from
one gamut to another." just before the sentence that starts with "For
a typical CRT monitor...".
Then change "clipped" at the end of the section to "mapped".

=Tantek= Edit.
------------------------------------------------------------------------
Issue 106.
URI: http://www.w3.org/mid/430DBA41.5080802@cisra.canon.com.au
Thread: http://lists.w3.org/Archives/Public/www-style/2005Aug/thread.html#221
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0292.html
Description:
Subject: [CSS21] CSS3
From Craig on behalf of SVG.
Awaiting further reply.
Issue closed.
------------------------------------------------------------------------
Issue 107.
URI: http://www.w3.org/mid/430DBA76.60509@cisra.canon.com.au
Description:

Section 5.8.3

Why does this section reference SVG 1.0? It should reference SVG 1.1.
Please correct this.

-SVG

Resolution:
Assumed editorial.
Issue closed.
------------------------------------------------------------------------
Issue 108.
URI: http://www.w3.org/mid/430DBA76.60509@cisra.canon.com.au
Description:

Section 5.8.3

The page numbers are also missing, but why are there page numbers at all?

(e.g. SVG 1.0 [SVG10] describes the SVG "class" attribute
[p. ??] and how a UA should interpret it, and similarly MathML 2.0 [MATH20]
describes the MathML "class" attribute [p. ??] .)

-SVG

Resolution:
Rejected; page numbers are added by PS generator.
Issue closed.
------------------------------------------------------------------------
Issue 109.
URI: http://www.w3.org/mid/430DBAA3.1050102@cisra.canon.com.au
Thread: http://lists.w3.org/Archives/Public/www-style/2005Aug/thread.html#223
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0363.html
Description:
Subject: Re: [CSS21] Additional Note
From Craig on behalf of SVG.
Satisfied: mid:4312373E.2080804@cisra.canon.com.au
Issue closed.
------------------------------------------------------------------------
Issue 110.
URI: http://www.w3.org/mid/430DBAD7.8060305@cisra.canon.com.au
Response: http://www.w3.org/mid/lverg1pki5p4nfakttihgedg568etnaqik@hive.bjoern.hoehrmann.de
Description:
Subject: [CSS21] xml:id
From Craig on behalf of SVG.
Awaiting further reply.
Issue closed.
------------------------------------------------------------------------
Issue 111.
URI: http://www.w3.org/mid/430DBB11.2010004@cisra.canon.com.au
Thread: http://lists.w3.org/Archives/Public/www-style/2005Aug/thread.html#225
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0364.html
Description:
Subject: 
From Craig on behalf of SVG.
Resolution:
Examples fixed, note in 1.4.4 changed.
Awaiting further reply.
Issue closed.
------------------------------------------------------------------------
Issue 112.
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0226
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0365.html
Description:
Subject: [CSS21] Section 6.1.2
From Craig on behalf of SVG.
Satisfied: http://www.w3.org/mid/43123735.1050408@cisra.canon.com.au
Issue closed.
------------------------------------------------------------------------
Issue 113.
URI: http://www.w3.org/mid/430DBB4B.9010802@cisra.canon.com.au
Thread: http://lists.w3.org/Archives/Public/www-style/2005Aug/thread.html#227
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0299.html
Description:
Subject: [CSS21] Section 6.1.3
From Craig on behalf of SVG.
Satisfied: http://www.w3.org/mid/43123735.1050408@cisra.canon.com.au
Issue closed.
------------------------------------------------------------------------
Issue 114.
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0228
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0293.html
Description:
Subject: Re: [CSS21] Section 6.4.4
From Craig on behalf of SVG.
Awaiting further reply.
Issue closed.
------------------------------------------------------------------------
Issue 115.
URI: http://www.w3.org/mid/430DBB93.6090808@cisra.canon.com.au
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0366.html
Description:
Subject: [CSS21] Section 15.2
From Craig on behalf of SVG.
Satisfied: http://www.w3.org/mid/43123735.1050408@cisra.canon.com.au
Issue closed.
------------------------------------------------------------------------
Issue 116.
URI: http://www.w3.org/mid/1404915290.20050825153832@w3.org
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0368.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0381.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0386.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0390.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0392.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0397.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0420.html
URI: http://www.w3.org/mid/43156D79.1070402@disruptive-innovations.com
URI: http://www.w3.org/mid/438E77CE.7010107@inkedblade.net
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0427.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0142.html (post-discussion)
URI: http://lists.w3.org/Archives/Public/www-style/2005Oct/0143.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0147.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Oct/0151.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0156.html
Description:
Subject: Re: [CSS21] Unclear status of different versions
Subject: Re: several messages
Subject: Re: How to add properties to the CSS syntax
From Chris on behalf of SVG and CDF.

Resolution:

In Abstract and Section 1.1, remove the sentence starting
"Implementations may refer to CSS2...", and replace it with "Future
specs should refer to CSS2.1 (unless they need features from CSS2
which have been dropped in CSS2.1, and then they should only reference
CSS2 for those features, or preferably reference such feature(s) in
the respective CSS3 Module that includes those feature(s))."

Issue closed.
------------------------------------------------------------------------
Issue 117.
URI: http://www.w3.org/mid/265287321.20050825153955@w3.org
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0369.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0380.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0382.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0383.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0385.html (no request)
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0388.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0413.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0424.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0121.html
URI: http://www.w3.org/mid/304767906.20051017163037@w3.org (no request)
Description:
Subject: Re: [CSS21] Unclear applicability to XML
From Chris on behalf of SVG and CDF.
Reporter stated intent to clarify request. Awaiting further reply.
Issue closed.
------------------------------------------------------------------------
Issue 118.
URI: http://www.w3.org/mid/1789757423.20050825154151@w3.org
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0370.html
Description:
Subject: Re: [CSS21] Multiple IDs
From Chris on behalf of SVG and CDF.
Awaiting further reply.
Issue closed.
------------------------------------------------------------------------
Issue 119.
URI: http://www.w3.org/mid/619362537.20050825154406@w3.org
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0283.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0284.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0305.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0309.html
Description:
Subject: [CSS21] Lack of version control for content
From Chris on behalf of SVG and CDF.
Awaiting further reply.
Issue closed.
------------------------------------------------------------------------
Issue 120.
URI: http://www.w3.org/mid/39742339.20050825154530@w3.org
Description:

Please clearly mark which sections are normative and which informative.
This applies to the entire document.

As an example, in chapter 2:
    * 2.1 A brief CSS 2.1 tutorial for HTML
    * 2.2 A brief CSS 2.1 tutorial for XML
    * 2.3 The CSS 2.1 processing model
          o 2.3.1 The canvas
          o 2.3.2 CSS 2.1 addressing model
    * 2.4 CSS design principles

Perhaps the tutorials of 2.1, 2.2 are informative and the processing
model 2.3 is normative? Its not clear whether 2.4 should be normative or
informative.

Informative: 1.2, 1.3, 1.5, 2.1, 2.2, 2.4, A, C, D, F, I
Normative: Everything else, including G.

Resolution:
Add to 3.1: "All sections of this specification, including appendices,
are normative unless otherwise noted."
In all places that are non-normative (as listed below) state "This
section is non-normative."
Those sections are: 1.2, 1.3, 1.5, 2.1, 2.2, 2.4, A, C, D, F, I
Remove the statement in G that it is normative.
Hyperlink 1.4.4 to 3.1, and 3.1 to 1.4.4. Update the reference to
"CSS1" in 1.4.4 to just say "CSS".

=Bert= Edit. [It's all done except that the backlink from 3.1 to 1.4.4
is broken -- make 1.4.4 have the id "notes-and-examples".]
------------------------------------------------------------------------
Issue 121.
URI: http://www.w3.org/mid/1341455960.20050825154824@w3.org
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0371.html
URI: http://www.w3.org/mid/1341229462.20050829170955@w3.org
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0387.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0389.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0417.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0428.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0124.html
Description:
Subject: [CSS21] Projected deprecation
Resolution:
Assumed s/such as/namely/ by Ian.
See http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0171.html
Issue closed.
------------------------------------------------------------------------
Issue 122.
URI: http://www.w3.org/mid/1382052719.20050825155110@w3.org
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0372.html
Description:
Subject: [CSS21] Notes
From Chris on behalf of SVG and CDF.
Awaiting further reply.
Issue closed.
------------------------------------------------------------------------
Issue 123.
URI: http://www.w3.org/mid/922544614.20050825155235@w3.org
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0373.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0398.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0421.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0426.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0123.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Oct/0125.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0135.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Oct/0137.html
Description:
Subject: Re: [CSS21] Style sheet definition
From Chris on behalf of SVG and CDF.
Reporter said he would take the issue up elsewhere.
Issue closed.
------------------------------------------------------------------------
Issue 124.
URI: http://www.w3.org/mid/406656511.20050825155353@w3.org
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0374.html
Description:
Subject: Re: [CSS21] Single viewport
From Chris on behalf of SVG and CDF.
Awaiting further reply.
Issue closed.
------------------------------------------------------------------------
Issue 125.
Thread: http://lists.w3.org/Archives/Public/www-style/2005Aug/thread.html#266
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0266.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0296.html (replied)
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0339.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0306.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0307.html (replied)
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0310.html (replied)
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0308.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0311.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0321.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0333.html (replied)
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0335.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0336.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0352.html (replied)
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0322.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0324.html (replied)
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0326.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0328.html (replied)
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0329.html
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0376.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Aug/0399.html (no requests)
Description:
Subject: Re: [CSS21] Wider variety of (non-junk) examples requested
From Chris on behalf of SVG.
Awaiting further reply.
Issue closed.
------------------------------------------------------------------------
Issue 126.
Description:

4.1.5 is clear that "CSS 2.1 user agents must ignore any '@import'
rule that occurs inside a block or after any valid rule other than an
@charset or an @import rule.", ever since we agreed to say this as
part of CSS2.1 issues-2 issue 82.

Thus, UA requirements are clear.

However, section 6.3 says "Any @import rules must precede all rule
sets in a style sheet.", which is for the author point of view but is
not as clear.

I propose we change that sentence in 6.3 to read "Any @import rules
must precede all other rules (except the @charset rule, if present)."

-Ian

(Incidentally, there's an error in media queries. It has an @import
inside an @media block. Oops.)

Resolution:
Approved. Make change described above.
Issue closed.
------------------------------------------------------------------------
Issue 127.
URI: http://www.w3.org/mid/43496FF1.6030306@inkedblade.net
Description:

(See also empty-cells in issue 62)

http://www.w3.org/TR/CSS21/tables.html#table-layers

This example seems to be demonstrating two things:
   - what to do if a cell is empty and empty-cells is 'hide'
   - what to do if a cell is completely missing

The first case is well-defined in CSS2.1, but the second
doesn't seem to be defined at all.

I propose that missing cells be treated, for the purpose
of rendering, as empty cells with all properties (notably
including border and background) except 'emtpy-cells' set
at their default values and "empty-cells: hide". This will
make sure handling in collapsed border tables defined, and
will make sure the cells effectively disappear in the
separated borders model. It's also compatible with what I
perceive to be CSS2's take on the problem. (See the last
rule in 17.5.1 in CSS2.)

-Elika

Resolution:

Add the following paragraph right after the list and before the
paragraph following the list in section 17.5:

   A "missing cell" is a cell in the row/column grid that is not
   occupied by an element or pseudo-element. Missing cells are
   rendered as if an anonymous table-cell box occupied their position
   in the grid.

Issue closed.
------------------------------------------------------------------------
Issue 128.
URI: http://www.w3.org/mid/4315C787.6030203@comhem.se
Description:
shrink-to-fit issue.
Resolution:
He is wrong.
=David= Reply.
------------------------------------------------------------------------
Issue 129.
URI: http://www.w3.org/mid/43187BCC.3050109@easyconnect.fr
Description:
error handling of selectors
Resolution:
Add reference from 4.2 to 4.1.7.
=Tantek= Edit.
------------------------------------------------------------------------
Issue 130.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0196.html
Description:
Some things in 4.1.1 still say [a-zA-Z].
Resolution:
Assumed editorial.
=Tantek=
------------------------------------------------------------------------
Issue 131.
URI: http://www.w3.org/mid/e474a6b0ffb3c208411115775fe0b074@asahi-net.or.jp
Description:
Request to change a graphic.
Resolution:
Assumed editorial by Ian.
Issue closed.
------------------------------------------------------------------------
Issue 132.
URI: http://www.w3.org/mid/9882C98B3C3D9B45A9A5F9EDECE014D812686BF9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com
Description:
Clarify rule about pseudo-elements not being anywhere but the end of a rule.
Resolution:
Retracted by reporter.
Issue closed.
------------------------------------------------------------------------
Issue 133.
URI: http://www.w3.org/mid/20050919225223.GA9168@ridley.dbaron.org
Description:
List numbering in 2.1.
Resolution:
Remain silent. Address in test suite.
=Hixie= Test suite: Put
   http://dbaron.org/css/test/2005/list-numbering-across-types
in the test suite along with many other tests on this.
Issue closed.
------------------------------------------------------------------------
Issue 134.
URI: http://www.w3.org/mid/n2m-g.5tqkj11nfnmho9ijthjsj51um88q0r9kvm@news.spartanicus.utvinternet.ie
URI: http://www.w3.org/mid/n2m-g.shskj1hnqnk0u1q1096r4aurdeaekhfl0i@news.spartanicus.utvinternet.ie
Description:
http://www.w3.org/TR/CSS21/changes.html#q4 currently doesn't mention
the new value "none" for the "content" property, and other comments.
Resolution:
Assumed editorial.
Issue closed.
------------------------------------------------------------------------
Issue 135.
URI: http://www.w3.org/mid/20050929151808.12625@mail.visualclick.de
URI: http://www.w3.org/mid/20050929160255.25775@mail.visualclick.de
URI: http://www.w3.org/mid/20051003125102.16412@mail.visualclick.de
URI: http://www.w3.org/mid/20050929173351.13550@mail.visualclick.de (proposal)
Description:
I seem to have lost the place where it is defined how to establish the
size of the page box (<http://www.w3.org/TR/CSS21/page.html>). I think
this used to be done with the 'size' property in CSS2, but this is no
longer in CSS21.
Resolution:
Issue closed.
------------------------------------------------------------------------
Issue 136.
Description:
Many of the normative refs should be informative.
PNG, HTML4, CSS1, CSS2, XML10 etc might not want to be normative. But
we should check.
[CHARSETS] maybe should be normative?
Resolution:
=David= Check all the references for whether they should be norm/non-norm.
------------------------------------------------------------------------
Issue 137.
Description:
Resolution:
Change or remove the copyright in chapter 1. (1.6)
Issue closed.
------------------------------------------------------------------------
Issue 138.
Description:
PDF is broken (appendices out of order).
Resolution:
Issue closed.
------------------------------------------------------------------------
Issue 139.
Description:
[PNG]'s URI is old.
[URI]'s reference's description is missing. (RFC problem)
Resolution:
Issue closed.
------------------------------------------------------------------------
Issue 140.
URI: http://www.w3.org/mid/7AEA6A97-B533-4707-87A3-A4BE386A4CFF@apple.com
URI: http://www.w3.org/mid/37891D60-D98A-47AF-AD51-2323D2AC6454@apple.com
URI: http://www.w3.org/mid/F9AA656B-D48C-4043-A65F-BB7461BC74A9@apple.com
URI: http://www.w3.org/mid/EFD9E7D3-D95D-4377-9519-D3BAFC63567A@apple.com
Description:
pre-wrap issue. Last e-mail has proposals.

Various proposals have been made that differ from the above proposals,
but they have received push-back.

Resolution:

6. If spaces (U+0020) or tabs (U+0009) at the end of a line have
'white-space' set to 'pre-wrap', UAs may visually collapse them.

=Tantek= Edit.
------------------------------------------------------------------------
Issue 141.
URI: http://www.w3.org/mid/4383ABE2.5010905@mit.edu
Description:
I think 6.4.1 needs to be clearer about the sort at each step being
only within groups of rules that sorted equivalent to each other at
the previous step...  That's not obvious from just looking at the
text, as things stand. -Boris

howcome says:

I propose to change this text in 6.4.1 from:

   To find the value for an element/property combination, user agents
   must apply the following sorting order:

to:

   To find the value for an element/property combination, user agents
   must use the following pseudo-algorithm:

and add this paragraph after the numbered list:

   The sorting process continues until one winning declaration is found.


dbaron disagreed and proposed:

Change the start of (2) from "Sort" to "Choose the last declaration in
the sort".

Change the start of (3) from "Sort" to "If the previous sort resulted in
a tie, break the tie by choosing the highest declaration in the sort".

Change the start of (4) from "Finally, sort by order specified: if two
rules have the same weight, origin and specificity," to "Finally, if the
previous sort still resulted in a tie,".

David also proposed:

Choose the declarations at the highest numerical value in the
following list based on importance (normal or important) and origin
(author, user, or user agent):

   1. user agent style sheets
   2. user normal style sheets
   3. author normal style sheets
   4. author important style sheets
   5. user important style sheets

If this results in more than one declaration, choose the
declarations tied for the highest specificity of selector.
Pseudo-elements and pseudo-classes are counted as normal elements and
classes, respectively.

If this results in more than one declaration, break the tie with
order:  the latter specified wins. Rules in imported style sheets are
considered to be before any rules in the style sheet itself.


Resolution:

Replace 2 with "2. Sort according to importance (normal or important)
and origin (author, user, or user agent). In ascending order of
precendence:"

Insert "rules with the same importance and origin" after "3. Sort"

=howcome= Edit.
------------------------------------------------------------------------
Issue 142.
URI: http://www.w3.org/mid/20051123002259.GA27719@ridley.dbaron.org

> "User agent: Conforming user agents must apply a default style sheet
> (or behave as if they did) prior to all other style sheets for a
> document....."

We should just remove the words "prior to all other style sheets for a
document", since they're redundant and potentially confusing if
interpreted too literally. -dbaron

Resolution:
Accept dbaron't proposal.
=Bert= Edit.
------------------------------------------------------------------------
Issue 143.
Description:
Margin and padding properties should apply to table-caption (they
currently say they don't despite the table section defining how
margins work for table-caption boxes).
Resolution:
Change Applies To: line.
=Bert= Edit.
------------------------------------------------------------------------
Issue 144.
URI: http://www.w3.org/mid/439D00F7.5060500@inkedblade.net
URI: http://www.w3.org/mid/440CFCDC.6030301@inkedblade.net
Description:
Table backgrounds.
Resolution:
  Replace text as given in Elika's email
=Elika= Propose a simple example for that section.
=Bert= Edit once Elika has sent new text and examples.
------------------------------------------------------------------------
Issue 145.
URI: http://www.w3.org/mid/43E85E2B.5030203@lachy.id.au
Description:
Resolution:
Not changing this for CSS2.1.
Issue closed.
------------------------------------------------------------------------
Issue 146.
URI: http://www.w3.org/mid/200602031701.30469.bert@w3.org
Description:
Resolution:
Answered on list.
Issue closed.
------------------------------------------------------------------------
Issue 147.
URI: http://www.w3.org/mid/5a5jr1pi8b2hh2tdl0812einu2i01b5472@hive.bjoern.hoehrmann.de
Description:

  http://www.w3.org/TR/2005/WD-CSS21-20050613/grammar.html G.2 has

  "!"{w}"important" {return IMPORTANT_SYM;}
  ...
  "url("{w}{string}{w}")" {return URI;}

So you can't have url(/**/foo/**/) or !/**/important (or you can have
both, my flex is a bit rusty); this contradicts 4.1.1 which prohibes the
former and allows the latter. Anne says iCab, IE win/mac, and Gecko do
apply "!/**/important", Opera and KHTML do not.

Resolution:
=Bert= Fix the tokeniser. (dbaron suggested making {w} contain comments)
------------------------------------------------------------------------
Issue 148.
URI: http://www.w3.org/mid/v8j8s1d49i1vrr8vjktrrnnu3sgr1kpdhc@hive.bjoern.hoehrmann.de
Description:

  CSS 2.1 has http://www.w3.org/TR/CSS21/syndata.html#escaped-characters

  Third, backslash escapes allow authors to refer to characters they
  can't easily put in a document. In this case, the backslash is
  followed by at most six hexadecimal digits (0..9A..F), which stand for
  the ISO 10646 ([ISO10646]) character with that number, which must not
  be zero. (It is undefined in CSS 2.1 what happens if a style sheet
  does contain a zero.)

I think at least the second instance of "zero" is misleading, this
should probably be ... which must not be U+0000 ... does contain a
U+0000 ... though there might be better wording for it. It also notes

  Backslash escapes are always considered to be part of an identifier
  or a string (i.e., "\7B" is not punctuation, even though "{" is, and
  "\32" is allowed at the start of a class name, even though "2" is
  not).

That doesn't seem right as if the escape is not part of STRING or IDENT
tokens as defined in the tokenization, it cannot be considered part of
any. This basically says that unescaping happens conceptually after
parsing and that escapes may occur in places where the literal character
would not be allowed. I am not sure how to rephrase it (nor does it seem
to be needed) though.

Resolution:
=Bert= Edit the first of the above to be clearer that by "zero" we
mean the unicode character zero; prepend the word "Note:" at the
beginning of the second paragraph he's complaining about, and maybe
add ", where allowed, " between "escapes" and "are".
------------------------------------------------------------------------
Issue 149.
URI: http://www.w3.org/mid/iak8s156vp3i5r4uc3n0a03g55ijm0mi5n@hive.bjoern.hoehrmann.de
Description:

  Do we have a list of inputs that cannot be tokenized or parsed per CSS
2.1? There should be some specific issues in the list archives, maybe we
should keep track of them? In any case,

.test {
color:green;color\
:red;
}

should probably be added if it's not there already. It seems this is
tokenized as ... IDENT ('color') DELIM ('\') S ('\n') DELIM (:) IDENT
('red') ';' which does not match 'declaration'. It's green in Opera9
and red in Mozilla/IE6.

Resolution:
No change.
Issue closed.
------------------------------------------------------------------------
Issue 150.
URI: http://www.w3.org/mid/43C68B95.4070405@mit.edu
Description:

I'm trying to understand the following paragraph in section 11.1.1 [1]:

  In the case of a scrollbar being placed on an edge of the element's box, it
  should be inserted between the inner border edge and the outer padding edge.
  Any space taken up by the scrollbars should be subtracted from the computed
  width/height, thus preserving the inner border edge.

What does that mean in practice?  Specifically, consider the following markup:

  <div id="outer">
    <div id="inner">Text</div>
  </div>

And the styles

  #outer { overflow: auto; height: 200px; width: 200px;}
  #inner { height: 100%; width: 200%; }

Now the "outer" div overflows horizontally, so a horizontal scrollbar
has to be inserted.  Given that, what is the computed value of
"height" for the outer div?  Is it 100px?  Or is it (100px - 'height
of scrollbar')?  And more specifically, what is the computed value of
"height" for the inner div?

Resolution:

The computed value of the outer 'height' is 200px.
The computed value of the inner 'height' is 100%.

Proposal:

10.3.3: Change 

   'margin-left' + 'border-left-width' + 'padding-left' + 'width' +
   'padding-right' + 'border-right-width' + 'margin-right' = width of
   containing block

   If 'width' is not 'auto' and 'border-left-width' + 'padding-left' +
   'width' + 'padding-right' + 'border-right-width'

...to:

   'margin-left' + 'border-left-width' + 'padding-left' + 'width' +
   'padding-right' + 'border-right-width' + 'margin-right' + scrollbar
   width (if any) = width of containing block

   If 'width' is not 'auto' and 'border-left-width' + 'padding-left' +
   'width' + 'padding-right' + 'border-right-width' + scrollbar width
   (if any)

Add to the end of that section:

   The "scrollbar width" value is only relevant if the user agent uses
   a scrollbar as its scrolling mechanism. See the definition of the
   'overflow' property.

10.3.7: Change:

   'left' + 'margin-left' + 'border-left-width' + 'padding-left' +
   'width' + 'padding-right' + 'border-right-width' + 'margin-right' +
   'right' = width of containing block

...to:

   'left' + 'margin-left' + 'border-left-width' + 'padding-left' +
   'width' + 'padding-right' + 'border-right-width' + 'margin-right' +
   'right' + scrollbar width (if any) = width of containing block

Add to the end of that section:

   The "scrollbar width" value is only relevant if the user agent uses
   a scrollbar as its scrolling mechanism. See the definition of the
   'overflow' property.

10.6.4: (tbd...)

10.6.6: (tbd...)

Change 11.1.1:

   In the case of a scrollbar being placed on an edge of the element's
   box, it should be inserted between the inner border edge and the
   outer padding edge. Any space taken up by the scrollbars should be
   subtracted from the computed width/height, thus preserving the
   inner border edge.

...to:

   (tbd...)

=Hixie= Work out the answer.
http://annevankesteren.nl/test/css/temp/002.htm
------------------------------------------------------------------------
Issue 151.
Description:

I was just rereading the CSS 2.1 spec and believe I stumbled across a
typo in the Flex tokenizer.

string1   \"([^\n\r\f\\"]|\\{nl}|{escape})*\"
string2   \'([^\n\r\f\\']|\\{nl}|{escape})*\'
invalid1   \"([^\n\r\f\\"]|\\{nl}|{escape})*
invalid2   \'([^\n\r\f\\']|\\{nl}|{escape})*

In the first part of these rules, shouldn't there be one more or one
less backslash before the single and double quotes? For example:

(a) if a lone backslash is to be forbidden:  [^\n\r\f\\\"]
(b) if a lone backslash is to be allowed:    [^\n\r\f\"]

I would think that option (a) is what's intended. I didn't see
anything about this in the changes/errata. Could you please confirm?

Nice work on the spec, btw.

Thanks,
Jared

Resolution:
=Bert= Resolve it.
------------------------------------------------------------------------
Issue 152.
URI: http://www.w3.org/mid/43D27CCC.9040709@mit.edu
URI: http://www.w3.org/mid/21324932.1137881854316.JavaMail.ngmail@webmail-02.arcor-online.net
Description:

Based on previous discussion [1], I think it's clear the ::first-line
pseudo-element is badly underspecified and further that there is no
clear idea how to specify it.  Given the state it's in, I don't think
it's possible to implement it interoperably.

Given that, I request that ::first-line be removed from the CSS2.1
specification until such a time as it's better specified.

[1] http://lists.w3.org/Archives/Public/www-style/2005Oct/0163.html

(see equivalent selectors issue too)

Further discussion including a testcase:
   http://lists.w3.org/Archives/Public/www-style/2006Jan/0209.html

Tantek's proposal:

Put the ::first-line pseudo inside the inline elements.
Paint the background separately, as for an anonymous box around the
contents of the first line.

Problems that remain with Tantek's proposal:

Which background do you use, if ::first-line says "background: inherit"?
What do you report for getComputedStyle(element, "::first-line") ?

Resolution:

Keep as is.
------------------------------------------------------------------------
Issue 153.
URI: http://www.w3.org/mid/20060201223415.GC24163@ridley.dbaron.org

Anne van Kesteren raised as a last-call comment on WICD [1] regarding
the sizing of scalable SVG background images (i.e., those that do not
provide a size, and may or may not provide an intrinsic ratio).  The CDF
working group discussed this and concluded [2] that it would be best if
this were specified by CSS.

Resolution:

In section 14.2 add:

   Intrinsic dimensions expressed as percentages must be resolved
   relative to the dimensions of the rectangle that establishes the
   coordinate system for the background-position property.

   If the image has no intrinsic dimensions and has an intrinsic ratio
   the dimensions must be assumed to be the largest dimensions at that
   ratio such that neither dimension exceeds the dimensions of the
   rectangle that establishes the coordinate system for the
   background-position property.

   If the image has no intrinsic ratio either, then the dimensions
   must be assumed to be the rectangle that establishes the coordinate
   system for the background-position property.

=Bert= Edit.
------------------------------------------------------------------------
Issue 154.
URI:
http://www.w3.org/mid/9882C98B3C3D9B45A9A5F9EDECE014D8155D13A1@win-msg-01.wingroup.windeploy.ntdev.microsoft.com
Description:
Resolution:
Remove mso, add -ms, simplify table accordingly.
=Bert= Edit.
------------------------------------------------------------------------
Issue 155.
URI:
http://www.w3.org/mid/9882C98B3C3D9B45A9A5F9EDECE014D8155D14D3@win-msg-01.wingroup.windeploy.ntdev.microsoft.com
Description:
Resolution:
=Markus= You raised the issue, you tell us how to resolve the issue.
------------------------------------------------------------------------
Issue 156.
URI: http://www.w3.org/mid/43F1094B.8000702@inkedblade.net
URI: http://www.w3.org/mid/43F116DF.90409@inkedblade.net
Description:
text-decoration stuff
Resolution:
=WG= Discuss.
------------------------------------------------------------------------
Issue 157.
Description:
Resolution:
Mention in the Changes section that for changes not listed by Changes
section, it's recommended that implementors read the disposition of
comments.
=Bert= Edit.
------------------------------------------------------------------------
Issue 158.
Description:
'no-wrap' should be 'nowrap' in 16.6.1:1.
Resolution: Editorial.
=Bert= Edit.
------------------------------------------------------------------------
Issue 159.
Description:
fantasai wants 6.4.1:2 to be s/style sheets/declarations/
dbaron wants 6.4.1:4 to be s/rules/declarations/
Resolution:
=howcome= Edit.
------------------------------------------------------------------------
Issue 160.
URI: http://www.w3.org/mid/9882C98B3C3D9B45A9A5F9EDECE014D815B23950@win-msg-01.wingroup.windeploy.ntdev.microsoft.com
Description:
selector wording
Resolution:
 Change to "...may only be appended after the last simple selector of the selector"
=Bert= Edit
------------------------------------------------------------------------
Issue 161.
URI:  http://www.w3.org/mid/9882C98B3C3D9B45A9A5F9EDECE014D8161032A5@win-msg-01.wingroup.windeploy.ntdev.microsoft.com
Description:
vertical-align and font-size
Resolution:
  Issue dropped.
------------------------------------------------------------------------
Issue 162.
Description:
  From: Bob Jervis <bjervis@exchange.microsoft.com>
  To: "howcome@opera.com" <howcome@opera.com>, "ian@hixie.ch" <ian@hixie.ch>
  Cc: Markus Mielke <mmielke@windows.microsoft.com>

  The CSS text is sketchy on the issue of line breaks.  Is a float a
  line break opportunity?

  This came up accidentally in composing a test page where I had
  something like:

                          Blah blah blah<span style="float: left">foo foo foo</span>, more blah blah blah

  So there is no space between the 'blah' before the span and the ','
  afterward.

  Should a browser (formatting English just to avoid any
  language-specific issues) ever allow a line break between the word and
  the comma?  Visually, if you have some construct like:

                          Xxx<span style="font: sans-serif">yyy</span>zzz

  The xxx, yyy and zzz sub-sequences may appear very different, but I
  could not find a browser that would line break that sequence.  Yet, I
  did find that FireFox 1.5 (I think) does line break at a float.

  What is the correct behavior?  There is language in the spec that says
  floats should have no effect on vertical layout (relating to block
  elements in the same flow), but I find no equivalent statement about
  inline elements and text in the same flow.

Resolution:
  CSS2.1 does not define line breaking opportunity. We all agree that there
  should be no line break opportunity with floats. Proposed text addition:
    "A float should not introduce a line break opportunity."
=Markus= find right place in the spec

------------------------------------------------------------------------
Issue 163.
URI: http://www.w3.org/mid/440C62EC.3080403@mit.edu
URI: http://www.w3.org/mid/440D5F48.4080307@peda.net
URI: http://www.w3.org/mid/7.0.1.0.2.20060307100207.023631a8@nc.rr.com
Description:
wording in 10.3.2/10.6.2.
bz's suggestions was:

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

...and analogously for width.

Resolution:
  We accept the proposal in http://lists.w3.org/Archives/Public/www-style/2006Mar/0014
=Bert= Edit
------------------------------------------------------------------------
Issue 164.
URI: http://www.w3.org/mid/440CFCDC.6030301@inkedblade.net
Description:
table backgrounds continued
Resolution:
SEE 144
------------------------------------------------------------------------
Issue 165.
URI: http://www.w3.org/mid/E1FGhW7-00047U-G6@localhost.localdomain
URI: http://www.w3.org/mid/440D7856.2060506@inkedblade.net
Description:
  content: uri(404)
Proposal:
  Change
    If a user agent cannot display the resource it must ignore it.
  to
    If the user agent cannot display the resource it must leave it out
    as if it were not specified.
Counter-proposal:
  Change
    If a user agent cannot display the resource it must ignore it.
  to
    If the user agent cannot display a resource, it should display
    some indication that the resource cannot be displayed.
Counter-counter-proposal:
  Change
      If a user agent cannot display the resource it must ignore it.
  to nothing.
Counter-counter-counter-proposal:
  Change
    If a user agent cannot display the resource it must ignore it.
  to
    If the user agent cannot display the resource it must either leave
    it out as if it were not specified or display some indication that
    the resource cannot be displayed.

Resolution:
  counter-counter-counter-proposal accepted.

=Howcome= Edit.
------------------------------------------------------------------------
Issue 166.
URI: http://www.w3.org/mid/4415FA58.50609@inkedblade.net
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2006JanMar/0240.html
Description:
 - font fallback seems restricted to only one font
 - Paul notes that UA should be free to pick using any algorithm
 - UA should be able to do something more intelligent than using the
   missing glyph glyph; e.g. print box with Unicode hex code
 - Elika notes that UA should try at least one UA-chosen font before
   falling back to default glyphs because even though all fonts on system
   have required glyph, author may have specified a list of fonts that
   aren't on the system,

Resolved:

In section 5.2 replace point 5 with:
   5. If there is no font within the family selected in 2, then use a
   UA-dependent default 'font-family' and repeat step 2, using the best
   match that can be obtained within the default font. If a particular
   character cannot be displayed using this font, the the UA may use other
   means to determine a suitable font for that character. The UA should map
   each character for which it has no suitable font to a visible symbol
   chosen by the UA, preferably a "missing character" glyph from one of the
   font faces available to the UA.

Resolution:
=Tantek= Edit.
------------------------------------------------------------------------