W3C home > Mailing lists > Public > www-style@w3.org > August 2012

Re: [css3-conditional] navigator.supportsCSS rather than window.supportsCSS

From: Elliott Sprehn <esprehn@gmail.com>
Date: Wed, 15 Aug 2012 01:15:47 -0700
Message-ID: <CAPJYB1isb9EMsqz5RxRZ9Qz-Suhg0xqOTNOQ__YfFfqeCxFajA@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Boris Zbarsky <bzbarsky@mit.edu>, www-style list <www-style@w3.org>
On Wed, Aug 15, 2012 at 12:08 AM, Glenn Adams <glenn@skynav.com> wrote:

> ...
>> document.supportsCSS(property, value) is what you want.
> I believe this is intended to be a function of the browser in general,
> independent of whether operating in quirks mode or not, which is
> effectively under author control. So NO, it should not be defined on
> Document.

If the function is supposed to return true when the CSS feature is
available then it must be per document, or you write really weird stuff
like iframe.contentWindow.CSS.supports(...), and inside an extension you
must be super careful to access the hostPage.window.CSS.supports because
CSS.supports inside the extension environment is going to return totally
different values.

It's not inconceivable that Chrome OS or Boot2Gecko apps (etc.) will
support fancy "app specific" CSS features that aren't available to regular
web pages (actually these things already exist like -moz-binding or

If you're suggesting it return the exact same values in all environments
then @supports (-moz-binding(...)) is going to be true in Gecko on regular
web pages which is definitely wrong since -moz-binding doesn't work there.
Similarly an embedded <iframe> inside a Dashboard widget with @supports
(-apple-dashboard-region) will evaluate to true..

- E
Received on Wednesday, 15 August 2012 08:16:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:20 UTC