[dom] matches, querySelector, etc. shouldn't throw on an unrecognized selector

appsforartists has just created a new issue for 
https://github.com/whatwg/dom:

== matches, querySelector, etc. shouldn't throw on an unrecognized 
selector ==
As the Web evolves, new selectors will be invented.  (The CSS4 wiki 
contains [14 selector 
proposals](https://wiki.csswg.org/spec/css4-ui#more-selectors).)  As 
that happens, there will be selectors that are understood by some 
browsers but not yet others.

The current spec commands that browsers [throw a 
SyntaxError](https://github.com/whatwg/dom/blob/b5bc2f7ec706d8c5b181dc90dfcd9605331de6c4/dom.bs#L2038-L2039)
 when they don't understand a selector.  Unless there is an actual 
syntax error (e.g. a mismatched paren), this should be handled more 
gracefully.  Otherwise, because errors halt JS execution, any site 
that adopts a new selector is going to break in old browsers unless 
the developer knew and remembered to wrap the statement in a 
`try/catch`.

This makes code both harder to read and harder to write without bugs.
  For instance, what should be this simple:

```javascript
var autofilled = node.matches(":autofill, :-webkit-autofill, 
:-moz-autofill");
````

becomes this mess:

```javascript 
var autofilled = false;

try {
  autofilled = node.matches(":autofill");

} catch (error) {                                      
  try {
    autofilled = node.matches(":-webkit-autofill");

  } catch (error) {                                      
    try {
      autofilled = node.matches(":-moz-autofill");

    } catch (error) {}
  }
}  
```

under the current spec.

The simplest solution would be to change the errors to warnings.  This
 would be a welcome change, though it would make it harder to 
programmatically distinguish between unmatched and unsupported 
selectors.  Perhaps a `navigator.supportsSelector` API should be added
 to make this differentiation easier.

Whatever the solution, throwing an error on an unsupported selector is
 hostile to the future of the web.  It should be fixed.

See https://github.com/whatwg/dom/issues/39

Received on Tuesday, 2 June 2015 05:36:20 UTC