Re: Blocks in parentheses or brackets

Hello Etan,

Your message was flagged as spam, because the date was impossible (14
Dec 2003)...

Etan Wexler writes:
> In CSS2 and CSS2.1, there is a conflict about block syntax. 
> Section 4.1.6, "Blocks"
> (<http://www.w3.org/TR/1998/REC-CSS2-19980512/syndata.html#block>,
> <http://www.w3.org/TR/2003/WD-CSS21-20030128/syndata.html#block>)
> states:
> 
>     A block starts with a left curly brace ({) and ends with the
>     matching right curly brace (}). In between there may be any
>     characters, except that parentheses ((Ê)), brackets ([Ê])
>     and braces ({Ê}) must always occur in matching pairs and may
>     be nested. Single (') and double quotes (") must also occur
>     in matching pairs, and characters between them are parsed as
>     a string. See Tokenization above for the definition of a
>     string. 
> 
>     Illegal example(s):
> 
>     Here is an example of a block. Note that the right brace
>     between the double quotes does not match the opening brace
>     of the block, and that the second single quote is an escaped
>     character, and thus doesn't match the first single quote:
> 
>     { causta: "}" + ({7} * '\'') }
> 
> This prose and example contradict the formal grammar, in which a
> block is forbidden inside parentheses and inside brackets. At
> issue is the following production
> (<http://www.w3.org/TR/1998/REC-CSS2-19980512/grammar.html>,
> <http://www.w3.org/TR/2003/WD-CSS21-20030128/grammar.html>).
> 
> any         : [ IDENT | NUMBER | PERCENTAGE | DIMENSION | STRING
>               | DELIM | URI | HASH | UNICODE-RANGE | INCLUDES
>               | FUNCTION | DASHMATCH | '(' any* ')' | '[' any* ']' ] S*;
> 
> Amending the production as follows would allow blocks in
> parentheses.
> 
> any         : [ IDENT | NUMBER | PERCENTAGE | DIMENSION | STRING
>               | DELIM | URI | HASH | UNICODE-RANGE | INCLUDES
>               | FUNCTION | DASHMATCH | '(' [ any | block ]* ')'
>               | '[' [ any | block ]* ']' ] S*;
> 
> We can consider the matter a correction/erratum rather than a
> change since the conflicting passages are equally normative.

You should distinguish the grammar of appendix D (the one you quoted)
from the grammar in chapter 4. The former is an approximation of the
grammar of CSS level 2 *only*, while the latter is for all of CSS.

In CSS2, there are only a few cases where curly braces can be nested
(rules inside @media) and they are captured by the grammar of appendix
D. In the future, there may be more cases of nested blocks, and that's
why the grammar in chapter 4 has a rule for "any" that contains
"block".

If a CSS2 UA reads a file that doesn't match the grammar of appendix
D, it knows there is an error in the file. It then has to find out if
the file matches the generic grammar of chapter 4, and if it does, it
should accept the file anyway, after applying rules such as those of
4.1.6 to remove the offending parts.

(If the file doesn't match the generic grammar either, it is not CSS
and will never be CSS in the future. We haven't specified what a UA
should do with the file in that case.)



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos/                              W3C/INRIA
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Friday, 21 February 2003 08:15:59 UTC