Lachlan Hunt wrote:
Boris Zbarsky wrote:
Lachlan Hunt wrote:
The Selectors specification defines the conformance criteria for a
group of selectors, and thus an invalid selector is one that does not
conform to those requirements. I have updated the text to more
clearly refer to the conformance requirements in Selectors.
So if I read this correctly, the selector is "invalid" if the UA
doesn't know what to do with it (which is what Selectors specifies).
In particular, if I use, say, a -o-something selector supported by
Opera, Opera would not throw while other UAs would. Is that correct?
Yes.
Looking back at this, I didn't phrase my concern well. The real
question is whether the Selectors API implementation must support the
same set of selectors for both Selectors API and CSS matching,
assuming it does CSS at all. For example, a number of selectors are a
lot easier to implement for Selectors API than they are for CSS
matching, since Selectors API doesn't need to handle dynamic changes.
I can see several approaches here:
1) Implementations MUST support the same set of selectors for both
CSS matching
and Selectors API.
2) Implementations MUST support a superset of the selectors used for CSS
matching in Selectors API (possibly with a SHOULD that the sets
should be
the same?).
3) Say nothing or explicitly let UAs do whatever they want in this
regard.
The current spec does #3. While I don't have a problem with that per
se, I just wanted to check that this is really what is desired.
I have added the following text to the spec:
"If the user agent also supports some level of CSS, the implementation
must support the same set of selectors that are supported by the CSS
implementation."
This doesn't really make it clear if that is 1 or 2 above. In both cases
the same set of selectors are supported, but for 2 the selectors-api
implementation is allowed to implement additional selectors.
/ Jonas
