- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 14 Feb 2008 10:58:34 -0600
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- CC: public-webapi@w3.org
Lachlan Hunt wrote: >> * It's not clear what it means for a group of selectors to be >> "invalid". Does the term mean that the group of selectors is not >> tokenizable according to the CSS grammar? Or that there are >> unrecognized simple selectors or combinators in the group? Or both? >> How should vendor extensions to CSS be handled? > > 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? >> * Is there any requirement that the same Selectors implementation be >> used for both the implementation of this API and for CSS if the user >> agent implements both? If there is, that needs to be stated; if not, >> it may be worth saying so. Not sure whether this belongs in this >> section, but it came to mind when thinking about what it means for a >> selector to be "invalid". > > I do not believe specific implementation details such as that belong in > the specification. 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. Other than the two replies in this mail, and pending resolution of the still-unresolved issues, I'm completely satisfied with the changes. Thank you! -Boris
Received on Thursday, 14 February 2008 16:58:43 UTC