Supporting feature tests directly

James Kyle me at thejameskyle.com
Wed Mar 25 20:17:22 UTC 2015


The reason `@supports` works in CSS is because of the limited language feature-set CSS has, but this wouldn't work in JavaScript.




To reuse the TCO example:




```

var supportsTCO = Reflect.supports('function recursive() { recursive() }');

```




Of course that will parse, and executing it wouldn't be a good idea.




Transpilers can solve this problem. I've been working on Babel to get caniuse-like browser support data to be smarter about handling what to transpile.




- "I want to support the last two versions of every browser, transpile/polyfill that for me."

- "I want to support these features, what browser support will I have?"

On Wed, Mar 25, 2015 at 12:32 PM, Tab Atkins Jr. <jackalmage at gmail.com>
wrote:

> On Wed, Mar 25, 2015 at 12:06 PM, Andrea Giammarchi
> <andrea.giammarchi at gmail.com> 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.
> ~TJ
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150325/dad91222/attachment-0001.html>


More information about the es-discuss mailing list