W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sun, 19 Aug 2012 00:32:45 -0700
Message-ID: <CAAWBYDCb-u=ZULwo=V1TD2R3jjAm5_-Kq_SgFYpuL=G0AM+q7A@mail.gmail.com>
To: Cameron McCormack <cam@mcc.id.au>
Cc: Chaals McCathieNevile <w3b@chaals.com>, Ian Hickson <ian@hixie.ch>, public-webapps <public-webapps@w3.org>
On Sat, Aug 18, 2012 at 6:03 PM, 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.

Yes, that's it exactly.  As a rule, browsers do *not* parse a rule
that they don't yet support; in the rare cases when they do, authors
complain, as it breaks naive feature detection and is just confusing.

So, all we require for CSS.supports() to work is for browsers to
continue doing exactly what they've already been doing for years.

Received on Sunday, 19 August 2012 07:33:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:38 UTC