[css3-selectors] New last call WD for Selectors

The CSS WG published a new WD for Selectors yesterday:

    http://www.w3.org/TR/2009/WD-css3-selectors-20090310

The specification was published as Candidate Recommendation in 2001,
then republished as a Working Draft in 2005 in order to remove a
feature that hadn't been implemented (the content selector).

The other features that were partially implemented then now seem to be
fully implemented, except that one of them showed problems, viz.,
the '::selection' pseudo-element. We decided to drop that feature for
now.

The recent Unicode normalization issue (which gave rise to some very
long threads[1] on this list) is *not* dealt with in this draft. The
issue seems wider than just Selectors and there is no consensus yet. So
rather than say something we may regret later, the spec says nothing.
We're aware that leaves a hole in the spec, but the spec is valuable
enough already.

This new publication comes with a last call for comments, because we
believe the specification is ready for a status change. It can
hopefully go directly to Proposed Recommendation, but if we find that
implementations (after eight years!) are not ready, it may have to be
Candidate Recommendation for a while again.

Of course, we first have to see what comments we get... The deadline for
those is April 7 and the preferred place to send them is this mailing
list, <www-style@...>. Please, put [css3-selectors] in the subject
(with the brackets).

Requests for new features are unlikely to receive a positive response.
(Once the spec is a Recommendation, we will think again about updating
it). But we like to hear about any other problems.

[1] http://lists.w3.org/Archives/Public/www-style/2009Feb/0231.html
    and other threads



Bert
--
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@...                             2004 Rt des Lucioles / BP 93
  [phone]            06902 Sophia Antipolis Cedex, France

[Anton Prowse]

Congratulations on a very solid-looking specification!

Here are the things that I noticed when reading through the document.
(Trivial editorial issues are listed separately at the end.)


6.3. Attribute selectors
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#attribute-selectors)
:

   # [att~=val] Represents an element with the att attribute whose
   # value is a whitespace-separated list of words, one of which is
   # exactly "val". If "val" contains whitespace, it will never represent
   # anything (since the words are separated by spaces). Also if "val" is
   # the empty string, it will never represent anything.

Issue 1:  Intuitively one might expect that if "val" were the empty
string it would represent an element with the att attribute whose value
is the empty string, rather than fail to represent anything.  (HTML5
currently proposes that <img>, <img alt=""> and <img alt="bar"> have
different semantics, for example, and so there is a use case for such
matching.)  If such matching is truly not permitted, perhaps it is worth
explicitly stating that.  (The equivalent situation with the
substring-matching attribute selectors seems reasonable as specified,
however.)




6.3.1. Attribute presence and value selectors
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#attribute-representation)
:

   # Attribute values must be identifiers or strings.

Issue 2a:  The term "identifier" is undefined.  (Same issue exists in
6.3.2.)


Issue 2b:  The term "string" string is undefined, but is presumed to be
an identifier delimited by " marks.  What about ' and other marks?
(Same issue exists in 6.3.2.)




6.6.4. The UI element states pseudo-classes
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#UIstates) :

   # Most elements will be neither :enabled nor :disabled.

Issue 3:  This sentence is meaningless for general document languages.




6.6.5. Structural pseudo-classes
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#structural-pseudos) :

   # Standalone pieces of PCDATA (text nodes in the DOM) and other
   # non-element nodes are not counted when calculating the position of
   # an element in the list of children of its parent.

Issue 4:  Neither "PCDATA" nor "DOM" are defined in this document.
"PCDATA" is not used anywhere else in the document, and "DOM" is only
used once more in normative text, in the subsection ':empty
pseudo-class' of this section.




6.6.5 :nth-child() pseudo-class
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#nth-child-pseudo) :

   # The :nth-child(an+b) pseudo-class notation represents an element
   # that has an+b-1 siblings before it in the document tree, for a given
   # positive integer or zero value of n, and has a parent element.

Issue 5a:  s/for a given/for some/.  Ditto for the description of the
other related pseudo-elements.


   # In other words, this matches the bth child of an element after all
   # the children have been split into groups of a elements each.

Issue 5b:  It matches the bth child *of each group* after the children
have been partitioned into groups (the last group having possibly fewer
than 'a' elements).  Also, the sentence makes no sense when either a or
b is zero or negative.  The sentence is not necessary, will be too long
when corrected to accurately explain modular arithmetic, and should be
omitted altogether.  Ditto for the description of the :nth-of-type()
pseudo-class.


   #   Examples:
   #     [...]
   #     p:nth-child(4n+1) { color: navy; }
   #     p:nth-child(4n+2) { color: green; }
   #     p:nth-child(4n+3) { color: maroon; }
   #     p:nth-child(4n+4) { color: purple; }

Issue 5c:  It is much more natural to use :nth-child(4n) than
:nth-child(4n+4) (although you would then want it to be first in the
list rather than last).  It was probably avoided because the case b=0
has not yet been discussed so far in the document --- but there is a
precedent higher up in the example: :nth-child( +6 ).


   # When a=0, the an part need not be included (unless the b part is
   # already omitted). When an is not included, the + sign before b (when
   # allowed) may also be omitted.

Issue 5d:  s/When an is not included, the + sign before b (when allowed)
may also be omitted/When an is not included and b is non-negative, a +
sign before b may also be omitted/


Issue 5e:  There is no discussion in this subsection of the omission of
the + sign before a, which is curious given that all other possible
omissions are discussed.


   # In this case the syntax simplifies to :nth-child(b) and the last
   # example simplifies to :nth-child(5).

Issue 5f:  The only unsimplified cases which simplifies to :nth-child(5)
when a is zero and b is non-negative are :nth-child(0n+5) and
:nth-child(-0n+5), neither of which are the last (or indeed any) example.




6.6.5 :empty pseudo-class
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#empty-pseudo) :

   # The :empty pseudo-class represents an element that has no children
   # at all. In terms of the DOM, only element nodes and text nodes
   # (including CDATA nodes and entity references) whose data has a
   # non-zero length must be considered as affecting emptiness; comments,
   # PIs, and other nodes must not affect whether an element is
   # considered empty or not.

Issue 6:  Neither "DOM", "CDATA" nor "PI" are defined in this document.
Neither "CDATA" nor "PI" is used anywhere else in the document, and
"DOM" is only used once more in normative text, in the introduction to
this section.




7.1. The ::first-line pseudo-element
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#first-line) :

   # In CSS, the ::first-line pseudo-element can only be attached to a
   # block-level element, an inline-block, a table-caption, or a
   # table-cell.

Issue 7a:  This does not really add anything to the
discussion, and runs the risk of becoming incorrect as other parts of
the CSS specification change.  It could be removed.  A more general
statement should be inserted in the introduction to Section 7, stating
that the applicability of pseudo-elements may be dependent on the nature
of the subjects of the selector.  (This statement should be inserted
even if the paragraph is not removed.)


   # A UA should act as if the fictional start tags of the ::first-line
   # pseudo-elements were nested just inside the innermost enclosing
   # block-level element. (Since CSS1 and CSS2 were silent on this case,
   # authors should not rely on this behavior.) Here is an example. The
   # fictional tag sequence for [...]

Issue 7b:  Should the parenthetical sentence be a note?  It seems out of
place in normative text.




7.2. The ::first-letter pseudo-element
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#first-letter) :

   # The ::first-letter pseudo-element represents the first letter of
   # the first line of a block, if it is not preceded by any other
   # content (such as images or inline tables) on its line. The
   # ::first-letter pseudo-element may be used for "initial caps" and
   # "drop caps", which are common typographical effects. This type of
   # initial letter is similar to an inline-level element if its 'float'
   # property is 'none'; otherwise, it is similar to a floated element.

