Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On 2012-06-18 11:06, Lachlan Hunt wrote: Since it seems there are no objections to the latter option, and a few people in favour of that, I've tentatively updated both drafts to reflect this. It now states: If the group of selectors include namespace prefixes that need to be resolved, the implementation must raise a SYNTAX_ERR exception http://dev.w3.org/2006/webapi/selectors-api/#resolving-namespaces http://dev.w3.org/2006/webapi/selectors-api2/#resolving-namespaces I have now updated the testsuite to reflect this change. http://dev.w3.org/2006/webapi/selectors-api-testsuite/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On Sun, 17 Jun 2012 13:10:11 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: 1. Explicitly undefine this case. That would not be my preference. 2. Spec IE9, Firefox13 and Opera12alpha's behavior Roughly speaking, the choice is an invalid token or '|' whichever comes first, but I'd note that in the corner case These are valid: |a *|a My proposed spec change: # If the group of selectors include namespace prefixes that need to # be resolved, the implementation must raise a NAMESPACE_ERR # exception. s/NAMESPACE_ERR/SYNTAX_ERR/ -- Simon Pieters Opera Software
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On 2012-06-18 04:29, Boris Zbarsky wrote: Consider how this is parsed in a depth-first recursive descent parser: a|b +, 1) The identifier a is scanned. This might be a tag name or a namespace; look at the next token. 2) The symbol '|' is scanned. Great. a was a namespace. Resolve it. And you're done. You have an error and bail out. You never even got to the '+'. This is a good reason not to strictly define one having precedence over the other. That leaves 2 options: Leaving it explicitly undefined (only mildly better than the current situation) or using only syntax error. Since it seems there are no objections to the latter option, and a few people in favour of that, I've tentatively updated both drafts to reflect this. It now states: If the group of selectors include namespace prefixes that need to be resolved, the implementation must raise a SYNTAX_ERR exception I also removed the note about non-namespace supporting implementations throwing a syntax error instead of a namespace error. http://dev.w3.org/2006/webapi/selectors-api/#resolving-namespaces http://dev.w3.org/2006/webapi/selectors-api2/#resolving-namespaces -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
Always throwing SyntaxError is probably better. Which reminds me, the specification needs to be updated for new-style exceptions.
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
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? -Boris
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On Jun 17, 2012, at 3:44 PM, Boris Zbarsky bzbar...@mit.edu wrote: Also probably incompatible with a depth-first recursive descent parser implementation. Are we sure we want to overconstrain implementations like that? Incompatible how?
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On Sun, Jun 17, 2012 at 4:43 PM, Boris Zbarsky bzbar...@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'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.
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
(12/06/17 21:33), Anne van Kesteren wrote: Always throwing SyntaxError is probably better. I have no opinion here besides that I think this should be well-defined. (12/06/17 21:50), Aryeh Gregor wrote: 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? Probably no. CSS itself treats namespace errors the same as syntax errors in stylesheets (right?), In the Selectors spec, in some sense, yes, but the spec didn't have to touch the JS stuff so I wouldn't rely on its insights into this. so it doesn't make sense to require Selectors APIs to distinguish them. As long as browsers are willing to change this old behavior, agreed. (By the way, another irrelevant editorial feedback: http://dev.w3.org/2006/webapi/selectors-api2/ 6.5 3-1 s/dom_relative_selectors_group/dom_selectors_group/ ) Cheers, Kenny
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On 2012-06-17 15:50, Aryeh Gregor wrote: On Sun, Jun 17, 2012 at 4:43 PM, Boris Zbarskybzbar...@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/
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On 6/17/12 9:50 AM, Anne van Kesteren wrote: On Jun 17, 2012, at 3:44 PM, Boris Zbarskybzbar...@mit.edu wrote: Also probably incompatible with a depth-first recursive descent parser implementation. Are we sure we want to overconstrain implementations like that? Incompatible how? Consider how this is parsed in a depth-first recursive descent parser: a|b +, 1) The identifier a is scanned. This might be a tag name or a namespace; look at the next token. 2) The symbol '|' is scanned. Great. a was a namespace. Resolve it. And you're done. You have an error and bail out. You never even got to the '+'. -Boris P.S. This is basically what the Gecko parser does, afaik. On the other hand, WebKit's parser is breadth-first, again as far as I know: it first breaks up the selector on ',', then tries to match the various bits against the relevant productions and only after that actually deals with the leaf parse nodes. Hence it actually sees the missing stuff after '+' error before it ever tries to figure out anything about a in there.
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On Mon, Jun 18, 2012 at 4:29 AM, Boris Zbarsky bzbar...@mit.edu wrote: And you're done. You have an error and bail out. Yeah, so I should have been more clear. My suggestion was to never throw a NamespaceError and just always use SyntaxError. That distinction has never made much sense. (Well I guess it might have somewhat when it was still theoretically possible to have a namespace-aware and non-namespace-aware DOM...) -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On 6/18/12 1:33 AM, Anne van Kesteren wrote: On Mon, Jun 18, 2012 at 4:29 AM, Boris Zbarskybzbar...@mit.edu wrote: And you're done. You have an error and bail out. Yeah, so I should have been more clear. My suggestion was to never throw a NamespaceError and just always use SyntaxError. Ah, ok. That would certainly be pretty easy. ;) -Boris
