W3C home > Mailing lists > Public > public-webapi@w3.org > February 2008

Re: [selectors-api] Selectors API comments: section 2

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 14 Feb 2008 10:58:34 -0600
Message-ID: <47B4733A.6080109@mit.edu>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 14 February 2008 16:58:44 GMT