Re: [CSS2.1] Parsing Selectors with Brackets

Christof Hoeke wrote:
> 

> 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 doesn't really have error recovery (although it is possible that 
some applications of XML have error recovery for content model 
violations (most cases where actual error recovery would be used in 
other languages are well formedness errors and therefore recovery is 
forbidden)).

CSS needs error recovery defining for two reasons:

1) the original one was that the "error" may no longer be an error in 
some future version, and parsers are expected to recover the compatible 
content from future version documents.  (Future versions can rely on 
this part of the error recovery being applied by implementations of 
previous versions.)

2) for certain web technologies, the normal garbage in garbage out rule 
is suspended and all viewers are supposed to behave the same in response 
to the same, invalid input.  These include HTML, CSS and SVG, so errors 
that, by their nature, can never be exploited for future versions of CSS 
are still required to be recovered, by recent and future browsers, in 
the same way.  (In traditional programming languages, although you might 
have debugging compilers that use error recovery to try to find as many 
errors as possible in one pass, one is expected to use error free source 
code for the final build.  This can result in invalid input producing 
compiler dependent results (particularly with production compilers). 
That is considered unacceptable for web authors.)
-- 
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

Received on Wednesday, 26 December 2007 22:37:38 UTC