Re: [SelectorsAPI] Selector detection needed?

Nicholas C. Zakas wrote:
> Browsers don't typically throw syntax
> errors when they run into selectors that aren't supported, they
> usually ignore them.

Yes, but the querySelector specification requires them to throw a syntax 
error in this situation.  It's pretty easy to implement this part, for 
what it's worth.

> I don't want to have to wrap every call to querySelector() or
> querySelectorAll() in a try-catch that adds overhead and unnecessary
> complexity.

To be honest, I don't see how it adds more overhead or complexity than a 
isSelectorSupported() call or whatever....  Am I missing something?

> I believe some way to query the support level for a
> selector is much more elegant solution.

To be honest, I'm not sure it is...

> The selector set is finite

Yes.  So is the set of documents on the web.  The problem is that it's 
not fixed, so adding constants to represent selectors means having to 
keep changing the specification every time new selectors are added.  It 
also means changing the specification every time new ways to combine 
existing selectors are added.

For any solution you propose here, please think about how it would 
handle the ":not(.foo.bar)" selector.

> I also don't see why I should have to try a
> complete CSS query when all I really want to know is if the given
> selector is supported.

What are the use cases for asking this question?  So far there has been 
only one use case proposed: having a page that outputs the "support 
status" of a browser.  Do you have others in mind?

> Throwing errors makes it difficult to determine if there was an
> actual syntax error because the CSS query was mistyped or if it's the
> browser not supporting something.

A CSS parser can't really tell those two cases apart in any case.  It 
might be a typo, or it might be a CSS feature that's not supported yet. 
  There's really no way to tell.  So the behavior of the UA will be the 
same in both cases: either throw for both, or silently return an empty 
list or null element pointer for both.  Throwing is vastly preferable to 
silently returning data that can be safely assumed to not be what the 
caller wanted.

-Boris

Received on Wednesday, 9 April 2008 04:50:51 UTC