[CSS2.1] Selectors

Preceding Siblings
------------------

S5.1 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#q1>:
# E + F	  Matches any F element immediately preceded by an element E.

preceded by a _sibling_ element, you mean; E + F shouldn't match if
E is the parent of F.

Adjacent Elements
-----------------

S5.7<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#adjacent-selectors>:
# In some contexts, adjacent elements generate formatting objects
# whose presentation is handled automatically (e.g., collapsing
# vertical margins between adjacent boxes). The "+" selector
# allows authors to specify additional style to adjacent elements.

This paragraph is confusing and, imo, useless. Take it out.

Attribute Selectors
-------------------

S5.8<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#attribute-selectors>:
# CSS 2.1 allows authors to specify rules that match attributes
# defined in the source document.

Given the way "matches" is defined in section 5.1, this
sentence should be reworded. The selector doesn't match
the attribute, it matches the element *with* the attribute.

Default Attributes
------------------

S5.8.2<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#q11>
#    EXAMPLE { /*... default property settings ...*/ }
# Because this selector is less specific than an attribute
# selector, it will only be used for the default case.

This is false. The selector will be used for all cases,
not just the default case. If a declaration from this
rule conflicts with one from a more specific rule, then
it will be overridden--but the declaration still applies.

Class Selectors
---------------

S5.8.3<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#class-html>:
# 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. The attribute
# value must immediately follow the "period" (.). UAs may
# apply selectors using the period (.) notation in XML
# documents if the UA has namespace specific knowledge that
# allows it to determine which attribute is the "class"
# attribute for the respective namespace. One such example
# of namespace specific knowledge is the prose in the
# specification for a particular namespace (e.g. SVG 1.0
# [SVG10] describes the SVG "class" attribute and how a UA
# should interpret it, and similarly MathML 2.0 [MATH20]
# describes the MathML "class" attribute.)

The poor quality of the prose here aside (which I'll have
to address later), I think this paragraph would benefit
from a brief discussion of what a class /is/ conceptually,
not just syntactically.

Also, you need to make clear that an XML namespace may
choose as its class attribute an attribute with a name
other than "class".

# Note. CSS gives so much power to the "class" attribute,
# that authors could conceivably design their own "document
# language" based on elements with almost no associated
# presentation (such as DIV and SPAN in HTML) and assigning
# style information through the "class" attribute. Authors
# should avoid this practice since the structural elements
# of a document language often have recognized and accepted
# meanings and author-defined classes may not.

You tell authors here what not to do with classes. One
reads this warning, but then what? There's no advice on
what *to* do! Tantek's post "A Touch of Class" [1]
explains classes particularly well; adding a few key
points from that would turn this block into a more useful
redirect.

[1] http://tantek.com/log/2002/12.html#L20021216t2238

ID Selectors
------------

S5.9<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#class-html>:
# Document languages may contain attributes that are
# declared to be of type ID. What makes attributes of
# type ID special is that no two such attributes can
# have the same value; whatever the document language,
# an ID attribute can be used to uniquely identify its
# element...

Since CSS could conceivably be used for a non-SGML-based
document language, I suggest defining IDs as "unique
identifiers" first and relating them to type ID later.
Another advantage is that you start the definition with
generic English rather than specific code.

:first-child
------------

S5.11.1<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#first-child>:
# Note that since anonymous boxes are not part of the
# document tree, they are not counted when calculating
# the first child.

-Boxes- are never part of the document tree. You mean
to say that "non-element nodes" are not counted.

Link Pseudo-Classes
-------------------

S5.11.2<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#link-pseudo-classes>
# For example, in HTML 4.0, the link pseudo-classes apply
# to A elements with an "href" attribute.Thus, the
# following two CSS 2.1 declarations have similar effect:
#
#   a:link { color: red }
#   :link  { color: red }

This example seems a bit pointless. If it's got a point,
you need to point it out. Otherwise, take it out.

# Note. It is possible for stylesheet authors to abuse the
# :link and :visited pseudo-classes to determine which sites
# a user has visited without the user's consent. UAs may
# therefore treat all links as unvisited links, or implement
# other measures to preserve the user's privacy while
# rendering visited and unvisited links differently. See
# [P3P] for more information about handling privacy.

If you want to let UAs treat all links as unvisited, then
put that in the normative prose, not an informative note.
As for privacy concerns over :visited and :link, putting
that kind of a note in here seems like overkill to me.

Dynamic Pseudos
---------------

S5.11.3<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#dynamic-pseudo-classes>:
# Similarly, because A:active is placed after A:hover,
# the active color (lime) will apply when the user both
# activates and hovers over the A element.

will apply -> will take effect

# An element can be both ':visited' and ':active' (or
# ':link' and ':active') and the normal cascading rules
#  determine which properties apply.

which _style declarations_ apply

:first-line
-----------

This entire section takes the "fictional tag sequence" idea
a bit too literally. For example,

# the user agent could generate the appropriate start and
# end tags for SPAN when inserting the fictional tag
# sequence for :first-line.

No. You can't make the tags real, because then you wind up
with an obscure box model. Suppose, for example, I specify
span { border: 1px solid}. The border shouldn't indicate a
split in the span element at the end of the first line.

# The :first-line pseudo-element can only be attached to
# a block-level element.

elem            { display: block; }
elem:first-line { color: blue; }
elem.special    { display: inline; }

say what?

# A UA should act as if the fictional start tag of the
# first-line pseudo-element is just inside the smallest
# enclosing block-level element.

What do you mean, the "smallest enclosing block-level
element"?

If you're trying to say something about nesting (I'm
guessing based on the example), then *say* something
about nesting. E.g.
    :first-line pseudo-elements are nested in the
    same order as the elements themselves.

~fantasai

Received on Friday, 10 October 2003 20:54:12 UTC