Re: [CSS2.1] blocks with missing start bracket and parsing error

On Sat, Mar 26, 2011 at 07:15:36PM +1100, Alan Gresley wrote:
> Hello again,
> 
> After my initial thread with a reply from Björn [1] regarding a
> 'missing end bracket', I will raise another issue now regarding a
> 'missing start bracket'.
> 
> 
> Please see this test case.
> 
> http://css-class.com/test/css21testsuite/blocks-035.xht
> 
> 
> This time the pertinent CSS is this.
> 
> 
>     p { background: blue }
> 
>     ]
> 
>    .test1 { background: green }
> 
> 
> Currently all browser will show one blue line and one green line.
> Unlike the 'missing end bracket' situation, we have a 'missing start
> bracket'. My question is, what should happen?

To my mind, the spec doesn't say what should happen here.

However, from discussions here and from the test suite, I gather is
that the intention is that the ']' token counts as "while parsing a
statement", and that finding "the end of the statement" when the start
of the statement is not an at-keyword and is not inside another block
involves finding a '{' token (more specifically a CBO, which I believe
means that it can't be written as \7b; though OTOH, uri-015 in the test
suite seems to assume that the "url" part of the URI token can be
written with escapes, so who knows) not inside any other bracketing
constructs, then finding a '}' token (CBC) not inside any bracketing
constructs; and that any non-matching closing bracketing characters
should be ignored for purposes of "observing the rules for matching
pairs".

(However, note that at-rule-013 seems to assume a different rule for
determining the end of the first @import statement: the unexpected '}'
token is not ignored, but rather seems to be taken to be the end of the
parent @media statement.  Whereas I gather that in contrast, a CDO or
CDC token is never taken as an indication of the end of the current
statement, nor is an unexpected '}' (CBC) token ever taken to mark the
end of the (sub-)statement currently being parsed.)

Applying the above rules, the ']' would be taken to be an error, so the
']' would be skipped (given that it doesn't match any opening '['), and
then one searches for a '{' (finding it on the .test1 line) and then
the '}' on that line is taken to be the end of the erroneous statement
that started with the ']', and that's considered to be the end of "the
illegal part" (see first para of section 4.2) to be ignored, and then
parsing continues as normal after that.  I.e. if there were a ".test2 {
background: green }" ruleset after the .test1 line then the .test2
ruleset would be honoured but the .test1 line would be considered part
of the illegal statement to be ignored.

Of course I'd prefer for these rules to actually be written in the
specification.

pjrm.

Received on Saturday, 26 March 2011 12:26:47 UTC