W3C home > Mailing lists > Public > www-style@w3.org > March 2008

RE: [CSS 2.1] General at-blocks and error recovery

From: Justin Rogers <justrog@microsoft.com>
Date: Sat, 8 Mar 2008 19:09:44 -0800
To: "L. David Baron" <dbaron@dbaron.org>, Anne van Kesteren <annevk@opera.com>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <00BD06E707F60B4F9D6A3E75C712209D4A121EE3EB@NA-EXMSG-C104.redmond.corp.microsoft.com>

>>>
An at-rule consists of everything up to and including the next semicolon (;) or the next block, whichever comes first.
<<<

@media all { @ }
div { color: green; }

I think the sticky point for this test case is what takes priority in error recovery. The open parenthesis starts a block which is owned by the @media. The closing parenthesis should close the block because it is currently the only open block and we found a matching closing character. We may do this while we are in error recovery for something else like a selector though. So, does error recovery stop once your parent block is closed? I don't think we should trump the higher level rules of matching blocks because we find a syntactic issue with the internals of the block itself since at-rule's hold blocks and blocks hold any. If it can hold any, then it also means it could hold just an asterisk and nothing more. So when we think we are in error recovery for a selector we should also be aware that we may have to short circuit because the block containing the selector is closed.

at-rule     : ATKEYWORD S* any* [ block | ';' S* ];
block       : '{' S* [ any | block | ATKEYWORD S* | ';' S* ]* '}' S*;

Justin Rogers [MSFT]

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of L. David Baron
Sent: Saturday, March 08, 2008 8:25 AM
To: Anne van Kesteren
Cc: www-style@w3.org
Subject: Re: [CSS 2.1] General at-blocks and error recovery


On Saturday 2008-03-08 10:54 +0100, Anne van Kesteren wrote:
> On Sat, 08 Mar 2008 06:56:11 +0100, L. David Baron <dbaron@dbaron.org>
> wrote:
>> What Firefox is doing is the following:
>>
>> @media all {
>>   /* ok, we're inside an @media rule, so we parse declaration blocks */
>> @
>>   /* well, this is the beginning of an invalid selector, so we have
>>      to parse until we hit the end of the declaration block, that
>>      is, until we hit an { and then the matching } */
>> }
>>   /* not a {, so keep looking for the { to start our declaration block */
>>   /* ... same for all remaining tokens in the style sheet */
>>
>> I can't find anything that says what @media rules are supposed to
>> have in them, but this seems to match the spec, now that I think
>> about it.
>
> I figured this was the reasoning. So is the reason this does not violate
>
>   http://www.w3.org/TR/CSS21/syndata.html#block
>
> that you're trying to form an at-rule token and therefore the matching { }
> pair is not actually a matching pair but the closing curly brace is part of
> a token?

No, it's definitely not part of a token.  The tokenizer is quite
clear.

What's happening is that after the "@" we're parsing an invalid
selector.  When we're parsing an invalid selector, we recover after
we find a "{" and then a matching "}" (a declaration block).  When
we hit the "{", we're looking for a "{" so it doesn't actually match
anything.

If you want Firefox to recover after "@media all { @ }" it will if
you write "{ } }".  The "{ }" is the declaration block it's looking
for, and the final "}" closes the @media rule.

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Sunday, 9 March 2008 03:10:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:02 GMT