Issue 8a:  In the first sentence, what is a "block"?


   # The ::first-letter pseudo-element can be used with all such
   # elements that contain text, or that have a descendant in the same
   # flow that contains text.

Issue 8b:  s/such/applicable/




8.2. Child combinators
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#child-combinators) :

   # A child combinator describes a childhood relationship between two
   # elements. A child combinator is made of the "greater-than sign" (>)
   # character and separates two sequences of simple selectors.

Issue 9:  s/"greater-than sign" (>)/"greater-than sign" (U+003E, >)/








Trivial editorial matters
-------------------------

General comments :

Issue 10:  Notes are currently not displayed consistently, cf "Note:",
"Note.", subsequent capital letter or lowercase letter.  All notes
should begin with "Note:" or similar; currently this is not the case in
6.6.1, 6.6.5, 7, 7.1 and 7.2.




1. Introduction
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#context) :

   # Selectors Level 1 and Selectors Level 2 are defined as the subsets
   # of functionality defined in the CSS1 and CSS2.1 specifications,
   # respectively.

Issue 11:  s/functionality/selector functionality/




6.3.4. Default attribute values in DTDs
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#def-values) :

   # Example:
   #
   # Consider an element EXAMPLE

Issue 12:  EXAMPLE should be typeset in the same monospace font as used
for element names elsewhere in the examples.  Ditto the example in 6.4.
Class selectors.




6.6.4. The UI element states pseudo-classes
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#UIstates) :

   # The :checked pseudo-class
   #
   # Radio and checkbox elements can be toggled by the user. Some menu
   # items are "checked" when the user selects them. When such elements
   # are toggled "on" the :checked pseudo-class applies. The :checked
   # pseudo-class initially applies to such elements that have the HTML4
   # selected and checked attributes as described in Section 17.2.1 of
   # HTML4, but of course the user can toggle "off" such elements in
   # which case the :checked pseudo-class would no longer apply. While
   # the :checked pseudo-class is dynamic in nature, and is altered by
   # user action, since it can also be based on the presence of the
   # semantic HTML4 selected and checked attributes, it applies to all
   # media.

Issue 13:  why such attention to HTML4 all of a sudden?  Explanation of
the behaviour should be separated from examples (eg HTML4) which
illustrate that behaviour.




6.6.5 :nth-child() pseudo-class
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#nth-child-pseudo) :

   # The :nth-child(an+b) pseudo-class notation represents an element
   # that has an+b-1 siblings before it in the document tree, for a given
   # positive integer or zero value of n, and has a parent element.

Issue 14:  s/an+b-1/(s x n) + b - 1/




6.6.5 :nth-last-child() pseudo-class
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#nth-last-child-pseudo)
:

   # See :nth-child() pseudo-class for the syntax of its argument.

Issue 15:  Linkify the text to point to the relevant place in the document.




6.6.5 :last-of-type pseudo-class
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#last-of-type-pseudo)
:

   # Example:
   #
   # The following selector represents the last data cell td of a table
   # row.

Issue 16:  s/a table row/a table row td/ or s/a table row/an HTML table row/




6.6.5. :first-child pseudo-class
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#first-child-pseudo) :

   # Examples:
   #
   # [...]
   #
   # This selector can represent the p inside the div of the following
   # fragment:
   #
   # [...]
   #
   # but cannot represent the second p in the following fragment:
   #
   # [...]

Issue 17:  s/fragment/HTML fragment/ (twice)




6.6.5 :empty pseudo-class
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#empty-pseudo) :

   # Examples:
   #
   # p:empty is a valid representation of the following fragment:
   #
   # <p></p>
   #
   # foo:empty is not a valid representation for the following fragments:
   #
   # [...]

Issue 18:  s/fragment/HTML fragment/ (twice)




6.6.6. Blank
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#UIfragments) :

   # This section intentionally left blank.

Issue 19:  Append a description of what was previously defined here. Cf
7.3. Blank.




7. Pseudo-elements
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#pseudo-elements) :

   # Pseudo-elements create abstractions about the document tree beyond
   # those specified by the document language. For instance, document
   # languages do not offer mechanisms to access the first letter or
   # first line of an element's content.  Pseudo-elements allow designers
   # to refer to this otherwise inaccessible information. Pseudo-elements
   # may also provide designers a way to refer to content that does not
   # exist in the source document (e.g., the ::before and ::after
   # pseudo-elements give access to generated content).

Issue 20a:  The wording of the first two sentences makes it sound like
this is a limitation in the document language, but in the case of
accessing the first line, this is something which is /meaningless/ in
the document language.


Issue 20b:  The reference to "designers" seems incongruous and does not
appear in normative text anywhere else in the specification.
s/designers/authors/ and ditto in the Note in 6.5. ID selectors.




7.1. The ::first-line pseudo-element
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#first-line) :

   # CSS example:
   #
   # p::first-line { text-transform: uppercase }
   #
   # The above rule means "change the letters of the first line of every
   # paragraph to uppercase".

Issue 21a:  s/paragraph/p element/ or s/CSS example/CSS and HTML Example/


   # The selector p::first-line does not match any real HTML element. It
   # does match a pseudo-element that conforming user agents will insert
   # at the beginning of every paragraph.

Issue 21b:  s/The selector p::first-line/In an HTML document, for
example, the selector p::first-line/


   # The "first formatted line" of an element may occur inside a
   # block-level descendant in the same flow (i.e., a block-level
   # descendant that is not positioned and not a float). E.g., the first
   # line of the div in <DIV><P>This line...</P></DIV> is the first line
   # of the p (assuming that both p and div are block-level).
   #
   # The first line of a table-cell or inline-block cannot be the first
   # formatted line of an ancestor element. Thus, in
   #
   # <DIV><P STYLE="display: inline-block">Hello<BR>Goodbye</P>
   # etcetera</DIV> the first formatted line of the div is not the line
   # "Hello".

Issue 21c:  s/E.g., the first line of the div in <DIV>/E.g., the first
line of the div in the HTML fragment <DIV>/

or

          s/div/DIV/ (twice) and s/p/P/ (twice)


Issue 21d:  Prepend "In CSS, " to the latter two paragraphs.


Issue 21e:  s/Here is an example. The fictional tag sequence for/For
example, the fictional tag sequence for the HTML fragment/


   # The ::first-line pseudo-element is similar to an inline-level
   # element, but with certain restrictions. In CSS, the following
   # properties apply to a ::first-line pseudo-element: font properties,
   # color property, background properties, 'word-spacing',
   # 'letter-spacing', 'text-decoration', 'vertical-align',
   # 'text-transform', 'line-height'. UAs may apply other properties as
   # well.

Issue 21f:  "In CSS" should be placed at the start of the first
sentence, not the second.


Issue 21g:  Should the following be inserted after the second sentence?
"A future version of this specification may allow this pseudo-element to
apply to more element types."  Cf. 7.2.


   # During CSS inheritance, the portion of a child element that occurs
   # on the first line only inherits properties applicable to the
   # ::first-line pseudo-element from the ::first-line pseudo-element.
   # For all other properties inheritance is from the non-pseudo-element
   # parent of the first line pseudo element. (The portion of a child
   # element that does not occur on the first line always inherits from
   # the parent of that child.)

Issue 21h:  Prepend the last sentence with "In CSS, ".  I interpret that
sentence as a reminder of CSS behaviour, and so it might be better as a
Note.




