Pseudo-classes and -elements

Wolfgang Rieger writes:

 > Further, there is a semantic distinction between pseudo-classes and
 > pseudo-elements (pseudo-classes are more like attributes while 
 > pseudo-elements are more like elements). IMHO there should be
 > a formal distinction between the two constructs. Otherwise (as I
 > have noted in recent postings) pseudo-classes and pseudo-elements
 > will be confused.

Good point. Let's find two characters -- here are some suggestions:

Pseudo-elements:

  H1/first-line
  H1/first-letter

  H1+first-letter
  H1+first-line

  H1~first-letter   /* mnemonic: tilde ressembles an 's' as in "H1's first-letter" */
  H1~first-line

Pseudo-classes:

  A+visited
  A+active
  A+link

  A!visited
  A!active
  A!link

  A?visited
  A?active
  A?link

What do people think?

 > I'm currently thinking about how to interpret style sheets for
 > arbitrary SGML documents with arbitrary DTDs. For this purpose, I
 > think it necessary to allow selection of elements via attribute 
 > values.

Yes this is scheduled for CSS2 (or whatever it will be called):

 H1[class=funk] { .. }
 A [HREF]       { .. }


 > if you change the meaning of the colon-notation "A : B" from "B is
 > pseudo-element in A" to "B is child of A" (i.e. direct descendant), 
 > you are compatible with existing implementations and have a 
 > consistent extension of the selector syntax.

Another very good point. A slightly different angle of attack: now
that the colon is freed up, how can we make best use of it? HTML
documents are rather flat, and we may have more need to look for
predecessor relationships (i.e. immediate sibling) than parent-child
relationships. So:

  H1 : P { .. } 

could address P elements immediately following H1 elements.

For SGML in general, this may not hold?

Regards,

-h&kon

Hakon W Lie, W3C/INRIA, Sophia-Antipolis, France
http://www.w3.org/people/howcome  howcome@w3.org

Received on Tuesday, 9 April 1996 11:43:51 UTC