Re: Pseudo-classes and -elements

On Tue, 9 Apr 1996 17:42:53 +0200, you wrote:

>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:
>  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
>  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]       { .. }

Is there material on CSS2 available?

I still think that having something like the reserved name indicator
(RNI) in SGML would be useful. (Explanation: The RNI in SGML is
normally the character '#', which is used to distinguish 'keywords'
from element names. Thus, the content model '(#PCDATA)' specifies an
element with data content, while '(PCDATA)' is an element containing
another element named PCDATA.)

Why would this be useful? For instance, in a general SGML document,
what would 'REF [link]' mean? Element REF with an attribute named
'link' or the pseudo-attribute 'link'?

If we used '!' to indicate special names, this would be consistent
with the usage of '!' together with 'legal' and 'important' (see my
post on 'legal' and 'inportant').

> > 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?

Using the colon for child-relationship was because this would be
consistent with the current usage of pseudo-elements (they can be
considered childs).

For SGML output conversions in general, it is quite easy and in may
cases sufficient to use only relations which can be determined using
the open element stack (i.e. child-, descendant-, parent- and

Implementing sibling-relationships requires (in general) to keep a
considerable portion of the document 'tree' in memory.

And in many cases, it is not really needed. One rather needs to know,
wether an element has a left sibling or not, i.e. wether the element
is the first child of it's parent. A pseudo-attribute 'first-child'
would be sufficient for this purpose.

To wrap it up, I would ask for opinions/comments on the following

Notation:	Meaning:

A : B		Element B is child of element A
A : !B		Pseudo-element B is child of element A
A !B		Pseudo-element B is descendant of element A
A B		Element B is descendant of element A
A[!B]		Element A has pseudo-attribute B set (CSS2)
A+B		Shorthand for A[!B]
A[B]		Element A has attribute B set (CSS2)
A[B=C]		Element A has attribute B with value C 
		(set or implied) (CSS2)
A[!first-child]	A is first-child of it's parent  (CSS2)
A+first-child	A is first-child of it's parent
Furthermore, I would propose the introduction of a new pseudo-element
'!pcdata' denoting data-content within an element. Using this, one
could specify formatting for data within an element. Example:

P : !pcdata { ... }

would give formatting instructions for data within paragraphs, which
would not be inherited by element content of P (e.g. <EM>, <B>, etc.).


Wolfgang Rieger

Buero fuer Software-Entwicklung           Email: rieger@bse.de
                                          WWW  : http://www.bse.de/
Rosenheimer Str. 214                      Phone: +49 89 497738	
81669 Munich, Germany                     Fax  : +49 89 497738