- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 29 Jan 2013 20:16:48 -0800
- To: Simon Sapin <simon.sapin@kozea.fr>
- Cc: "www-style@w3.org" <www-style@w3.org>
On Tue, Jan 29, 2013 at 2:32 PM, Simon Sapin <simon.sapin@kozea.fr> wrote: > A few edge cases: > > * EOF in selector mode should be a parse error (a {} block is missing) > * EOF in at-rule prelude should be like ';'. A parse error for > declarations-filled or rule-filled at-rules, but not for other at-rules: > > data:text/html,<style>@import "data:text/css,body{background:green" > > In the example above the @import rule is valid even though it ends with EOF > rather than ';' > > * '}' in either mode should be like EOF, but *only* if this is nested in a > matching '{' block such as @media { > * An unpaired '}' in a top-level selector or at-rule prelude should be like > ']'. It’s preserved token as far as Syntax is concerned, it’s only invalid > in Selectors, MQ, etc. > > > Maybe this last distinction is what "If the stack of open rules has three or > more items on it, …" was about? Okay, should be fixed now. If a } occurs in a selector or an at-rule prelude, it changes behavior based on whether you're currently parsing a top-level rule or not, usually throwing the rule away. (Only exception is if you're parsing a non-top at-rule which is a statement, which I just close and consider done, like if you have an unclosed property in a style block when you hit }. That doesn't exist in current CSS (only at-rule statements are @import and @charset, which are invalid when not at top-level), so it's nothing to worry about so far, but might as well cater for the future. ~TJ
Received on Wednesday, 30 January 2013 04:17:34 UTC