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, t
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. Resol
On Sun, 17 Jun 2012 13:10:11 +0200, Kang-Hao (Kenny) Lu
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
On 6/18/12 1:33 AM, Anne van Kesteren wrote:
On Mon, Jun 18, 2012 at 4:29 AM, Boris Zbarsky 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
On Mon, Jun 18, 2012 at 4:29 AM, Boris Zbarsky 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 h
On 6/17/12 9:50 AM, Anne van Kesteren wrote:
On Jun 17, 2012, at 3:44 PM, Boris Zbarsky 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 pars
On 2012-06-17 15:50, Aryeh Gregor wrote:
On Sun, Jun 17, 2012 at 4:43 PM, Boris Zbarsky 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 w
(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, i
On Jun 17, 2012, at 3:44 PM, Boris Zbarsky wrote:
> Also probably incompatible with a depth-first recursive descent parser
> implementation. Are we sure we want to overconstrain implementations like
> that?
Incompatible how?
On Sun, Jun 17, 2012 at 4:43 PM, Boris Zbarsky 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 implementa
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
Always throwing SyntaxError is probably better. Which reminds me, the
specification needs to be updated for new-style exceptions.
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
13 matches
Mail list logo
