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

Re: Block-based parsing; allow lies

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 14 Sep 2005 11:34:39 +0000 (UTC)
To: Kornel Lesinski <kornel@osiolki.net>
Cc: David Woolley <david@djwhome.demon.co.uk>, www-style <www-style@w3.org>
Message-ID: <Pine.LNX.4.62.0509141131060.23166@dhalsim.dreamhost.com>

On Wed, 14 Sep 2005, Kornel Lesinski wrote:
> Why would they lie? - to get their browsers render 'at least something' 
> from @required rules.

No, they lie because of bugs. It's not really lying, it's completely 

> 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 feature.

To do this, it first has to be established that the implementations are 
relatively bug free. I can think of many cases in many browsers where a 
feature was thought to be bug free for _years_ until someone (typically 
me! :-P) came along and actually tested it. Then suddenly it was found 
that actually the feature was pretty much unusable in anything but the 
simplest scenarios.

> 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.

...and then we're back to where we are now. So what's the point? I 
disagree that the benefits introduced outweigh the cost (in author 
confusion and frustration, in implementation investment, in testing, in 
specifying what "a good level of conformance" means, etc).

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 14 September 2005 11:34:48 UTC

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