W3C home > Mailing lists > Public > www-style@w3.org > September 2005

Block-based parsing; allow lies

From: Kornel Lesinski <kornel@osiolki.net>
Date: Wed, 14 Sep 2005 11:15:52 +0100
To: "David Woolley" <david@djwhome.demon.co.uk>
Cc: www-style <www-style@w3.org>
Message-ID: <op.sw274qb84suneb@idlaptop02.mshome.net>

On Tue, 13 Sep 2005 20:54:17 +0100, David Woolley  
<david@djwhome.demon.co.uk> wrote:

> As well as the other points that have been made, this rule doesn't work
> as parsers often know more of the grammar than they can implement in
> the rendering.

Require/allow browsers to 'fail' block for other reasons than CSS grammar.

That is needed to get things like positioned generated content useful on  
the web (which otherwise fails horribly in CSS2 browsers).

Vendors could use that intentionally to help authors avoid known rendering  
bugs (iframe {z-index} could fail in Opera, div  
{background-attachment:fixed;} in IE, etc.)

> The problem with rendering based rules is that marketing people will
> tend to take a liberal view of conformance (and put a low priority on
> fixing automated conformance claims) whereas people wanting all or
> nothing type processing often want a very strict interpretation.

Why would they lie? - to get their browsers render 'at least something'  
 from @required rules. So why not allow such "lying"?

Make two levels of conformance:

* Default level would be "appears to work" and could be used in simple  
situations where just basic functionality of property is needed.
* Second level would be "good implementation" which should be recognized  
only when browser has full and relatively bugfree implementation of  

I realize that even such solution is far from perfect and browsers will  
lie or will not recognize strict level despite good implementation, but  
still I thnik that's better than nothing.

I think over time browser vendors will learn that lying about unsupported  
features breaks sites and authors will find combinations of rules and  
selectors that eliminate lying browsers anyway.

Currently selectors and parsing bugs play role of @required, but @required  
rule gives more options, is closer to problem domain and will cause less  
damage in long term.

@required can't cause much harm - not as much as reliance on User-Agent  
string or CSS hacks. OTOH it will encourage implementation and use of new  
CSS features, especially those which aren't backwards-compatible.

regards, Kornel Lesiński
Received on Wednesday, 14 September 2005 10:14:22 UTC

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