Supporting feature tests directly

Tab Atkins Jr. jackalmage at
Wed Mar 25 19:32:20 UTC 2015

On Wed, Mar 25, 2015 at 12:06 PM, Andrea Giammarchi
<andrea.giammarchi at> wrote:
> For consistency sake I agree, but I come from a world where browsers also
> exposed unofficially APIs so that, as James mentioned already,
> `Array.prototype.includes` would have returned true and never worked.
> I wonder how reliable is `CSS.supports` not just in term of syntax, but
> actual usability.

You give it a full property declaration, and if the browser can parse
it successfully, it returns true/false.  This allows for false
positives (a browser parsing a property but not actually supporting it
yet), but devs (rightfully) yell and scream at browsers whenever that
case (parse but no support) happens, so we do it very rarely, and only
ever by accident.

It's just a standardized version of the de facto standard CSS feature
test of "set the property on an element, and try to read it back; if
you get something, it's supported".

Because it's based on an objective and reliable criteria tied to
directly to actual support (successful parsing), it's reliable in
practice as a feature test.  This differentiates it from the old
hasFeature() function, which was based on a map of feature strings to
bools stored in the browser, with no connection to the actual features
in question, and so was inevitably filled with lies and bitrot.


More information about the es-discuss mailing list