Re: [SelectorsAPI] Selector detection needed?

[ccing the right list for this, and setting reply-to]
Garrett Smith wrote:
> The point of debate seems to be whether or not throwing an error is
> really a Good Idea.

No, the point of this "debate" is whether there needs to be a separate API for 
determining "selector support status", and if so why and what it should look like.

> Yeah. It makes code messy.

That's a subjective judgment at best.

But even if we accept that, |if| statements make code messy.

> Having a string as the argument makes this easy.

Agreed.

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

You clearly missed the point of my question.  Note that your "a string as the 
argument" suggestion answers the question I was asking here.

> Wrapping each call in a try catch makes the code ugly.

So does wrapping them in "if()".

> Having the API throw an error makes it hard to know if an error
> actually occurred, or if the selector is not supported.

Not if the errors are different for those cases, as they are here.

> Capability detection functions can be run with results stored in a
> table (Library).

Yes...  That's the case no matter how the support detection is done.

> If a table of constants on the QuerySelector interface is bad, a table
> on the implementing code seems bad, too.

Agreed.  Nowhere did I propose this as a good idea.

> try {
>   var q = node.createQuery("div.pane > .items");
> } catch(ex) {
>   // Instantiate a hand-rolled object to do the query.
> )

This is an interesting idea, for what it's worth.  It makes the simple case 
(using a selector that any sane UA supports) more complicated, though, so I'm 
not sure it's the right way to go.

-Boris

Received on Thursday, 10 April 2008 05:10:30 UTC