- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Sun, 17 Jun 2012 18:46:56 +0200
- To: Aryeh Gregor <ayg@aryeh.name>
- CC: Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
On 2012-06-17 15:50, Aryeh Gregor wrote: > On Sun, Jun 17, 2012 at 4:43 PM, Boris Zbarsky<bzbarsky@mit.edu> wrote: >> On 6/17/12 9:33 AM, Anne van Kesteren wrote: >>> Always throwing SyntaxError is probably better. >> >> Also probably incompatible with a depth-first recursive descent parser >> implementation. Are we sure we want to overconstrain implementations like >> that? I don't know what this means. Could you clarify? > I'm not sure what Anne meant, but I'd think we should just always > require SyntaxError, including for namespace errors. Do enough people > really use namespaces that they deserve a separate exception? CSS > itself treats namespace errors the same as syntax errors in > stylesheets (right?), so it doesn't make sense to require Selectors > APIs to distinguish them. The distinction made sense when we were considering supporting namespaces, as it would help authors to diagnose mistakes. But looking at sizzle.js [1], it doesn't make a distinction between them at all. It just catches the error, ignores it and moves on. This may be one thing that could be changed without risk of breaking anything, since the lack of any namespace support means its unlikely that there are any scripts performing any special error handling for namespace errors that differs from other syntax errors. Is there any reason we should keep this distinction? [1] https://github.com/jquery/sizzle/blob/master/sizzle.js -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Received on Sunday, 17 June 2012 16:47:25 UTC