Re: Why no Parent Selector?

On Wed, 1 Dec 1999, Daniel Glazman wrote:

>> Is [:subject] really a pseudo-class?
> You are right. It is not IMHO opinion a pseudo-class. It only has to
> deal with CSS parsing of selectors. And that's why the original
> version of STTS3 was using a completely different syntax : the
> subject of the selector was indicated by a leading descriptor "!".

A leading "!" would probably be confused with negation, but assuming
that some other syntax could be used, that would indeed solve this
particular problem.


>> [It is not a _selector_ either]
> Agreed. That's why I used the "descriptor" word in STTS original
> version.

That would be much better. If a mutated form of ":subject" makes it
into the final spec, I would **VERY** strongly recommend that it not
be called a selector.

 
>> Another problem is that [presumably?] :subject does not act like any
>> other CSS selector syntax -- it is allowed anywhere, but only once per
>> selector.
> I can't get your point here. Can you explain that ?

Yes, but note that this is a very weak and trivial argument that can
be safely ignored:

 This is a similar problem to the fact that ":subject" reverses
 established convention of the last selector in a selector chain being
 the one that matches: people are used to one thing, and ":subject"
 changes the rules. When teaching CSS1, for example, one can mention
 all the properties, and in general one can simply omit to mention the
 CSS2 properties and the course will simply be a subset of the CSS2
 course. However, if one says "a declaration block applies to the last
 selector in the chain", then this will actually be _wrong_ when it
 comes to teaching CSS3 if ":subject" survives. People teaching CSS1
 would have to take CSS3 into account if they are to stay accurate.

 With CSS1, one can say "pseudo-classes are allowed anywhere in
 selectors, pseudo-elements are allowed only at the end of the chain".
 But if ":subject" is introduced then one would have to add "except
 for ":subject", which we will mention in the CSS3 course". (This
 would not be so much of an issue if ":subject"'s syntax was fixed.)

Ok, end of section that can be safely ignored. :-)


>> 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.
> "-" cannot be used for parsing reasons. Anyway, I don't think that
> using a special combinator is a good idea.

Why? That is all that :subject is actually doing, no?

Is there anything that :subject can do which cannot be done by the
more conventional idea of combinators?

 
>> 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.
> Ian, this approach is interesting but complex.

When used at the end of the selector chain it has _exactly_ the same
power as the ":subject" pseudo-...., err, thing.

If complexity is an issue, then it can be introduced in CSS3 as being
only valid at the end of a selector chain, and then this has exactly
the same result as ":subject" except that it can be easily extended to
cover _many_ more situations in CSS4, simply by removing the
restriction.


> CSS has a great thing that I really (personal opinion) don't want to
> break: human readability. I think that your proposal reduces a lot
> readability.

I beg to differ. Possibly the name could be changed, this would
improve the readability a great deal:

   tree:contains(fruit)

This is more readable, IMHO, than:

   tree:subject fruit

Similarly, 

   bowl:contains(apple):contains(pear)

...is distinctly more readable than

   bowl:subject apple ~ fruit, bowl:subject fruit ~ apple

The only problem with calling the pseudo-class ":contains" is that it
does not do justice to the total power of the proposal:

   alice:contains(+ bob)

...is not quite what is meant (since it matches an "alice" element
which immediately precedes a "bob" element, and does not involve
containership at all).

This, BTW, would be equivalent to the WD syntax:

   alice:subject + bob

While I'm writing examples:

   bowl:contains(fish) + cat:before { content: '*grin*' }

Still readable IMHO, and not possible using the ":subject" thing.


> I'll leave browser vendors express their opinions but I also think
> there are implementation (parsing) concerns (data between
> parenthesis are not a selector, just a part of selector).

I am not a CSS implementor, but from my programming experience I would
assume that the argument could "simply" be parsed by recursively
calling the selector parsing code.

For the matching side of the implementation, the restricted version of
":matches" would in fact be identical to the full potential of
:subject and so should not be a problem either.

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

Received on Wednesday, 1 December 1999 09:40:01 UTC