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."
(The changes will appear in the draft next time I check it into CVS,
later this evening.)
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
