[selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-17 Thread Kang-Hao (Kenny) Lu
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

Re: Should MutationObservers be able to observe work done by the HTML parser?

2012-06-17 Thread Jonas Sicking
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

Re: Browser Payments API proposal

2012-06-17 Thread Arthur Barstow
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/.

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

2012-06-17 Thread Anne van Kesteren
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

2012-06-17 Thread Boris Zbarsky
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

2012-06-17 Thread Anne van Kesteren
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

2012-06-17 Thread Aryeh Gregor
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

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

2012-06-17 Thread Kang-Hao (Kenny) Lu
(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,

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

2012-06-17 Thread Lachlan Hunt
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.

Re: Should MutationObservers be able to observe work done by the HTML parser?

2012-06-17 Thread Ryosuke Niwa
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:

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

2012-06-17 Thread Boris Zbarsky
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

Re: Should MutationObservers be able to observe work done by the HTML parser?

2012-06-17 Thread Olli Pettay
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:

Re: Should MutationObservers be able to observe work done by the HTML parser?

2012-06-17 Thread Olli Pettay
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

Re: Should MutationObservers be able to observe work done by the HTML parser?

2012-06-17 Thread Mihai Parparita
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

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

2012-06-17 Thread Anne van Kesteren
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

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

2012-06-17 Thread Boris Zbarsky
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.