W3C home > Mailing lists > Public > www-style@w3.org > February 1998

Re: !CSS2WD ERROR! in pseudo-element rules

From: Ian Hickson <exxieh@bath.ac.uk>
Date: Wed, 25 Feb 1998 21:12:22 -0000
Message-ID: <003e01bd4233$38567f40$d020268a@hpxu>
To: www-style@w3.org
Bert said...
>The word "combined" is misleading. It refers to a style sheet like
>    P:before {content: "para: "}
>    P:first-letter {color: red}

Ok. the "p" should be red.

>Yes, I agree there are useful cases, but on the whole this leads to
>so many difficulties (in the specification as well as in the
>implementations) that we think this is not in the scope of CSS.

Why? Or rather, What difficulties?

Let's see. Imagine the following paragraph, which has the generated/inserted
text shown (note that the EM splits over the two lines, so has been cut by
the <:firstline> pseudo as described in the spec - nothing new, it was in

<P><:first-line><:before>inserted before, </:before>the
 paragraph</em> of text.</p>

Now consider the following selectors, all of which are currently classified
as illegal:

P :before :first-letter  -  also applies to the first letter the text ("i"
of "inserted") - as would "P :first-letter".
P :first-letter :before  -  applies to just before the first letter,
including any inserted text (just before "i" of "inserted").
P :before :before        -  also applies to just before the first letter,
including any inserted text (just before "i" of "inserted").
P :first-letter :after   -  applies to just after the first letter,
including any inserted text (just after "i" of "inserted").
P :first-line :after     -  applies to between the words "main" and "
paragraph" (note spaces).
P :before :after         -  applies to between the words "before, " and
P :first-line EM         -  applies to the word "main" (this is illegal
because pseudo is not last element)
("P EM :first-letter" is illegal since EM is not a block level element. This
condition does make sense - we don't want drop caps *inside* blocks of

As far as I can see, all of these are quite straightforward to interpret,
with maybe a slight problem with "P :first-line :after" - should any
inserted text be counted as part of the first-line? The answer, logically,
would be that the inserted text should be on the first-line, so that it
balances anything inserted :before the first-line. After all, the <:before>
in the code above is inside the <P>, so consistency would indicate that that
is correct.

Pseudo elements provide a lot of power to the style sheet writer. It is my
opinion that allowing these to be combined is no more complicated than
allowing it for all the other types of selectors, which *can* be combined.
Complexity should not scare us away from a comprehensive standard -
particularily since table support is being described (and very thouroughly

Daniel said:
>possible problems :
>1. In the quoted example, nothing tells us that the EM is *completely*
>included in P:first-line for instance....

So? This problem is already present with :first-line on it's own, and the
spec "solves" this quite clearly. See 5.10.1.

>2. pseudo-elements list may be extended in the future and promoting
>pseudos as normal elements in selectors could be a terrible problem.

Like...? And do these "terrible problems" overweigh the benefits?

BTW, The last selector in the list above, "P :first-line EM", is a very
important one for the same reason as I gave originally - the next rule
causes any EM text in the first line to be un-emphasised. This is plainly
bad; and CSS should allow us to make corrections for it (and hence my
suggestion that we drop the condition that pseduo-elements can only appear
at the end).

  P EM, P:first-line  { font-style: italic }

/* We "need" this rule to solve the problem, but it's not currently allowed!
  P:first-line EM     { font-style: normal } */

Ian Hickson
Version: 3.12
GIT/M/S d- s+: a--- C++(+++)>$ U P L+ !E W++ N++ o? K? w++>+++ O- !M V- PS+
PE- Y+ PGP t 5+++>++++ X- R+++ tv b++(+++) DI D++ G e-(*)>+++++ h!()(--) y?
Received on Wednesday, 25 February 1998 16:20:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:46 UTC