Re: small selector syntax addition

fantasai wrote:
> 
> $ and :matches()

$ is this idea exactly equivalent to :subject and (...).

: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 #.

i.e.

    foo:matches($[baz] bar)

...becomes

    foo[baz]:matches(# bar)


>     - A $ in front of a simple selector sequence indicates the subject
>       of the selector. By default the last sequence is the subject.

This is unnecessary if you have my :matches().



>     Advantages:
> 
>        3. Can be used to to make almost any selector imaginable, so it won't
>           need to be extended with each subsequent vesion of the spec.

This isn't true. If you try to convert the selectors I gave in my last post, 
you'll see that there is at least one which your syntax cannot do.


>        4. Parsing and processing code for the main selector can be
>           reused to handle the :matches() argument.

I forgot to mention this as a plus point for mine.


>        6. A partial implementation of just $ will suffice for most needs.

I don't really understand this.


>        7. Reads better: .section > $div > code

    .section > div:has( > code)

I don't see that the dollar sign is any more understandable.


>           One can see the selector as mapping unbroken path through the
>           tree, branching only when selectors _need_ to branch off.
>               .section > :matches(h1,h2,h3,h4,h5,h6) + $div > code

I really don't understand what you mean by that. It sounds like an advantage 
which also applies to my suggestion, though.


You forgot the following disadvantages:

       1. Changes one of the basic concepts of CSS, that the subject of the
          selector is the last simple selector in the chain.

       2. Can only have one description on the right hand side, unless you use
          the :matches() form, at which point the dollar syntax is redundant.

       3. removes the potential use of a dollar sign from the language for
          future extensions.

       4. Ambiguous: what does it mean if there are two $s in a selector?

       5. Can't describe everything.


For completeness, here are some examples:

       /* select gardens in the village containing at least one pot plant */
       village $garden plant[type=pot]

       /* select gardens in the village containing at least one infected plant */
       village $garden plant > flea

       /* select gardens in the village containing at least two plants */
       village $garden plant ~ plant

       /* select gardens containing at least two infected plants */
       village $garden plant:matches($ > flea) ~ plant > flea

       /* select all plants that are before infected plants */
       $plant + plant > flea

       /* select all clean plants that are before infected plants */
       $plant:not(:matches($ > flea)) + plant > flea

       /* select all fleas if the document contains an antiflea element */
       /* can't be done */

Given that every useful [1] selector using this syntax can be algorithmically 
converted into one that uses my :matches() (this is true for all the proposed 
syntaxes, in fact), I don't see the advantage of this proposal.


-- Footnotes --
[1] this proposal allows for impossible selectors which are not possible using 
my :matches() form. For example:

    $foo:matches($bar)

...can never match. These cannot be converted to the :matches() form.

-- 
Ian Hickson
``The inability of a user agent to implement part of this specification due to
the limitations of a particular device (e.g., non interactive user agents will
probably not implement dynamic pseudo-classes because they make no sense
without interactivity) does not imply non-conformance.'' -- Selectors, Sec13

Received on Friday, 3 May 2002 20:55:17 UTC