7.2. The ::first-letter pseudo-element
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#first-letter) :

   # The ::first-letter pseudo-element represents the first letter of
   # the first line of a block, if it is not preceded by any other
   # content (such as images or inline tables) on its line. The
   # ::first-letter pseudo-element may be used for "initial caps" and
   # "drop caps", which are common typographical effects. This type of
   # initial letter is similar to an inline-level element if its 'float'
   # property is 'none'; otherwise, it is similar to a floated element.

Issue 22a:  Prepend the last sentence with "In CSS, ".


   # In CSS, these are the properties that apply to ::first-letter
   # pseudo-elements: font properties, 'text-decoration',
   # 'text-transform', 'letter-spacing', 'word-spacing' (when
   # appropriate), 'line-height', 'float', 'vertical-align' (only if
   # 'float' is 'none'), margin properties, padding properties, border
   # properties, color property, background properties.

Issue 22b:  Should the following be inserted after that sentence?  "A
future version of this specification may redefine which properties apply
to this pseudo-element."  Cf. 7.2.


   # Example:
   #
   # This example shows a possible rendering of an initial cap.

Issue 22c: s/Example:/CSS and HTML Example/


   # Example:
   #
   # The fictional tag sequence for this HTMLfragment:

Issue 22d: s/HTMLfragment/HTML fragment/


   # The first letter of a table-cell or inline-block cannot be the
   # first letter of an ancestor element. Thus, in
   # <DIV><P STYLE="display: inline-block">Hello<BR>Goodbye</P>
   # etcetera</DIV> the first letter of the div is not the letter "H". In
   # fact, the div doesn't have a first letter.
   #
   # The first letter must occur on the first formatted line. For
   # example, in this fragment: <p><br>First... the first line doesn't
   # contain any letters and ::first-letter doesn't match anything
   # (assuming the default style for br in HTML 4). In particular, it
   # does not match the "F" of "First."

Issue 22e:  Prepend the first sentence with "In CSS, " .


Issue 22f:  s/in this fragment/in this HTML fragment/


   # Example:
   #
   # After the rule 'p::before {content: "Note: "}', the selector
   # 'p::first-letter' matches the "N" of "Note".
   #
   # Note: In some cases the ::first-letter pseudo-element should
   # include more than just the first non-punctuation character on a
   # line. For example, combining characters must be kept with their base
   # character. Additionally, some languages may have specific rules
   # about how to treat certain letter combinations. The UA definition of
   # ::first-letter should include at least the default grapheme cluster
   # as defined by UAX29 and may include more than that as appropriate.
   # In Dutch, for example, if the letter combination "ij" appears at the
   # beginning of an element, both letters should be considered within
   # the ::first-letter pseudo-element. [UAX29]
   #
   # If the letters that would form the ::first-letter are not in the
   # same element, such as "'T" in <p>'<em>T..., the UA may create a
   # ::first-letter pseudo-element from one of the elements, both
   # elements, or simply not create a pseudo-element.

Issue 22g:  Typeset the selectors and rules in a monospace font as is
done elsewhere in the specification, and remove the surrounding
apostrophes.


   # Example:
   #
   # The following example illustrates how overlapping pseudo-elements
   # may interact. [...]

Issue 22h: s/Example/CSS and HTML Example/




8.1. Descendant combinator
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#descendant-combinators)
:

   # Examples:
   #
   # For example, consider the following selector:
   #
   # h1 em
   #
   # It represents an em element being the descendant of an h1 element.
   # It is a correct and valid, but partial, description of the following
   # fragment:
   #
   # <h1>This <span class="myclass">headline
   # is <em>very</em> important</span></h1>
   #
   # The following selector:
   #
   # div * p
   #
   # represents a p element that is a grandchild or later descendant of
   # a div element. Note the whitespace on either side of the "*" is not
   # part of the universal selector; the whitespace is a combinator
   # indicating that the DIV must be the ancestor of some element, and
   # that that element must be an ancestor of the P.

Issue 23a:  s/fragment/HTML fragment/


Issue 23b:  s/DIV/div/ and s/P/p/ and typeset both in a monospace font.



8.3.2. General sibling combinator
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#general-sibling-combinators)
:

   # Example:
   #
   # h1 ~ pre
   #
   # represents a pre element following an h1. It is a correct and
   # valid, but partial, description of:
   #
   # <h1>Definition of the function a</h1>
   # <p>Function a(x) has to be applied to all figures in the table.</p>
   # <pre>function a(x) = 12x/13.5</pre>

Issue 24:  s/description of/description of the following HTML fragment/




10.1. Grammar
(http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#grammar) :

   # [...] note that most UA's should not use it directly [...]

Issue 25:  s/UA's/UAs/





Cheers,
Anton Prowse
http://dev.moonhenge.net

[Boris Zbarsky]

Anton Prowse wrote:
>   # [att~=val]     Represents an element with the att attribute whose
...
> Issue 1:  Intuitively one might expect that if "val" were the empty
> string it would represent an element with the att attribute whose value
> is the empty string, rather than fail to represent anything.  (HTML5
> currently proposes that <img>, <img alt=""> and <img alt="bar"> have
> different semantics, for example, and so there is a use case for such
> matching.)

This use case is met by, respectively:

  img:not([alt])
  img[alt=""]
  img[alt]:not([alt=""])

and changing the behavior of [att~=val] wouldn't change anything in
terms of making life simpler for authors here, as far as I can see.

Note the long discussion about this earlier on this list; I think it's
been more or less discussed to death, with the WG changing and
re-changing its decision several times.

>   # Attribute values must be identifiers or strings.
>
> Issue 2a:  The term "identifier" is undefined.  (Same issue exists in
> 6.3.2.)

Indeed; this should be defined as the IDENT token from the scanner
(section 10.2).  Note that the grammar does so quite explicitly when
defining the grammar for the attribute selectors (section 10.1).

> Issue 2b:  The term "string" string is undefined, but is presumed to be
> an identifier delimited by " marks.  What about ' and other marks?
> (Same issue exists in 6.3.2.)

It's defined in the scanner (section 10.2).

Perhaps the terminology section (1.2) should just explicitly say which
of these terms refer to scanner tokens; that should help, no?

-Boris

[Anton Prowse]

Boris Zbarsky wrote:

> Anton Prowse wrote:
>>   # [att~=val]     Represents an element with the att attribute whose
> ...
>> Issue 1:  Intuitively one might expect that if "val" were the empty
>> string it would represent an element with the att attribute whose value
>> is the empty string, rather than fail to represent anything.  (HTML5
>> currently proposes that <img>, <img alt=""> and <img alt="bar"> have
>> different semantics, for example, and so there is a use case for such
>> matching.)
>
> This use case is met by, respectively:
>
>  img:not([alt])
>  img[alt=""]
>  img[alt]:not([alt=""])
>
> and changing the behavior of [att~=val] wouldn't change anything in
> terms of making life simpler for authors here, as far as I can see.
>
> Note the long discussion about this earlier on this list; I think it's
> been more or less discussed to death, with the WG changing and
> re-changing its decision several times.

Sure; I wasn't actually proposing a change to the behaviour, just
pointing out that the spec didn't match my intuition on reading (which
was backed up by an easily-conceived use case).  I'm a great believer in
explanatory text when something in an otherwise-intuitive spec goes
against intuition, so I guess I'd like to see a note somewhere
explaining, exactly as you did, that the use case is met in other ways.

Cheers,
Anton Prowse
http://dev.moonhenge.net

[L. David Baron]

