On Sun, 19 Aug 2012 03:03:19 +0200, Cameron McCormack <[email protected]>
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
