- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 10 Apr 2008 00:09:45 -0500
- To: Garrett Smith <dhtmlkitchen@gmail.com>
- CC: www-style@w3.org, "Web APIs WG (public)" <public-webapi@w3.org>
[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:29 UTC