Re: Why no Parent Selector?

On Tue, 30 Nov 1999, Daniel Glazman wrote:

> The W3C Selectors Working Draft [1] [...] introduces the :subject
> selector. So selecting a P that contains a DEL is written
> 
> 	P:subject > DEL
> 
> [1] http://www.w3.org/TR/CSS3-selectors

I have a few concerns about the :subject selector.

Is it really a pseudo-class?

The draft spec suggests that it is, however that makes no sense. The
idea behind pseudo-classes is to have an effect similar to using the
class selector (.xxx) -- i.e., an element matches if and only if that
element matches a certain condition (e.g., cursor is above it, it is
the first element of its type amongst its siblings, one of its
attributes has a certain value, etc...). However, the :subject
selector _always_ applies -- in fact, it has no relevance whatsoever
to matching the document tree, it merely changes the resulting meaning
of the complete selector.

(So maybe it is a pseudo-element? Again no. A pseudo-element matches
something that is not in the document tree, but :subject doesn't
particularly 'match' anything. [1])

However, even given that it is not a pseudo-class and that presumably
it could therefore have some other syntax, it is still Wrong: as a
_selector_, it should be selecting something -- but as mentioned
above, :subject does not match anything, it merely changes the
eventual interpretation of the selector chain.

Another problem is that [presumably?] :subject does not act like any
other CSS selector syntax -- it is allowed anywhere, but only once per
selector. (Effectively it has [AFAICT] opposite restrictions to
pseudo-elements.) If this is relaxed and used to allow brevity in
selectors, then this would be of limited use as it would break
backwards compatability, and so any rules using those selectors would
have uncertain effects on legacy browsers [2].

Further, it reverses the established convention that selectors match
the simple selector element in a selector chain.

Finally, it is not very versatile -- it is somewhat limited to acting
as a parent selector and as an inverse sibling selector, for which
much simpler syntaxes could be used, namely combinators such as "<"
and "-", and so on.

I would propose (again) that instead of :subject, we introduce a
function-like pseudo-class which matches an element if its argument,
treated as the rest of the selector, match. [3]

Examples are always the easiest way of explaining things, so:

1. As A Parent Selector

   Proposed syntax:  x:matches(> y)
   WD syntax:        x:subject > y
   matches:          <x MATCHED> <y/> </x>


2. As An Ancestor Selector

   Proposed syntax:  x:matches(y)
   WD syntax:        x:subject y
   matches:          <x MATCHED> <z> <y/> </z> </x>


3. Inverse Direct Adjacent Selector

   Proposed syntax:  x:matches(+ y)
   WD syntax:        x:subject + y
   matches:          <x MATCHED/> <y/>


4. Inverse Indirect Adjacent Selector

   Proposed syntax:  x:matches(~ y)
   WD syntax:        x:subject ~ y
   matches:          <x MATCHED/> <z/> <y/>

 
5. Selecting Elements Which Contain Certain Other Elements

   Proposed syntax:  x:matches(y):matches(z)
   WD syntax:        /* not possible ? */
   matches:          <x MATCHED> <b> <y/> </b> <a> <z/> </a> </x>


6. Selecting Elements Which Are In An Element Containing Another Element

   Proposed syntax:  x:matches(y) z
   WD syntax:        /* not possible ? */
   matches:          <x> <a> <y/> </a> <b> <z MATCHED/> </b> </x>


7. Selecting Elements Which Precede An Element And Have A Parent Which
Precedes Another Element

   Proposed syntax:  a:matches(~ b) > c:matches(~ d)
   WD syntax:        /* not possible ? */
   matches:          <a> <c MATCHED/> <z/> <d/> </a> <z/> <b/>



[1] BTW, I'm starting to think that we should possibly change the
syntax of pseudo-elements so that they are more distinguishable from
pseudo-classes than now. A lot of people seem unclear about the
fundamental difference between pseudo-classes and -elements, and I
think the fact that they have identical syntaxes is not helping the
situation. Maybe an equals sign or two colons would be ok:

   element=before { content: 'whatever' }
   element::before { content: 'whatever' }

We can still change this, because there are only four pseudo-elements
so far (first-line, first-letter, before, and after) and of those only
two are implemented In The Wild (and that in a relatively small-market
browser, namely Opera).

[2] Mainly because they are buggy and don't ignore unknown bits -- in
completely compliant browsers, the entire rule would be ignored. That
would mean that people would probably not use :subject as a shorthand
syntax anyhow, so the gain is minimal.

[3] For example:

   A:matches(B)

...would match A if 

   A B

...matched B.

Similarly, 

   A B:matches(C D) E

...would match E if

   A B C D

...matched D and

   A B E

...matched E, for the same B.

I'm sure someone else will find a better explanation...


-- 
Ian Hickson                         ("`-''-/").___..--''"`-._   
http://www.bath.ac.uk/%7Epy8ieh/     `6_ 6  )   `-.  (     ).`-.__.`)
                                     (_Y_.)'  ._   )  `._ `. ``-..-' fL
Member, Web Standards Project      _..`--'_..-_/  /--'_.' ,'
http://www.webstandards.org/      (il).-''  (li).'  ((!.-'

Received on Tuesday, 30 November 1999 16:36:21 UTC