Re: small selector syntax addition

Ian Hickson wrote:
> 
> fantasai wrote:
>  > Ian Hickson wrote:
>  > > :matches() in this idea is exactly equivalent to :matches() in my
>  > > proposal, after moving any selectors associated with the subject
>  > > of the argument out to the level of the :matches() pseudo, and
>  > > replacing the subject with a #.
>  > You also wrote:
>  > >      /* select all fleas if the document contains an antiflea element */
>  > >      flea:matches(antiflea)
>  > which indicates otherwise, since in the syntax I describe that would
>  > match exactly nothing. They are not equivalent, they are merely
>  > similar.
> 
> Please reread exactly what I wrote. I stand by my original comment.

I did. I stand by my original reply. :)

>  >   Now, if I had a selector written like this:
>  >
>  >      .section > :matches(h1,h2,h3,h4,h5,h6) + $div > code
>  >
>  >   The <div> would be handed to the selector matching code, which
>  >   would then walk to the <div>'s previous sibling and send that to
>  >   be matched against :matches()'s argument, which, being a normal
>  >   selector with no additional rules, would be processed with the
>  >   same parsing and matching code as the main selector. It's pure
>  >   recursion. (If <div> matched against it's prior relations, the
>  >   function would then inspect its children for <code>.)
> 
> Right. But additional code would have to be added to the normal
> selector matching code to support $ and all it entails. So the same
> amount of new code needs to be written.

Well, if one takes the proposal I had replied to, yours would
require more code since you must be able to jump to the root and
scan for antiflea and other such acrobatics. But by treating both
the main selector and the :matches() argument exactly the same,
you have, as I said, pure recursion.

<differences of opinion>

> Look at the following selectors, and tell me how they should be
> interpreted. (Note that for each one, the $ could equally well be
> replaced by :subject or the (...) form, which are merely syntactic
> equivalents for the same thing.)

First:

"Pseudo-elements may only appear once in the sequence of simple
 selectors that represents the subjects of the selector."
    --http://www.w3.org/TR/2001/CR-css3-selectors-20011113/#pseudo-elements 
 
>     $h1 > $h1

Invalid, as I said before. Only one subject per selector.

>     $h1::after + h2

::after pseudo-element of an h1 immediately preceding an h2
 
>     $h1::first-line > span

::first-line pseudo-element of an h1 element with a span as child
 
>     $::before + ::after

Invalid, per CSS3 Selectors CR
 
>     $span * ::after

Invalid, per CSS3 Selectors CR


Excellent argument, btw.

> Taking your comments into account, here is an updated version of my
> proposal.
...
>      The special symbol '#' in the argument is a placeholder that
>      matches the node that the pseudo-class is being tested on. If it
>      is not used then the last sequence of simple selectors in the
>      selector chain has to match the element. In other words,

I don't like the use of # because it normally indicates the start
of an ID selector. It complicates parsing, both for the computer
and the person. I know you don't want to use up more symbols, but
I think in this case the benefit outweighs the advantage.

>      If the # form appears anywhere except the end of an argument, then
>      the document must be walked looking for matching elements.

This sentence is unnecessary.

>      The :has() pseudo-class is an alias for :matches(), as follows:
> 
>         :has(FOO1, FOO2, ..., FOOn)
> 
>      ...is exactly equivalent to
> 
>         :matches(# FOO1, # FOO2, ..., # FOOn)
> 
>      ...in terms of interpretation as a selector. Note that the FOOs
>      can start with a combinator, if they don't then the descendant
>      combinator is assumed. This is the same as the way we have 'odd'
>      and 'even' as equivalents to '2n+1' and '2n' for the :nth-child()
>      pseudo-classes. It makes the simple case simple.

I suggest you get rid of this :has(). It's redundant, and starting an
argument with a hanging combinator is, to me, far worse than using a
subject indicator in the main selector. A:has( + B) looks to me very
awkward--it's incomplete--and reading it doesn't make much sense,
either.

~fantasai

Received on Sunday, 5 May 2002 19:21:23 UTC