Re: Acceptable for CSS to add a "window.CSS" global?

On Sun, 19 Aug 2012 03:03:19 +0200, Cameron McCormack <cam@mcc.id.au>  
wrote:

> Chaals McCathieNevile:
>> Frankly, I am deeply sceptical that the CSS group has managed to solve
>> the social problem sufficiently well to make the technical solution
>> noticeably different from hasFeature.
>
> I think the biggest difference between hasFeature and supportsCSS is  
> that the implementation of the former, for a given feature string, would  
> be completely independent of the feature it is testing for.  So someone  
> must make a judgement at some point about whether to return true for a  
> given feature string.  With supportsCSS, I would imagine that it would  
> return true or false by passing the string along to the CSS parser, so  
> you would be much more likely to get an accurate answer out of it and  
> there'd be no need for someone to make the judgement call.

Until some important site starts to use this to differentiate between  
browsers. Since the primary job of a browser maker is to render the web  
for users, when a site blocks them for no real technical reason the  
browser is likely to (and should) implement a work-around to make the site  
work. This is one area where hasFeature() failed. Another, and one which I  
suspect requires less social engineering to resolve, is the "look, we  
score XYZ on ShinyNewBenchmark.com" - by implementing just enough of  
something to pass the test without making it usable in practice.

I honestly hope supports works out - and believe it can. But that belief  
is not based on the idea that it is somehow fundamentally different  
technically, but that it can combine something of a clean slate, a  
slightly different implementation, and happening today and not five years  
ago. So despite my concerns about how it works out with e.g. "-webkit-*" I  
think it's worth trying.

But then, I am an eternal optimist.

cheers

Chaals

-- 
Chaals - standards declaimer

Received on Sunday, 19 August 2012 11:00:35 UTC