Re: Why no Parent Selector?

--- Ian Hickson <py8ieh@bath.ac.uk> wrote:
> 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.
A pseudo-class is what you define it as, since it
doesn't exist except as a CSS concept.

IMHO, pseudo-classes select entire elements, but
pseudo-elements select only part of them.
> 
> (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.
1. I don't see why we should be stuck with narrow CSS
1 and 2 definitions of selectors.

2. It is no more or less a selector than :active.
In addition in (for example) P:subject IMG, there is
one selector and two simple selectors - :subject is
not a selector, and as such it contravenes the
selector syntax no more than P:hover IMG does.

> (Effectively it has [AFAICT] opposite
> restrictions to
> pseudo-elements.) 
Actually not, since pseudo-elements are only allowed
on the subject of the selector, and :subject is also
(obviously) allowed on the subject of the selector.

> 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].
I think the only legacy browser that would have
problems is IE 3, which has a tiny and thankfully
shrinking market share, but if you can illustrate an
example that other browsers wouldn't allow, then
please do.
 
> Further, it reverses the established convention that
> selectors match
> the simple selector element in a selector chain.

I don't quite see what you mean here, I presume you
mean that the simple selector is the last thing in a
selector chain, but this is wrong - a selector is any
number of simple_selectors separated by combinators -
P IMG has to simple selectors, separated, as all
simple_selectors are, by a combinator (white space -
the descendant combinator), and P:subject IMG also has
two simple selectors, P:subjecct and IMG, and the
selector matches (one of) the simple_selectors.

> 
> 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 ? */
X:subject Y ^ X, X:subject X ^ Y, where ^ is the
follows (in the sense of opening tag (you could also
have follows in the sense of element: follows- ¬; this
might be better for this example) [arguably only the
element follows combinator is needed] (you could have
before combinators, but !¬ = not after = before)
>    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 ? */
x (y ^ z), x (z ^ y) [note the brackets - x y ^ z
seems to match:
<x>
<y />
</x>
<z />
]
>    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 ? */
Not terribly easy to understand this one (a problem
with this method as a whole).

However, (a c:subject ~ d) ~ b
>    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, 
There are more important things that people get
confused about in CSS, such as the disgraceful state
of the float section, and the generally difficult to
understand nature of many sections.

Anyway, any confusion is unimportant, except to a
purist who insists that the author must have full
understanding of subtle and usually irrelevant (to the
author) distinctions.

In addition, I can't see any significant confusion -
no -one is going to get confused about what
:first-letter does, nor will they confuse :active

> 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, 
We could, but there is really no point. The colon
looks more elegant anyway.
> 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).
And even in that buggily.
> 
> [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...
:contains seems a better name.

=====
----------------------------------------------------------
From Matthew Brealey (http://members.tripod.co.uk/lawnet (for law)or http://members.tripod.co.uk/lawnet/WEBFRAME.HTM (for CSS))
__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

Received on Wednesday, 1 December 1999 06:30:55 UTC