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

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.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/39