- From: Tantek Çelik <tantek@cs.stanford.edu>
- Date: Sat, 14 Dec 2002 20:25:09 -0800
- To: <www-style@w3.org>
On 12/14/02 4:24 PM, "Ian Hickson" <ian@hixie.ch> wrote:
>> We'll fix Tasman to comply with this interpretation - could you
>> suggest the specific errata for CSS1 & 2 to clarify the interpretation
>> in the specs?
>
> Well, my argument is that it doesn't require clarification. ;-)
>
> The easiest way might be to just change the example in the 4.1.6 Blocks
> section of CSS 2.1 from:
>
> { causta: "}" + ({7} * '\'') }
>
> ...to:
>
> { causta { "}" + ({7} * '\'') } }
>
> ...or some such.
That might help.
> The more I read 4.1.6, the less I can work out how else it could be
> interpreted.
To begin with, in CSS1 7.1
http://www.w3.org/TR/REC-CSS1#forward-compatible-parsing
Where it specifically says:
"
A declaration consists of a property, a colon (:) and a value. Around each
of these there may be whitespace. A property is an identifier, as defined
earlier. Any character may occur in the value, but parentheses (()),
brackets ([]), braces ({}), single quotes (') and double quotes (") must
come in matching pairs.
"
the last sentence seems to imply that such matching is only required inside
the value, which is not how others have interpreted it. Since such matching
is required in the entire declaration, perhaps it is better to say that.
It might be as simple as changing ", but parantheses" to ". Parantheses".
> Maybe at the end of 4.1.8 "Declarations and properties", we
> could add "Note that the parsing rules for generic blocks all apply to
> declaration blocks as well. Foor instance if an opening brace is found in
> an unexpected place, it does still delimit the start of the block.".
>
> Since you thought there was an alternative interpretation, what do _you_
> think should be changed? :-)
Where it also says:
"Any character may occur in the value, but parentheses "
Change it to:
"Any character may occur in the value. Parentheses "
which drops the implication that such matching is only required in the value
by decoupling the two clauses.
Tantek
Received on Saturday, 14 December 2002 23:10:30 UTC