On Wednesday 2009-03-11 20:37 +0100, Bert Bos wrote:
> The CSS WG published a new WD for Selectors yesterday:
>
>     http://www.w3.org/TR/2009/WD-css3-selectors-20090310

Can you make this appear on http://www.w3.org/TR/ ?  It doesn't seem
to be listed; the 2005 WD is still there.

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

[Michael Jansson]

I believe I have read comments about this but I can't find any references after going through the CSS 2.1 spec. Would appreciate any insight into this question. If you remember an old mail-thread, then just point me in the right direction (I must be searching with the wrong keywords since I'm not finding anything on this topic).

If I look at this code in a modern browser...

<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01//EN'>
<html>
<body style='border:1px solid red; background-color:#fee; margin:10px; padding:0px'>
Some text
</body>
</html> 

...I'm getting a page with colored margin. I believe the spec is pretty clear that margins are transparent, thus letter the background of the containing block to show though. However, I think I have read somewhere that there is an exception for the body/root element. It's background property would not only be applied to the content and padding region like it would for other elements, but it would also cover its margins. Is this correct? Are there other exceptions like this? (Don't think the spec is very clear).

Anyhow, this is what I believe I have read somewhere, but I can find any references to this. If this is not the case, then what is it that I am missing here? Why is the margin region pink with the code above?

A second question would be why there is such a difference between the result in browsers when the DTD is removed from the code above? The margin is collapsed in IE, the height is expanded in both IE and Safari, and FireFox and Opera remains unchanged. 

[Giovanni Campagna]

2009/4/14 Michael Jansson <mjan@...>:

> I believe I have read comments about this but I can't find any references
> after going through the CSS 2.1 spec. Would appreciate any insight into this
> question. If you remember an old mail-thread, then just point me in the
> right direction (I must be searching with the wrong keywords since I'm not
> finding anything on this topic).
>
> If I look at this code in a modern browser...
>
> <!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01//EN'>
> <html>
> <body style='border:1px solid red; background-color:#fee; margin:10px;
> padding:0px'>
> Some text
> </body>
> </html>
>
> ...I'm getting a page with colored margin. I believe the spec is pretty
> clear that margins are transparent, thus letter the background of the
> containing block to show though. However, I think I have read somewhere that
> there is an exception for the body/root element. It's background property
> would not only be applied to the content and padding region like it would
> for other elements, but it would also cover its margins. Is this correct?
> Are there other exceptions like this? (Don't think the spec is very clear).

Section 14.2: "The background of the root element becomes the
background of the canvas and covers the entire canvas, anchored (for
'background-position') 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. Such
backgrounds must also be anchored at the same point as they would be
if they were painted only for the root element. This does not apply to
XHTML documents."

The same rule is for "overflow". It has been proposed to extend this
to <body> in XML, in the XHTML namespace, but the feature is at-risk.

> Anyhow, this is what I believe I have read somewhere, but I can find any
> references to this. If this is not the case, then what is it that I am
> missing here? Why is the margin region pink with the code above?

Because the background of HTML body is treatead as the background of
the canvas. So not only it covers margins, but it covers also the part
of the canvas after the end of content.

> A second question would be why there is such a difference between the result
> in browsers when the DTD is removed from the code above? The margin is
> collapsed in IE, the height is expanded in both IE and Safari, and FireFox
> and Opera remains unchanged.

You experienced "quirks mode": a different, non conforming layout mode
that UAs keep for backward-compatibility and it is triggered by "old"
DTDs.

> Thanks,
> Em2 Solutions AB
> Michael Jansson
>

Giovanni

[Boris Zbarsky]

Michael Jansson wrote:
> ...I'm getting a page with colored margin. I believe the spec is pretty
> clear that margins are transparent, thus letter the background of the
> containing block to show though. However, I think I have read somewhere
> that there is an exception for the body/root element.

CSS2.1 section 14.2 (The background), paragraphs 3 and 4.

> A second question would be why there is such a difference between the
> result in browsers when the DTD is removed from the code above?

Because then you trigger quirks mode.

-Boris

[fantasai]

Anton Prowse wrote:

> Congratulations on a very solid-looking specification!
>
> Here are the things that I noticed when reading through the document.
> (Trivial editorial issues are listed separately at the end.)
>
>
> 6.3. Attribute selectors
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#attribute-selectors)
> :
>
>   # [att~=val]     Represents an element with the att attribute whose
>   # value is a whitespace-separated list of words, one of which is
>   # exactly "val". If "val" contains whitespace, it will never represent
>   # anything (since the words are separated by spaces). Also if "val" is
>   # the empty string, it will never represent anything.
>
> Issue 1:  Intuitively one might expect that if "val" were the empty
> string it would represent an element with the att attribute whose value
> is the empty string, rather than fail to represent anything.  (HTML5
> currently proposes that <img>, <img alt=""> and <img alt="bar"> have
> different semantics, for example, and so there is a use case for such
> matching.)  If such matching is truly not permitted, perhaps it is worth
> explicitly stating that.  (The equivalent situation with the
> substring-matching attribute selectors seems reasonable as specified,
> however.)

See bz's response:
   http://lists.w3.org/Archives/Public/www-style/2009Mar/0153.html

I'm going to close this issue as no change. Please let me know if you
object.

~fantasai

[fantasai]

Anton Prowse wrote:

> Congratulations on a very solid-looking specification!
>
> Here are the things that I noticed when reading through the document.
> (Trivial editorial issues are listed separately at the end.)
> ...
> 6.6.4. The UI element states pseudo-classes
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#UIstates) :
>
>   # Most elements will be neither :enabled nor :disabled.
>
> Issue 3:  This sentence is meaningless for general document languages.

It's meant to clarify that e.g. paragraph text does not match either
:enabled or :disabled. Adjusted to

  # In a typical document most elements will be neither :enabled nor
  # :disabled."

but I don't think we should remove it.

Please let me know if this is acceptable.

~fantasai

[fantasai]

Anton Prowse wrote:

> Congratulations on a very solid-looking specification!
>
> Here are the things that I noticed when reading through the document.
> (Trivial editorial issues are listed separately at the end.)
> ...
> 7.1. The ::first-line pseudo-element
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#first-line) :
>
>   # In CSS, the ::first-line pseudo-element can only be attached to a
>   # block-level element, an inline-block, a table-caption, or a
>   # table-cell.
>
> Issue 7a:  This does not really add anything to the
> discussion, and runs the risk of becoming incorrect as other parts of
> the CSS specification change.  It could be removed.  A more general
> statement should be inserted in the introduction to Section 7, stating
> that the applicability of pseudo-elements may be dependent on the nature
> of the subjects of the selector.  (This statement should be inserted
> even if the paragraph is not removed.)

Changed to
   # <p>In CSS, the <code>::first-line</code> pseudo-element can only
   # have an effect when attached to a block-like container such as a
   # block box, inline-block, table-caption, or table-cell.</p>

>   # A UA should act as if the fictional start tags of the ::first-line
>   # pseudo-elements were nested just inside the innermost enclosing
>   # block-level element. (Since CSS1 and CSS2 were silent on this case,
>   # authors should not rely on this behavior.) Here is an example. The
>   # fictional tag sequence for [...]
>
> Issue 7b:  Should the parenthetical sentence be a note?  It seems out of
> place in normative text.

It's a normative recommendation. I don't really see a good reason to
change it at this point, so I'm going to leave it as-is.

Please let me know if this addresses your comments.

~fantasai

[fantasai]

Anton Prowse wrote:

> Congratulations on a very solid-looking specification!
>
> Here are the things that I noticed when reading through the document.
> (Trivial editorial issues are listed separately at the end.)
>
> ...
>
> 6.6.5 :nth-child() pseudo-class
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#nth-child-pseudo) :
>
>   # The :nth-child(an+b) pseudo-class notation represents an element
>   # that has an+b-1 siblings before it in the document tree, for a given
>   # positive integer or zero value of n, and has a parent element.
>
> Issue 5a:  s/for a given/for some/.  Ditto for the description of the
> other related pseudo-elements.

Replaced with "for any".

>   # In other words, this matches the bth child of an element after all
>   # the children have been split into groups of a elements each.
>
> Issue 5b:  It matches the bth child *of each group* after the children
> have been partitioned into groups (the last group having possibly fewer
> than 'a' elements).  Also, the sentence makes no sense when either a or
> b is zero or negative.  The sentence is not necessary, will be too long
> when corrected to accurately explain modular arithmetic, and should be
> omitted altogether.  Ditto for the description of the :nth-of-type()
> pseudo-class.

Replaced with
   # For values of <var>a</var> and <var>b</var> greater than zero, this
   # effectively divides the element's children into groups of <var>a</var>
   # elements (the last group taking the remainder), and selecting the
   # <var>b</var>th element of each group.
for :nth-child() and removed from :nth-of-type.

>   #   Examples:
>   #     [...]
>   #     p:nth-child(4n+1) { color: navy; }
>   #     p:nth-child(4n+2) { color: green; }
>   #     p:nth-child(4n+3) { color: maroon; }
>   #     p:nth-child(4n+4) { color: purple; }
>
> Issue 5c:  It is much more natural to use :nth-child(4n) than
> :nth-child(4n+4) (although you would then want it to be first in the
> list rather than last).  It was probably avoided because the case b=0
> has not yet been discussed so far in the document --- but there is a
> precedent higher up in the example: :nth-child( +6 ).

I think it's written like that to keep the parallel with the other
selectors in that listing. I'm going to leave this as-is. I've also
reordered the examples so that syntax is only used after it has been
explained.

>   # When a=0, the an part need not be included (unless the b part is
>   # already omitted). When an is not included, the + sign before b (when
>   # allowed) may also be omitted.
>
> Issue 5d:  s/When an is not included, the + sign before b (when allowed)
> may also be omitted/When an is not included and b is non-negative, a +
> sign before b may also be omitted/

Fixed.

> Issue 5e:  There is no discussion in this subsection of the omission of
> the + sign before a, which is curious given that all other possible
> omissions are discussed.

This is because the omission of + before a is covered by plus signs
on positive integers being optional. The + before the b, in the full
syntax, is considered binary operator between an and b, so saying
that an can be dropped is not enough.

>   # In this case the syntax simplifies to :nth-child(b) and the last
>   # example simplifies to :nth-child(5).
>
> Issue 5f:  The only unsimplified cases which simplifies to :nth-child(5)
> when a is zero and b is non-negative are :nth-child(0n+5) and
> :nth-child(-0n+5), neither of which are the last (or indeed any) example.

Good catch. Removed and changed the next example to use 5 instead of 1.

Please let me know if these changes address your comments.

~fantasai

[Anton Prowse]

fantasai wrote:

> Anton Prowse wrote:
>> 6.6.5 :nth-child() pseudo-class
>> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#nth-child-pseudo)
>> :
>>
>>   # The :nth-child(an+b) pseudo-class notation represents an element
>>   # that has an+b-1 siblings before it in the document tree, for a given
>>   # positive integer or zero value of n, and has a parent element.
>>
>> Issue 5a:  s/for a given/for some/.  Ditto for the description of the
>> other related pseudo-elements.
>
> Replaced with "for any".
>

"for some value" is the mathematically precise way of formulating this
type of sentence, whilst "for any value" is ambiguous.  However, since
the interpretation of "for any value" as "for all values" is nonsensical
here (meaning that "for some value" is the only remaining sensible
interpretation) I can live with the change if you think it's more
accessible to non-mathematicians!

Cheers,
Anton Prowse
http://dev.moonhenge.net

[Anton Prowse]

fantasai wrote:

> Anton Prowse wrote:
>> 6.6.4. The UI element states pseudo-classes
>> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#UIstates) :
>>
>>   # Most elements will be neither :enabled nor :disabled.
>>
>> Issue 3:  This sentence is meaningless for general document languages.
>
> It's meant to clarify that e.g. paragraph text does not match either
> :enabled or :disabled. Adjusted to
>
>  # In a typical document most elements will be neither :enabled nor
>  # :disabled."
>
> but I don't think we should remove it.
>
> Please let me know if this is acceptable.

This seems fine!

Cheers,
Anton Prowse
http://dev.moonhenge.net

[fantasai]

Anton Prowse wrote:

> Congratulations on a very solid-looking specification!
>
> Here are the things that I noticed when reading through the document.
> (Trivial editorial issues are listed separately at the end.)
> ...
> 8.2. Child combinators
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#child-combinators) :
>
>   # A child combinator describes a childhood relationship between two
>   # elements. A child combinator is made of the "greater-than sign" (>)
>   # character and separates two sequences of simple selectors.
>
> Issue 9:  s/"greater-than sign" (>)/"greater-than sign" (U+003E, >)/

Fixed, thanks.

> Trivial editorial matters
> -------------------------
>
> General comments :
>
> Issue 10:  Notes are currently not displayed consistently, cf "Note:",
> "Note.", subsequent capital letter or lowercase letter.  All notes
> should begin with "Note:" or similar; currently this is not the case in
> 6.6.1, 6.6.5, 7, 7.1 and 7.2.

Fixed.

> 1. Introduction
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#context) :
>
>   # Selectors Level 1 and Selectors Level 2 are defined as the subsets
>   # of functionality defined in the CSS1 and CSS2.1 specifications,
>   # respectively.
>
> Issue 11:  s/functionality/selector functionality/

Fixed.

> 6.3.4. Default attribute values in DTDs
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#def-values) :
>
>   # Example:
>   #
>   # Consider an element EXAMPLE
>
> Issue 12:  EXAMPLE should be typeset in the same monospace font as used
> for element names elsewhere in the examples.  Ditto the example in 6.4.
> Class selectors.

Done.

> 6.6.4. The UI element states pseudo-classes
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#UIstates) :
>
>   # The :checked pseudo-class
>   #
>   # Radio and checkbox elements can be toggled by the user. Some menu
>   # items are "checked" when the user selects them. When such elements
>   # are toggled "on" the :checked pseudo-class applies. The :checked
>   # pseudo-class initially applies to such elements that have the HTML4
>   # selected and checked attributes as described in Section 17.2.1 of
>   # HTML4, but of course the user can toggle "off" such elements in
>   # which case the :checked pseudo-class would no longer apply. While
>   # the :checked pseudo-class is dynamic in nature, and is altered by
>   # user action, since it can also be based on the presence of the
>   # semantic HTML4 selected and checked attributes, it applies to all
>   # media.
>
> Issue 13:  why such attention to HTML4 all of a sudden?  Explanation of
> the behaviour should be separated from examples (eg HTML4) which
> illustrate that behaviour.

Good catch. Rearranged the text to read:

   # Radio and checkbox elements can be toggled by the user. Some menu
   # items are "checked" when the user selects them. When such elements
   # are toggled "on" the :checked pseudo-class applies. While the
   # :checked pseudo-class is dynamic in nature, and can altered by user
   # action, since it can also be based on the presence of semantic
   # attributes in the document, it applies to all media. For example,
   # the :checked pseudo-class initially applies to such elements that
   # have the HTML4 selected and checked attributes as described in
   # Section 17.2.1 of HTML4, but of course the user can toggle "off"
   # such elements in which case the :checked pseudo-class would no
   # longer apply.

I believe that closes this issue.

> 6.6.5 :nth-child() pseudo-class
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#nth-child-pseudo) :
>
>   # The :nth-child(an+b) pseudo-class notation represents an element
>   # that has an+b-1 siblings before it in the document tree, for a given
>   # positive integer or zero value of n, and has a parent element.
>
> Issue 14:  s/an+b-1/(s x n) + b - 1/

I don't understand this suggestion. Did you want a multiplication sign
between a and n?

> 6.6.5 :nth-last-child() pseudo-class
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#nth-last-child-pseudo)
>
> :
>
>   # See :nth-child() pseudo-class for the syntax of its argument.
>
> Issue 15:  Linkify the text to point to the relevant place in the document.

Fixed.

> 6.6.5 :last-of-type pseudo-class
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#last-of-type-pseudo)
> :
>
>   # Example:
>   #
>   # The following selector represents the last data cell td of a table
>   # row.
>
> Issue 16:  s/a table row/a table row td/ or s/a table row/an HTML table
> row/

Fixed. (You meant tr, I presume, not td.)

> 6.6.5. :first-child pseudo-class
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#first-child-pseudo)
> :
>
>   # Examples:
>   #
>   # [...]
>   #
>   # This selector can represent the p inside the div of the following
>   # fragment:
>   #
>   # [...]
>   #
>   # but cannot represent the second p in the following fragment:
>   #
>   # [...]
>
> Issue 17:  s/fragment/HTML fragment/ (twice)

Actually, it does not matter whether it is HTML or not. So I will not
make this change.

> 6.6.5 :empty pseudo-class
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#empty-pseudo) :
>
>   # Examples:
>   #
>   # p:empty is a valid representation of the following fragment:
>   #
>   # <p></p>
>   #
>   # foo:empty is not a valid representation for the following fragments:
>   #
>   # [...]
>
> Issue 18:  s/fragment/HTML fragment/ (twice)

Or, for the same reason, this one.

> 6.6.6. Blank
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#UIfragments) :
>
>   # This section intentionally left blank.
>
> Issue 19:  Append a description of what was previously defined here. Cf
> 7.3. Blank.

Ok.

> 7. Pseudo-elements
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#pseudo-elements) :
>
>   # Pseudo-elements create abstractions about the document tree beyond
>   # those specified by the document language. For instance, document
>   # languages do not offer mechanisms to access the first letter or
>   # first line of an element's content.  Pseudo-elements allow designers
>   # to refer to this otherwise inaccessible information. Pseudo-elements
>   # may also provide designers a way to refer to content that does not
>   # exist in the source document (e.g., the ::before and ::after
>   # pseudo-elements give access to generated content).
>
> Issue 20a:  The wording of the first two sentences makes it sound like
> this is a limitation in the document language, but in the case of
> accessing the first line, this is something which is /meaningless/ in
> the document language.

Not sure what I can do about that, so I'm going to leave it.

> Issue 20b:  The reference to "designers" seems incongruous and does not
> appear in normative text anywhere else in the specification.
> s/designers/authors/ and ditto in the Note in 6.5. ID selectors.

Fixed.

> 7.1. The ::first-line pseudo-element
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#first-line) :
>
>   # CSS example:
>   #
>   # p::first-line { text-transform: uppercase }
>   #
>   # The above rule means "change the letters of the first line of every
>   # paragraph to uppercase".
>
> Issue 21a:  s/paragraph/p element/ or s/CSS example/CSS and HTML Example/

Fixed.

>   # The selector p::first-line does not match any real HTML element. It
>   # does match a pseudo-element that conforming user agents will insert
>   # at the beginning of every paragraph.
>
> Issue 21b:  s/The selector p::first-line/In an HTML document, for
> example, the selector p::first-line/

Since the sentence technically isn't inaccurate, I'm going to leave this one.

>   # The "first formatted line" of an element may occur inside a
>   # block-level descendant in the same flow (i.e., a block-level
>   # descendant that is not positioned and not a float). E.g., the first
>   # line of the div in <DIV><P>This line...</P></DIV> is the first line
>   # of the p (assuming that both p and div are block-level).
>   #
>   # The first line of a table-cell or inline-block cannot be the first
>   # formatted line of an ancestor element. Thus, in
>   #
>   # <DIV><P STYLE="display: inline-block">Hello<BR>Goodbye</P>
>   # etcetera</DIV> the first formatted line of the div is not the line
>   # "Hello".
>
> Issue 21c:  s/E.g., the first line of the div in <DIV>/E.g., the first
> line of the div in the HTML fragment <DIV>/
> or
>          s/div/DIV/ (twice) and s/p/P/ (twice)

Took the second option.

> Issue 21d:  Prepend "In CSS, " to the latter two paragraphs.

Added a new heading to mark all of this text as applying to CSS's definition
of "first formatted line".

> Issue 21e:  s/Here is an example. The fictional tag sequence for/For
> example, the fictional tag sequence for the HTML fragment/

Fixed.

>   # The ::first-line pseudo-element is similar to an inline-level
>   # element, but with certain restrictions. In CSS, the following
>   # properties apply to a ::first-line pseudo-element: font properties,
>   # color property, background properties, 'word-spacing',
>   # 'letter-spacing', 'text-decoration', 'vertical-align',
>   # 'text-transform', 'line-height'. UAs may apply other properties as
>   # well.
>
> Issue 21f:  "In CSS" should be placed at the start of the first
> sentence, not the second.

Shifted the mention of CSS, but not to the start of the first sentence
since we have the header now.

> Issue 21g:  Should the following be inserted after the second sentence?
> "A future version of this specification may allow this pseudo-element to
> apply to more element types."  Cf. 7.2.

I think it's more likely that we'll add support for inline::first-letter
than inline::first-line. So I'm going to leave the text as-is.

>   # During CSS inheritance, the portion of a child element that occurs
>   # on the first line only inherits properties applicable to the
>   # ::first-line pseudo-element from the ::first-line pseudo-element.
>   # For all other properties inheritance is from the non-pseudo-element
>   # parent of the first line pseudo element. (The portion of a child
>   # element that does not occur on the first line always inherits from
>   # the parent of that child.)
>
> Issue 21h:  Prepend the last sentence with "In CSS, ".  I interpret that
> sentence as a reminder of CSS behaviour, and so it might be better as a
> Note.

No, this is not normal CSS behavior, and this prose needs to be normative.
Normal CSS behavior inherits only through the element tree, and here we
have an element inheriting from two different parents.

> 7.2. The ::first-letter pseudo-element
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#first-letter) :
>
>   # The ::first-letter pseudo-element represents the first letter of
>   # the first line of a block, if it is not preceded by any other
>   # content (such as images or inline tables) on its line. The
>   # ::first-letter pseudo-element may be used for "initial caps" and
>   # "drop caps", which are common typographical effects. This type of
>   # initial letter is similar to an inline-level element if its 'float'
>   # property is 'none'; otherwise, it is similar to a floated element.
>
> Issue 22a:  Prepend the last sentence with "In CSS, ".

Done.

>   # In CSS, these are the properties that apply to ::first-letter
>   # pseudo-elements: font properties, 'text-decoration',
>   # 'text-transform', 'letter-spacing', 'word-spacing' (when
>   # appropriate), 'line-height', 'float', 'vertical-align' (only if
>   # 'float' is 'none'), margin properties, padding properties, border
>   # properties, color property, background properties.
>
> Issue 22b:  Should the following be inserted after that sentence?  "A
> future version of this specification may redefine which properties apply
> to this pseudo-element."  Cf. 7.2.

We already have an exception allowing UAs to apply other properties,
so I will leave this alone.

>   # Example:
>   #
>   # This example shows a possible rendering of an initial cap.
>
> Issue 22c: s/Example:/CSS and HTML Example/

Changed.

>   # Example:
>   #
>   # The fictional tag sequence for this HTMLfragment:
>
> Issue 22d: s/HTMLfragment/HTML fragment/

Fixed.

>   # The first letter of a table-cell or inline-block cannot be the
>   # first letter of an ancestor element. Thus, in
>   # <DIV><P STYLE="display: inline-block">Hello<BR>Goodbye</P>
>   # etcetera</DIV> the first letter of the div is not the letter "H". In
>   # fact, the div doesn't have a first letter.
>   #
>   # The first letter must occur on the first formatted line. For
>   # example, in this fragment: <p><br>First... the first line doesn't
>   # contain any letters and ::first-letter doesn't match anything
>   # (assuming the default style for br in HTML 4). In particular, it
>   # does not match the "F" of "First."
>
> Issue 22e:  Prepend the first sentence with "In CSS, " .

Fixed.

> Issue 22f:  s/in this fragment/in this HTML fragment/

Fixed.

>   # Example:
>   #
>   # After the rule 'p::before {content: "Note: "}', the selector
>   # 'p::first-letter' matches the "N" of "Note".
>   #
>   # Note: In some cases the ::first-letter pseudo-element should
>   # include more than just the first non-punctuation character on a
>   # line. For example, combining characters must be kept with their base
>   # character. Additionally, some languages may have specific rules
>   # about how to treat certain letter combinations. The UA definition of
>   # ::first-letter should include at least the default grapheme cluster
>   # as defined by UAX29 and may include more than that as appropriate.
>   # In Dutch, for example, if the letter combination "ij" appears at the
>   # beginning of an element, both letters should be considered within
>   # the ::first-letter pseudo-element. [UAX29]
>   #
>   # If the letters that would form the ::first-letter are not in the
>   # same element, such as "'T" in <p>'<em>T..., the UA may create a
>   # ::first-letter pseudo-element from one of the elements, both
>   # elements, or simply not create a pseudo-element.
>
> Issue 22g:  Typeset the selectors and rules in a monospace font as is
> done elsewhere in the specification, and remove the surrounding
> apostrophes.

Fixed.

>   # Example:
>   #
>   # The following example illustrates how overlapping pseudo-elements
>   # may interact. [...]
>
> Issue 22h: s/Example/CSS and HTML Example/

Fixed.

> 8.1. Descendant combinator
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#descendant-combinators)
>
> :
>
>   # Examples:
>   #
>   # For example, consider the following selector:
>   #
>   # h1 em
>   #
>   # It represents an em element being the descendant of an h1 element.
>   # It is a correct and valid, but partial, description of the following
>   # fragment:
>   #
>   # <h1>This <span class="myclass">headline
>   # is <em>very</em> important</span></h1>
>   #
>   # The following selector:
>   #
>   # div * p
>   #
>   # represents a p element that is a grandchild or later descendant of
>   # a div element. Note the whitespace on either side of the "*" is not
>   # part of the universal selector; the whitespace is a combinator
>   # indicating that the DIV must be the ancestor of some element, and
>   # that that element must be an ancestor of the P.
>
> Issue 23a:  s/fragment/HTML fragment/

Not necessary, so leaving as-is.

> Issue 23b:  s/DIV/div/ and s/P/p/ and typeset both in a monospace font.

Fixed.

> 8.3.2. General sibling combinator
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#general-sibling-combinators)
>
> :
>
>   # Example:
>   #
>   # h1 ~ pre
>   #
>   # represents a pre element following an h1. It is a correct and
>   # valid, but partial, description of:
>   #
>   # <h1>Definition of the function a</h1>
>   # <p>Function a(x) has to be applied to all figures in the table.</p>
>   # <pre>function a(x) = 12x/13.5</pre>
>
> Issue 24:  s/description of/description of the following HTML fragment/

Not necessary, so leaving as-is.

> 10.1. Grammar
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#grammar) :
>
>   # [...] note that most UA's should not use it directly [...]
>
> Issue 25:  s/UA's/UAs/

Fixed.

~fantasai

[Anton Prowse]

fantasai wrote:

> Anton Prowse wrote:
>> Here are the things that I noticed when reading through the document.
>> (Trivial editorial issues are listed separately at the end.)
>> 6.6.5 :nth-child() pseudo-class
>> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#nth-child-pseudo)
>> :
>>
>>   # The :nth-child(an+b) pseudo-class notation represents an element
>>   # that has an+b-1 siblings before it in the document tree, for a given
>>   # positive integer or zero value of n, and has a parent element.
>>
>> Issue 14:  s/an+b-1/(s x n) + b - 1/
>
> I don't understand this suggestion. Did you want a multiplication sign
> between a and n?

Oops, I meant:
s/an+b-1/(a x n) + b - 1/
but I think you guessed that anyway.

Yes, at the time I would have preferred a multiplication sign when such
an expression were used in the prose, or else have that expression
typeset in a different font to indicate its mathematical nature.
(Otherwise, "an" looks like an English word rather than mathematical
notation.)  However, it seems that the typesetting has already been
changed in the latest draft (or else I no longer remember what I was
concerned about!) and so I withdraw my concern.

>> 6.6.5 :last-of-type pseudo-class
>> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#last-of-type-pseudo)
>>
>> :
>>
>>   # Example:
>>   #
>>   # The following selector represents the last data cell td of a table
>>   # row.
>>
>> Issue 16:  s/a table row/a table row td/ or s/a table row/an HTML
>> table row/
>
> Fixed. (You meant tr, I presume, not td.)

Indeed!

>> 6.6.5. :first-child pseudo-class
>> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#first-child-pseudo)
>> :
>>
>>   # Examples:
>>   #
>>   # [...]
>>   #
>>   # This selector can represent the p inside the div of the following
>>   # fragment:
>>   #
>>   # [...]
>>   #
>>   # but cannot represent the second p in the following fragment:
>>   #
>>   # [...]
>>
>> Issue 17:  s/fragment/HTML fragment/ (twice)
>
> Actually, it does not matter whether it is HTML or not. So I will not
> make this change.

I'm skeptical ;-)  The example assumes an SGML/XML notation, eg "<p>"

>
>> 6.6.5 :empty pseudo-class
>> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#empty-pseudo) :
>>
>>   # Examples:
>>   #
>>   # p:empty is a valid representation of the following fragment:
>>   #
>>   # <p></p>
>>   #
>>   # foo:empty is not a valid representation for the following fragments:
>>   #
>>   # [...]
>>
>> Issue 18:  s/fragment/HTML fragment/ (twice)
>
> Or, for the same reason, this one.

Ditto.

>> 7.1. The ::first-line pseudo-element
>> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#first-line) :
>>
>>   # The selector p::first-line does not match any real HTML element. It
>>   # does match a pseudo-element that conforming user agents will insert
>>   # at the beginning of every paragraph.
>>
>> Issue 21b:  s/The selector p::first-line/In an HTML document, for
>> example, the selector p::first-line/
>
> Since the sentence technically isn't inaccurate, I'm going to leave this
> one.

Not sure I like this!  Actually, in retrospect the problem lies with the
example above the quoted sentence:

   # The above rule means "change the letters of the first line of every
paragraph to uppercase".

s/The above rule/In HTML, the above rule/

or

s/paragraph/p element/

To me, leaving the quoted sentence unchanged seems more reasonable in
the light of the first variant of this new proposed change, but I would
still find it incongruous with the second.

>> 8.1. Descendant combinator
>> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#descendant-combinators)
>>
>> :
>>
>>   # Examples:
>>   #
>>   # For example, consider the following selector:
>>   #
>>   # h1 em
>>   #
>>   # It represents an em element being the descendant of an h1 element.
>>   # It is a correct and valid, but partial, description of the following
>>   # fragment:
>>   #
>>   # <h1>This <span class="myclass">headline
>>   # is <em>very</em> important</span></h1>
>>   #
>>   # The following selector:
>>   #
>>   # div * p
>>   #
>>   # represents a p element that is a grandchild or later descendant of
>>   # a div element. Note the whitespace on either side of the "*" is not
>>   # part of the universal selector; the whitespace is a combinator
>>   # indicating that the DIV must be the ancestor of some element, and
>>   # that that element must be an ancestor of the P.
>>
>> Issue 23a:  s/fragment/HTML fragment/
>
> Not necessary, so leaving as-is.

As above.

>> 8.3.2. General sibling combinator
>> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#general-sibling-combinators)
>>
>> :
>>
>>   # Example:
>>   #
>>   # h1 ~ pre
>>   #
>>   # represents a pre element following an h1. It is a correct and
>>   # valid, but partial, description of:
>>   #
>>   # <h1>Definition of the function a</h1>
>>   # <p>Function a(x) has to be applied to all figures in the table.</p>
>>   # <pre>function a(x) = 12x/13.5</pre>
>>
>> Issue 24:  s/description of/description of the following HTML fragment/
>
> Not necessary, so leaving as-is.

As above.


Cheers,
Anton Prowse
http://dev.moonhenge.net

[fantasai]

Anton Prowse wrote:

>
>>> 6.6.5. :first-child pseudo-class
>>> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#first-child-pseudo)
>>> :
>>>
>>>   # Examples:
>>>   #
>>>   # [...]
>>>   #
>>>   # This selector can represent the p inside the div of the following
>>>   # fragment:
>>>   #
>>>   # [...]
>>>   #
>>>   # but cannot represent the second p in the following fragment:
>>>   #
>>>   # [...]
>>>
>>> Issue 17:  s/fragment/HTML fragment/ (twice)
>>
>> Actually, it does not matter whether it is HTML or not. So I will not
>> make this change.
>
> I'm skeptical ;-)  The example assumes an SGML/XML notation, eg "<p>"

 >
 >>> 6.6.5 :empty pseudo-class
 >>> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#empty-pseudo) :
 > ...
 > Ditto.
 >
 >>> 8.1. Descendant combinator
 >>> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#descendant-combinators)
 > ...
 > As above.
 >
 >
 >>> 8.3.2. General sibling combinator
 >>> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#general-sibling-combinators)
 >...
 > As above.

Added a statement to the Terminology section specifying that examples
are given in XML/HTML syntax:
    http://dev.w3.org/csswg/selectors3/#terminology

>>> 7.1. The ::first-line pseudo-element
>>> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#first-line) :
>>>
>>>   # The selector p::first-line does not match any real HTML element. It
>>>   # does match a pseudo-element that conforming user agents will insert
>>>   # at the beginning of every paragraph.
>>>
>>> Issue 21b:  s/The selector p::first-line/In an HTML document, for
>>> example, the selector p::first-line/
>>
>> Since the sentence technically isn't inaccurate, I'm going to leave
>> this one.
>
> Not sure I like this!  Actually, in retrospect the problem lies with the
> example above the quoted sentence:
>
>   # The above rule means "change the letters of the first line of every
> paragraph to uppercase".
>
> s/The above rule/In HTML, the above rule/
>
> or
>
> s/paragraph/p element/
>
> To me, leaving the quoted sentence unchanged seems more reasonable in
> the light of the first variant of this new proposed change, but I would
> still find it incongruous with the second.

Changed s/paragraph/p element/ and shifted the paragraph into the example.


Please let me know if this addresses your comments.

~fantasai

[Anton Prowse]

fantasai wrote:
> Anton Prowse wrote:
>> Issue 5e:  There is no discussion in this subsection of the omission of
>> the + sign before a, which is curious given that all other possible
>> omissions are discussed.
>
> This is because the omission of + before a is covered by plus signs
> on positive integers being optional. The + before the b, in the full
> syntax, is considered binary operator between an and b, so saying
> that an can be dropped is not enough.

Pedantically speaking, a signed positive integer is not the same thing
as a positive integer.  (The + sign is optional before positive integers
only in informal settings which blur the two.)  The grammar permits a +
sign before a, but neither the prose nor the examples mention it.  I
think there's a need for a sentence saying that the + sign is both
permitted and optional.

Cheers,
Anton Prowse
http://dev.moonhenge.net

[Anton Prowse]

Anton Prowse wrote:

> fantasai wrote:
>> Anton Prowse wrote:
>>> Issue 5e:  There is no discussion in this subsection of the omission of
>>> the + sign before a, which is curious given that all other possible
>>> omissions are discussed.
>>
>> This is because the omission of + before a is covered by plus signs
>> on positive integers being optional. The + before the b, in the full
>> syntax, is considered binary operator between an and b, so saying
>> that an can be dropped is not enough.
>
> Pedantically speaking, a signed positive integer is not the same thing
> as a positive integer.  (The + sign is optional before positive integers
> only in informal settings which blur the two.)  The grammar permits a +
> sign before a, but neither the prose nor the examples mention it.  I
> think there's a need for a sentence saying that the + sign is both
> permitted and optional.

Apologies, this is indeed a non-issue given the definition of integer in
CSS21 / css3-values.

Cheers,
Anton Prowse
http://dev.moonhenge.net

[fantasai]

Anton Prowse wrote:

> Congratulations on a very solid-looking specification!
>
> Here are the things that I noticed when reading through the document.
> (Trivial editorial issues are listed separately at the end.)
>
> ...
>
> 6.6.5. Structural pseudo-classes
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#structural-pseudos)
> :
>
>   # Standalone pieces of PCDATA (text nodes in the DOM) and other
>   # non-element nodes are not counted when calculating the position of
>   # an element in the list of children of its parent.
>
> Issue 4:  Neither "PCDATA" nor "DOM" are defined in this document.
> "PCDATA" is not used anywhere else in the document, and "DOM" is only
> used once more in normative text, in the subsection ':empty
> pseudo-class' of this section.
>
> ...
>
> 6.6.5 :empty pseudo-class
> (http://www.w3.org/TR/2009/WD-css3-selectors-20090310/#empty-pseudo) :
>
>   # The :empty pseudo-class represents an element that has no children
>   # at all. In terms of the DOM, only element nodes and text nodes
>   # (including CDATA nodes and entity references) whose data has a
>   # non-zero length must be considered as affecting emptiness; comments,
>   # PIs, and other nodes must not affect whether an element is
>   # considered empty or not.
>
> Issue 6:  Neither "DOM", "CDATA" nor "PI" are defined in this document.
> Neither "CDATA" nor "PI" is used anywhere else in the document, and
> "DOM" is only used once more in normative text, in the introduction to
> this section.

I've attempted to handle these by altering the wording and adding an
informative reference to DOM3 Core:
   http://dev.w3.org/cvsweb/csswg/selectors3/Overview.html.diff?r1=1.60&r2=1.61&f=h

Please let me know if this addresses your comment.

~fantasai