[selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
The spec (either Level 1 or Level 2) is unclear about which error should be raised in a situation when both NAMESAPCE_ERR and SYNTAX_ERR apply, and this is not the same in all browsers. That is, for a selector like a|b + or a|b, + IE9, Firefox 13 and Opera12alpha raise NAMESAPCE_ERR, while Chrome19 raises SYNTAX_ERR. Two proposed solutions (sorted by my preference): 1. Explicitly undefine this case. I don't think having interoperability on this is of big importance, but in general having an explicit undefined is usually better than an implicit one. Proposed text: change # If the group of selectors include namespace prefixes that need to # be resolved, the implementation must raise a NAMESPACE_ERR # exception. to | If the group of selectors include namespace prefixes that need to | be resolved and match either dom_selectors_group or | dom_relative_selectors_group, the implementation must raise a | NAMESPACE_ERR exception. If the group of selectors include | namespace prefixes that need to be resolved and /doesn't/ match | either dom_selectors_group or dom_relative_selectors_group, the | implementation must raise either a NAMESPACE_ERR exception or a | SYNTAX_ERR exception. The exact choice is undefined. 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 a| Firefox13 and Oper12alpha raise NAMESPACE_ERR but IE9 raises SYNTAX_ERR. Cheers, Kenny
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein rafa...@google.com wrote: I too thought we had intentionally spec'd them to not fire during load. The HTML spec is clear about this WRT Mutation Events: http://www.whatwg.org/specs/web-apps/current-work/#tree-construction: DOM mutation events must not fire for changes caused by the UA parsing the document. (Conceptually, the parser is not mutating the DOM, it is constructing it.) This includes the parsing of any content inserted using document.write() and document.writeln() calls. It seems like this should also apply to Mutation Observers, unless we have compelling reasons to do otherwise. This was something that we got people complaining about with mutation events over the years. Our answer used to be that mutation events generally suck and you can't depend on them anyway. Obviously not an argument we'd want to use for MutationObservers. I can't think of any cases where you would *not* want these to fire for parser mutations. For example if you are building an XBL-like widget library which uses the DOM under a node to affect behavior or rendering of some other object. If you attach the widget before the node is fully parsed you still need to know about modifications that happen due to parsing. If you are tracking all nodes which has a particular class name or element name (for example to attach behavior to them, or as a performance improvement in order to keep a live list of nodes matching a selector) then you need to know about mutations that the parser performed. Also, if changing code from using document.write to using .insertAdjecentHTML or other DOM features, why should that change whether observers are notified? Are there use cases for *not* wanting to know about parser mutations, but still know about script-initiated mutations? What about situations when a node is moved around and so that parser ends up inserting nodes not at the end of the document? I.e. if a node A is done parsing, but then an ancestor B of the current parser insertion point is moved to become a child of A, which causes the parser to again mutate A's descendants. / Jonas
Re: Browser Payments API proposal
On 6/16/12 8:16 PM, ext Alex MacCaw wrote: The blog article link has changed to: http://blog.alexmaccaw.com/preview/Pc1LYBw4xDT95OPWZGihod7z8WhrnfAdXMjQxMDg3MTc5NDIaXNjA1p Alex - perhaps this API will be of interest to the Web Payments Community Group http://www.w3.org/community/webpayments/. -AB
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: Should MutationObservers be able to observe work done by the HTML parser?
On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking jo...@sicking.cc wrote: On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein rafa...@google.com wrote: I too thought we had intentionally spec'd them to not fire during load. The HTML spec is clear about this WRT Mutation Events: http://www.whatwg.org/specs/web-apps/current-work/#tree-construction: DOM mutation events must not fire for changes caused by the UA parsing the document. (Conceptually, the parser is not mutating the DOM, it is constructing it.) This includes the parsing of any content inserted using document.write() and document.writeln() calls. It seems like this should also apply to Mutation Observers, unless we have compelling reasons to do otherwise. This was something that we got people complaining about with mutation events over the years. Our answer used to be that mutation events generally suck and you can't depend on them anyway. Obviously not an argument we'd want to use for MutationObservers. I can't think of any cases where you would *not* want these to fire for parser mutations. Agreed. I'm in favor of observers being notified for parser-initiated DOM mutations. The primary reason we don't fire mutation events for parser insertion removal is because they're synchronous and introduces all sorts of problems including security vulnerabilities but that isn't the case with mutation observers. One question. Should we also notify mutation observers immediately before executing synchronous scripts (i.e. script elements without differ or async content attributes) to address Mihai's use case? - Ryosuke
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: Should MutationObservers be able to observe work done by the HTML parser?
On 06/17/2012 03:03 PM, Jonas Sicking wrote: On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein rafa...@google.com wrote: I too thought we had intentionally spec'd them to not fire during load. The HTML spec is clear about this WRT Mutation Events: http://www.whatwg.org/specs/web-apps/current-work/#tree-construction: DOM mutation events must not fire for changes caused by the UA parsing the document. (Conceptually, the parser is not mutating the DOM, it is constructing it.) This includes the parsing of any content inserted using document.write() and document.writeln() calls. It seems like this should also apply to Mutation Observers, unless we have compelling reasons to do otherwise. This was something that we got people complaining about with mutation events over the years. Our answer used to be that mutation events generally suck and you can't depend on them anyway. Obviously not an argument we'd want to use for MutationObservers. I can't think of any cases where you would *not* want these to fire for parser mutations. I agree. Better to try to keep the API consistent and create mutation records for all the mutations. For example if you are building an XBL-like widget library which uses the DOM under a node to affect behavior or rendering of some other object. If you attach the widget before the node is fully parsed you still need to know about modifications that happen due to parsing. If you are tracking all nodes which has a particular class name or element name (for example to attach behavior to them, or as a performance improvement in order to keep a live list of nodes matching a selector) then you need to know about mutations that the parser performed. Also, if changing code from using document.write to using .insertAdjecentHTML or other DOM features, why should that change whether observers are notified? Are there use cases for *not* wanting to know about parser mutations, but still know about script-initiated mutations? What about situations when a node is moved around and so that parser ends up inserting nodes not at the end of the document? I.e. if a node A is done parsing, but then an ancestor B of the current parser insertion point is moved to become a child of A, which causes the parser to again mutate A's descendants. / Jonas
Re: Should MutationObservers be able to observe work done by the HTML parser?
On 06/17/2012 10:17 PM, Ryosuke Niwa wrote: On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking jo...@sicking.cc mailto:jo...@sicking.cc wrote: On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein rafa...@google.com mailto:rafa...@google.com wrote: I too thought we had intentionally spec'd them to not fire during load. The HTML spec is clear about this WRT Mutation Events: http://www.whatwg.org/specs/web-apps/current-work/#tree-construction: DOM mutation events must not fire for changes caused by the UA parsing the document. (Conceptually, the parser is not mutating the DOM, it is constructing it.) This includes the parsing of any content inserted using document.write() and document.writeln() calls. It seems like this should also apply to Mutation Observers, unless we have compelling reasons to do otherwise. This was something that we got people complaining about with mutation events over the years. Our answer used to be that mutation events generally suck and you can't depend on them anyway. Obviously not an argument we'd want to use for MutationObservers. I can't think of any cases where you would *not* want these to fire for parser mutations. Agreed. I'm in favor of observers being notified for parser-initiated DOM mutations. The primary reason we don't fire mutation events for parser insertion removal is because they're synchronous and introduces all sorts of problems including security vulnerabilities but that isn't the case with mutation observers. One question. Should we also notify mutation observers immediately before executing synchronous scripts (i.e. script elements without differ or async content attributes) to address Mihai's use case? That would be rather odd. If someone needs to process mutation records before normal delivery time, there is always takeRecords() - Ryosuke
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Sun, Jun 17, 2012 at 10:22 PM, Olli Pettay olli.pet...@helsinki.fiwrote: That would be rather odd. If someone needs to process mutation records before normal delivery time, there is always takeRecords() In my example, I don't control the contents of the second script tag, so I can't use takeRecords() there. Mihai
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
