W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Sun, 17 Jun 2012 18:46:56 +0200
Message-ID: <4FDE0A00.6090204@lachy.id.au>
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
Received on Sunday, 17 June 2012 16:47:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:34 UTC