[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
