Re: [SelectorsAPI] Selector detection needed?

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

The try-catch statement does carry overhead with it in terms of an additional scope. If you're doing a bunch of queries and you need to surround each of them with a try-catch, it can affect performance (see http://dev.opera.com/articles/view/efficient-javascript/?page=2). 

Errors should be thrown only for things that aren't easily detectable beforehand. This seems like something that should be easy enough to detect ahead of time such that throwing an error is too heavy-handed a way to deal with it. Not supporting a selector is not the same as a syntax error.

>>>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.

Again, you're focusing in on the specific solution. I already said that I suggested it to spur some conversation. I'm sure there could be something more elegant. The DOM has tons of different ways to determine what is implemented and possible to use. 

>>>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.

An unsupported selector doesn't necessarily break CSS syntax. Consider that :after and :hover match the same pattern. 

>>>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?

A support status page could be useful, but I'm thinking more practical. How can a JavaScript library that currently supports CSS querying determine if it should use its implementation or the browser one? Again, writing a try-catch around every call adds performance overhead and doesn't really seem optimal for every query. Since CSS queries are the basis of libraries like jQuery, you're talking a performance hit on every DOM access point. Always defaulting to the library's implementation clearly isn't optimal, but always using the browser's one doesn't guarantee everything will work. With some way to detect the capabilities of the query engine, a JS library could determine up front whether or not to use the browser-native version. Okay, if the browser supports X, and Y, and Z, then I'll default to using that, otherwise I won't. It could be something as simple as:

    var goodEnough = document.querySelectorSupport(":hover", ":not", ".a.b", "tagname", "#id");

In this paradigm, you can pass in a string representing each selector to test, with special ones for single class names (.a), multiple (.a.b, .a.b.c, etc.), tag names (tagname), IDs (#id).

-Nicholas

----- Original Message ----
From: Boris Zbarsky <bzbarsky@MIT.EDU>
To: Nicholas C. Zakas <html@nczonline.net>
Cc: www-style@w3.org
Sent: Tuesday, April 8, 2008 9:49:59 PM
Subject: 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

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Received on Thursday, 10 April 2008 04:24:51 UTC