W3C home > Mailing lists > Public > www-style@w3.org > January 2011

[CSS21] Editorial issues with Ch. 6 (Assigning property values, Cascading, and Inheritance) - comments on Working Draft

From: Anton Prowse <prowse@moonhenge.net>
Date: Fri, 07 Jan 2011 21:46:26 +0100
Message-ID: <4D277BA2.4020805@moonhenge.net>
To: "www-style@w3.org" <www-style@w3.org>
Issue 1: 6.2 Inheritance says:

   # When inheritance occurs, elements inherit computed values. The
   # computed value from the parent element becomes both the specified
   # value and the computed value on the child.

This is not the case when the keyword 'inherit' is used, though.  In 
that case, the specified value is 'inherit', which is never the same as 
the computed value.

Secondly, this section does not actually define when inheritance occurs. 
  Is that because inheritance /always/ occurs when it can?  (That would 
be consistent with 6.1.1 which says that the specified value is defined 
to be the value resulting from the cascade if it exists, else a value 
resulting from inheritance (else...).)  In other words, if a property is 
inheritable, does every element have an internal property which stores 
the inherited value, regardless of whether that value is actually used 
for the computed value?

If this is the case, could this be made a little clearer in 6.2?

Issue 2: As a result of the resolution of Issue 193,[1] 6.2 now says:

   # Note that inheritance follows the document tree and is not
   # intercepted by anonymous boxes.

As the spec currently stands, this sentence is redundant since 
properties and their specified/computed/used/actual values are 
associated with elements, not boxes.  IMO the new sentence actually 
introduces confusion where there was none before, not least because 
boxes (let alone anonymous ones) are not introduced until a later 
chapter and there is no hyperlink to the relevant definition.

Note, however, that this sentence could become acceptable (modulo the 
elements vs boxes issue) if something similar to my proposals in [2] are 

Issue 3: In 6.4.3 (Calculating a selector's specificity):

   # * [...]
   # * count the number of ID attributes in the selector (= b)
   # * count the number of other attributes and pseudo-classes in the
   #   selector (= c)

This is intended to include instances of the "hash" (#) and "period" (.) 
notation, but even though 5.8.3 (Class selectors) says

   # Working with HTML, authors may use the period (.) notation as an
   # alternative to the ~= notation when representing the class
   # attribute. Thus, for HTML, div.value and div[class~=value] have the
   # same meaning.

it's not overly clear from the wording of 6.4.3 that such instances 
(which lack the explicit naming of an attribute) are to be counted.

Perhaps this could be made clearer.

Moreover, 6.4.3 goes on to say:

   # The specificity is based only on the form of the selector. In
   # particular, a selector of the form "[id=p33]" is counted as an
   # attribute selector (a=0, b=0, c=1, d=0), even if the id attribute
   # is defined as an "ID" in the source document's DTD.

which makes the wording of the second and third bullet points even more 
ambiguous; surely the second bullet point should say "ID selectors" 
rather than "ID attributes", in line with 5.9 (ID Selectors).  Likewise, 
perhaps its sufficient for the third bullet point to say "attribute 
selectors" rather than "other attributes" to address my concern, linking 
both "ID selectors" and "attribute selectors" back to the appropriate 
sections of Chapter 5.

[Note that an "attribute selector" or an "ID selector" forms part of – 
or, in Selectors Level 3, is – a "simple selector" which itself may form 
part of a "selector".  The terminology differentiation leaves a little 
bit to be desired!]

[1] http://wiki.csswg.org/spec/css2.1#issue-193
[2] http://lists.w3.org/Archives/Public/www-style/2011Jan/0073.html

Anton Prowse
Received on Friday, 7 January 2011 20:46:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:54 UTC