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

On Sun, Aug 19, 2012 at 3:59 AM, Chaals McCathieNevile <w3b@chaals.com> wrote:
> 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.

While Opera has a history of lying to sites for compatibility reasons,
most other browsers do not.  Even within practices such as Opera's,
it's always limited to particular sites which are problematic, rather
than being a generic lie to the web as a whole (which, in @supports's
case, would almost certainly *break* plenty of sites who *are*
depending on that property being supported properly).  Finally, the
CSSWG's own practices of mandating prefixes before compatibility is
established means that it's unlikely that someone will claim to
support an unprefixed property before it's actually ready.

This sort of thing can still fail, of course. But it fixes several of
the problems that dragged hasFeature() down.


In any case, it sounds like no one knows of any problems off the top
of their head with adding a new "window.CSS" object.  Pending any
compatibility studies showing problems, we'll go ahead and move
forward with it.

~TJ

Received on Sunday, 19 August 2012 15:57:51 UTC