Re: CSS parser recovery

On 12/14/02 2:01 AM, "Ian Hickson" <ian@hixie.ch> wrote:

> On Sat, 14 Dec 2002, Tantek Çelik wrote:
>> On 12/14/02 1:50 AM, "Ian Hickson" <ian@hixie.ch> wrote:
>>> 
>>> And I cannot see any way that that is desirable.
>> 
>> I did not say whether or not it is desirable.  It simply is.
> 
> I disagree. You have not shown any part of the spec that says that the
> brace should be ignored,

It causes the declaration to become illegal (per the property : value
definition of declaration), and thus the declaration is ignored.

> not any part of the spec that says that the
> definition of "block" should be ignored for declaration blocks.

That's what more specific rules do, they tell you what to do more
specifically than generic rules.  I can quote them again if it helps:


CSS 7.1:

<blockquote>
A declaration consists of a property, a colon (:) and a value.
</blockquote>

Note - no allowance for a block in the property, or after the property
before the colon.

Continued...

<blockquote>
Around each of these there may be whitespace.
</blockquote>

Explicit allowance of whitespace, but NO allowance of a block.

Continued...

<blockquote>
A property is an identifier, as defined earlier.
</blockquote>

And identifiers as defined earlier CANNOT contain blocks.

Continued...

<blockquote>
Any character may occur in the value, but parentheses (()), brackets ([]),
braces ({}), single quotes (') and double quotes (") must come in matching
pairs.
</blockquote>

Aha! Explicit allowance for a block in the value, and only the value portion
of the declaration.


>>> Also, your way makes it impossible for us to extend CSS to allow blocks on
>>> the property side, as in:
>>> 
>>>  h1 {
>>>   font-size { minimum, preferred, maximum }: 9px, 16px, 72px;
>>>  }
>>> 
>>> ...or whatever.
>> 
>> Correct.
> 
> Well given that my interpretation is _at least_ as valid as yours, and
> arguably (IMHO) more valid, and in addition more flexible, I don't see any
> reason to prefer your interpretation.

My interpretation interprets the specific rules more strictly, and is thus
preferable from a stricter interpretation point of view and thus arguably
(IMHO) more valid.

Your interpretation is more flexible from the point of allowing us to extend
CSS to allow blocks on the property side.

> We should probably clarify the spec to explicitly state that the text that
> says that blocks must be nested does indeed apply too all blocks (although
> to be honest I didn't think that was debatable until today).

And I didn't think it was debatable either until today.

At this point I see more value in not breaking at least two implementations
that have been (arguably) compliant with this portion of the spec for quite
some time, rather than allowing for a theoretical only useful ability to
extend CSS to allow blocks on the property side.

Thus I would prefer the spec to explicitly state that blocks are not allowed
inside a property, or after a property before the colon, and that any random
characters (such as "{") present in such locations render the declaration
illegal and cause the declaration to be ignored.

Tantek

Received on Saturday, 14 December 2002 05:42:50 UTC