- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 06 May 2002 02:32:01 +0100
- To: fantasai <fantasai@escape.com>
- CC: www-style@w3.org
fantasai wrote: > 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. :) Ok, in that case I am very confused. Your comment ("in the syntax I describe that would match exactly nothing") doesn't seem relevant, since I didn't say that my old :matches() was equivalent to your :matches(), I said the opposite (your :matches() was equivalent to my old :matches() after some algorithmic changes). >> 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. It doesn't complicate parsing that much. If your sequence of simple selectors consists of exactly '#' then you have the special symbol, otherwise '#' will mean the start of an ID. Considering how trivial that is, I don't think it's worth using a whole other symbol. Also, the '#' symbol makes more sense to me... it's like an anonymous ID, if you see what I mean. It conveys to me that this is something important. The '$' symbol doesn't really convey anything to me, except maybe something to do with sections (BCPL used $(...$) as section markers, and I've been looking at BCPL recently...). I just noticed that the '#' character also looks like a placeholder more than a '$' character -- compare: A:matches(B + # + C) A:matches(B + $ + C) >> 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. Where else does it say how to handle a '#' somewhere other than at the end? >> 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, Selectors have lots of redundancy, that's not a big problem. For example, '2n+1' and 'odd' mean the same thing, and ':first-child' is the same as ':nth-child(1)'. This is a feature, not a bug. It means that the simplest cases are the simplest to write. > 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. Read the "+" combinator as "sibling" and it reads as "an A, which has sibling B", just like A.B reads as "an A, whose class is B". I think it looks better than A:matches(# + B). Also, the most common case of looking for descendant doesn't appear to have a hanging combinator: p:has(strong) -- 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 Sunday, 5 May 2002 21:32:05 UTC