Re: Browsers will never get [block based parsing] right

Ian Hickson wrote:
> On Wed, 14 Sep 2005, Emrah BASKAYA wrote:
> 
>>We don't have to make it complicated and put conformance levels.
> 
> In that case we're back to the original proposal, which doesn't work at 
> all, as discussed.

Sure, @required wouldn't fix all the issues in the world, not even 
all the issues we have when we combine CSS and HTML, but it does 
give us (style authors) a few more tools to fight the UA bugs.

I think Kornel Lesinski 
(http://lists.w3.org/Archives/Public/www-style/2005Sep/0092) got it 
right when he compared this feature to incorrectly implemented 
properties or selectors. All browsers have incorrectly implemented 
features and @required would be no different. But the odds of having 
broken selector implementation combined with broken @required 
implementation is smaller than having just a broken selector 
implementation.

>>But I am sure, with the absence of such a @required feature, the authors 
>>will find great many hacks to use new CSS3 feature without making it 
>>look silly on CSS2 browsers (classic example would be using less padding 
>>when UA cannot display rounded corners), such as using CSS3 selectors 
>>*just* for the sole purpose of eliminating CSS2 browsers.
> 
> Yes, that's quite possible. However, the proposed feature wouldn't 
> actually help with this case, since you'd end up with browser X claiming 
> support for border-radius despite a fatal (but unnoticed when the browser 
> shipped) bug. Or some similar thing.

If browser X has a fatal bug in implementation of some CSS property, 
it really doesn't matter if it incorrectly implements @required too. 
Not having @required *as an additional protection* is not going to 
help much, is it?

-- 
Mikko

Received on Wednesday, 14 September 2005 15:04:06 UTC