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

Re: [CSS21] DELIM? in core syntax

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Sat, 05 Apr 2008 10:28:04 +0100
Message-ID: <47F74624.1060703@googlemail.com>
To: fantasai <fantasai.lists@inkedblade.net>
CC: Anne van Kesteren <annevk@opera.com>, www-style@w3.org

fantasai wrote:
> Anne van Kesteren wrote:
>> Does anyone recall why DELIM? is part of the declaration production in 
>> the core syntax? It was suggested this might be because of vendor 
>> prefixed properties, but that is already covered by the IDENT token.
> Please check errata first when raising issues with the spec. :)
> http://www.w3.org/Style/css2-updates/CR-CSS21-20070719-errata.html#s.4.1.1

While IDENT does fully cover vendor-prefixed properties, note that 
DELIM? also (incidentally) allowed the following "star property" 
parsing-bug hack for passing properties to IE7 and below

*width: 100px;

to be parsed and discarded as a malformed declaration by conforming 
implementations, rather than rendering the entire input untokenizable.

This hack is not uncommon. For example, YUI foundation uses it:


IE6 and IE7 error-correct *property: value; to property: value;.

As best as I can tell, other popular web engines treat *property: value; 
as a malformed declaration  (Opera, Gecko, KHTML) or an unknown property 
(probably WebKit, Amaya) and continue to process the remaining 
declarations in the block.

A known exception is the (ex-Steady State) SACParser used by the Lobo 
browser, which skips the whole block where it occurs.

I'd suggest that for future implementations to be compatible with a not 
insignificant body of existing CSS and most existing user-agents, 
*property: value; should be treated as a malformed declaration 
tokenizable with the core syntax, rather than leaving handling undefined.

We don't need all of DELIM? for that. It could be more surgical:

declaration: '*'? property S* ':' S* value ';';

Benjamin Hawkes-Lewis
Received on Saturday, 5 April 2008 09:28:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:35 UTC