24028 2013-12-07 23:22:22 +0000 Element.matches("!invalid!") should throw DOMException "SyntaxError", not JavaScript TypeError 2014-06-03 10:27:58 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified PC All RESOLVED FIXED P2 normal --- 23367 1 philipj annevk crimsteam mike www-dom public-webapps-bugzilla oldest_to_newest 97284 0 philipj 2013-12-07 23:22:22 +0000 http://dom.spec.whatwg.org/#evaluate-a-selectors-string All tested *MatchesSelector() implementations throw a SyntaxError when parsing fails, but the spec requires TypeError. SyntaxError seems more reasonable here, so change the spec to match reality? 97326 1 annevk 2013-12-09 14:41:27 +0000 The reason behind using TypeError is that using DOMException is not actually favored by TC39 et al. And we still don't know what will happen to DOMException. See bug 23367. 97425 2 philipj 2013-12-10 22:43:28 +0000 What should happen to the gazillion places that already throw some kind of DOMException? I doubt that changing the exception type for some heavily used API will be Web compatible... 97429 3 annevk 2013-12-10 23:10:01 +0000 We'll have to sort that out. I was mostly trying to avoid it for new APIs. 97434 4 philipj 2013-12-10 23:43:21 +0000 Bug 23367 has very little context, can you explain what's going on here? It's not immediately obvious what the problem with DOMException is. 97446 5 annevk 2013-12-11 11:32:43 +0000 People from TC39 have argued we should have less exceptions and use JavaScript exceptions when applicable (as we already do at the binding level). And they have argued that e.name should equal the name of e's interface (not the case for DOMException at the moment). 106644 6 annevk 2014-05-22 13:38:37 +0000 Okay, I admit defeat. New APIs can do this, but if someone wants to change old APIs they have to convince implementers themselves. https://github.com/whatwg/dom/commit/39c292711896215afea75e1f4bbce601321d6011 107153 7 crimsteam 2014-06-02 19:09:36 +0000 If you changed matches() then what about querySelector() and querySelectorAll()? This methods are older than matches(), but still in "scope-match a selectors string " algo we have: 2. If s is failure, throw a JavaScript TypeError. Firefox, Chrome and IE return SyntaxError (query() and queryAll() still not supported so skipping them). This behaviour is correct per Selectors API Level 1/Selectors API Level 2: http://www.w3.org/TR/selectors-api/#parse-a-selector http://dev.w3.org/2006/webapi/selectors-api2/#parse-a-selector so really any implementators wants/plans change this? Similar for MutationObserver.observe(), but in this case we have something news, and at least Chrome throw TypeError, so maybe in future other browsers do the same. 107177 8 annevk 2014-06-03 06:00:09 +0000 Could you please file a separate bug? 107191 9 crimsteam 2014-06-03 10:26:39 +0000 (In reply to Anne from comment #8) > Could you please file a separate bug? https://www.w3.org/Bugs/Public/show_bug.cgi?id=25958