Re: [css3-syntax] `}` in selector mode with three ore more open rules

On Mon, Jan 28, 2013 at 4:00 PM, Simon Sapin <simon.sapin@kozea.fr> wrote:
> Le 29/01/2013 00:19, Tab Atkins Jr. a écrit :
>> I couldn't figure out what I was trying to do with it.  Since the
>> behavior in the spec is clearly nonsensical, and I can't figure out
>> what I was trying to do, I can't fix it, and so I've just removed it.
>
> At-rule-prelude mode has something similar.

Yup, missed that earlier.  That's what I get for getting back into
Syntax editting without loading the state machine into my head again.


>> The other clause didn't make any sense either, so I've fixed it up to
>> do the right thing - when you see a top-level } in a selector, it just
>> throws away the style rule being constructed, switches to the parent
>> rule's mode, and reprocesses the }.
>
> This makes sense for a selector in a rule-filled at-rule, but for a
> top-level selector I think you get an infinite loop. Reprocess the } which
> falls in "anything else" in top-level mode which leads you back to selector
> mode on the same token.
>
> In a top-level selector I think you just want to append the } token to the
> selector and leave to the selector parser to declare it invalid.
>
> I think you can also get rid of the Next-block error mode and
> Next-block-or-statement error mode.

As we discovered in the other thread, yeah, I did need that like it
was originally.  I've rewritten it to use the defined term "top-level
rule" so it's clear what the hell it's actually referring to, and I
think both occurrences are now fixed to have the right behavior in all
cases.

I've kept the error modes.  I see no reason to put } in an at-rule
prelude or selector, if it's just going to be thrown away as invalid
immediately.  You shouldn't put unmatched pair tokens in your CSS. ^_^

> Also, EOF in selector or at-rule prelude mode should be a parse error +
> discard the current rule rather than finish parsing.

Ah, thanks.  Fixed.

~TJ

Received on Wednesday, 30 January 2013 04:30:52 UTC