Re: [SelectorsAPI] Selector detection needed?

On Tue, Apr 8, 2008 at 9:49 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
>  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.

The point of debate seems to be whether or not throwing an error is
really a Good Idea.


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

Yeah. It makes code messy.

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


You're mentioning extensibility, and I think that's a great point.

A new selector might be added in the future.

Having a string as the argument makes this easy.

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

A combined class selector, negated.

I would probably assume that to mean "not both".

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

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

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

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

SupportedQuerySelectors = (function(){
  var node = document.createElement("div");
  function supportsSelector( prefix ) {
    try {
      node.querySelector(s, function(prefix){return"ns";});
    }
    catch (e) { return false; }
    return true;
  }

  return {
    NOT : supportsSelector(":not(.x)")
  };
})();

A table of constants is not on the QuerySelector's interface, but
instead in implementation code.

If a table of constants on the QuerySelector interface is bad, a table
on the implementing code seems bad, too. Plus it's more code that has
to be maintained. It also has to be downloaded over http. Granted,
capability checks are often necessary anyway (WRT browser bugs), but
they are kind of a pain. It would be nice to have a contract for
support other than error.

OTOH, supporting a separated table of constants is undesirable because
it requires extra maintenance.

How about a query?

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

q.execute();

Prepared query and command might also be useful.

q.executeCommand( function reverseOrder(node) {
node.parentNode.insertBefore(node.parentNode.lastChild); } );


>
> > 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 Thursday, 10 April 2008 04:14:15 UTC