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. <[email protected]>
wrote:

> On Wed, Mar 25, 2015 at 12:06 PM, Andrea Giammarchi
> <[email protected]> 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
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to