This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24028 - Element.matches("!invalid!") should throw DOMException "SyntaxError", not JavaScript TypeError
Summary: Element.matches("!invalid!") should throw DOMException "SyntaxError", not Jav...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on: 23367
Blocks:
  Show dependency tree / graph
 
Reported: 2013-12-07 23:22 UTC by Philip Jägenstedt
Modified: 2014-06-03 10:27 UTC (History)
3 users (show)

See Also:

Attachments

Description Philip Jägenstedt 2013-12-07 23:22:22 UTC 
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?
Comment 1 Anne 2013-12-09 14:41:27 UTC 
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.
Comment 2 Philip Jägenstedt 2013-12-10 22:43:28 UTC 
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...
Comment 3 Anne 2013-12-10 23:10:01 UTC 
We'll have to sort that out. I was mostly trying to avoid it for new APIs.
Comment 4 Philip Jägenstedt 2013-12-10 23:43:21 UTC 
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.
Comment 5 Anne 2013-12-11 11:32:43 UTC 
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).
Comment 6 Anne 2014-05-22 13:38:37 UTC 
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
Comment 7 Arkadiusz Michalski (Spirit) 2014-06-02 19:09:36 UTC 
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.
Comment 8 Anne 2014-06-03 06:00:09 UTC 
Could you please file a separate bug?
Comment 9 Arkadiusz Michalski (Spirit) 2014-06-03 10:26:39 UTC 
(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