W3C home > Mailing lists > Public > www-style@w3.org > December 2007

Re: [CSS2.1] Parsing Selectors with Brackets

From: Christof Hoeke <csad7@t-online.de>
Date: Thu, 27 Dec 2007 12:27:32 +0100
Message-ID: <47738C24.5090607@t-online.de>
To: Anne van Kesteren <annevk@opera.com>
CC: www-style@w3.org, Justin Rogers <justrog@microsoft.com>, fantasai <fantasai.lists@inkedblade.net>, Bjoern Hoehrmann <derhoermi@gmx.net>

Anne van Kesteren wrote:
> 
> On Wed, 26 Dec 2007 23:15:44 +0100, Christof Hoeke <csad7@t-online.de> 
> wrote:
>>> I believe there is far too much in the specification that is just 
>>> text and not enough describing the grammar...
>>
>> I suspect that is really where all the browser incompatibilities come 
>> from, does it not?
> 
> No, the most pertinent issues are related to differences in rendering, 
> not differences in parsing a CSS file. Layout is one of the most 
> complicated parts of the browser and therefore getting interoperability 
> between N browsers is difficult.

Absolutely True.
But if the foundation (parsing the syntax) is not clear the rendering 
will inevitably be flawed.

(To explain: Guess I am actually ignoring rendering a bit as in a 
personal project I try to build a CSS lib which does not even try to 
render anything but just parse CSS. Use case at first was simply to 
pretty print a CSS file and later stuff like minifying and combining 
sheets - combining in the sense to cut down HTTP requests.
When using real-world stylesheets which may extensively use CSS hacks it 
quickly becomes almost impossible to handle these as even the base CSS 
syntax obviously has issues, not even counting implementation 
differences and the hacks (even on top...)

>>>  Error recovery in the parser can be extremely easy if we consider 
>>> simple and concise rules in the error recovery section. There is no 
>>> reason to be vague other than to leave options for implementation 
>>> interpretation or to allow current implementations to be correct even 
>>> if they don't follow the spec strictly.
>>
>> Just a thought, but is CSS really so different to other languages and 
>> specs (like e.g. XML) that it is so difficult to actually state these 
>> precise rules (no offense)?
> 
> XML only maps a certain set of byte streams to an XML document. CSS maps 
> every byte stream to a CSS document. On top of that comes that the CSS 
> grammar is more complex and evolves over time. If we add support for a 
> new CSS unit, such as 'rem' for instance, the tokenizer needs to be 
> modified. 

The tokenizer actually may remain the same, does it not (at least for a 
new CSS unit)?

> Having said that, I think we can do better, but the focus of 
> the CSS WG has primarily been differences in rendering and if nobody is 
> taking up the work, it is unlikely to get done. (David Baron has been 
> looking into (or suggesting at least) a grammar which includes handling 
> of errors for a CSS3 Module.)

The WG certainly is doing a great job, especially in the last months 
becoming
more public and all.

Christof
Received on Thursday, 27 December 2007 11:27:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:57 GMT