CSS @supports feature detection

[Nikhil Nigade]

The CSS "@supports" syntax is useful for feature detection and progressive enhancements.

The following CSS code fails in 
- Safari 11.0.2 on macOS 10.12.6
- Safari Technology Preview Release 46 on macOS 10.12.6
- Mobile Safari on iOS 11.2.2

> @supports (-webkit-backdrop-filter: blur) {
>     #myElem {
>         -webkit-backdrop-filter: blur(10px);
>     }
> }

The associated JS for the above also fails:
> CSS.supports('-webkit-backdrop-filter', 'blur') || CSS.supports("backdrop-filter:blur") || CSS.supports("-webkit-backdrop-filter:blur")

Expected: The above is expected to return `true` and/or the CSS @supports block should be invoked.

Actual Result: 
1. The above JS code returns `false` and therefore disables the progressive enhancement path and the implementation requires checking the UA String for feature detection. 
2. The CSS @supports block is never parsed since feature detection fails although supported by the browsers.

[Simon Fraser (smfr)]

Does @supports (-webkit-backdrop-filter: blur(0)) work?

[Nikhil Nigade]

(In reply to Simon Fraser (smfr) from comment #1)
> Does @supports (-webkit-backdrop-filter: blur(0)) work?

Yes. That syntax works both in CSS and JS on: 
- Safari 11.0.2 on macOS 10.12.6
- Safari Technology Preview Release 46 on macOS 10.12.6
- Mobile Safari on iOS 11.2.2

However, shouldn't simply using
> (-webkit-backdrop-filter: blur)
also pass the check? 

My code is now set up to use the following for future-proofing. 
> @supports (-webkit-backdrop-filter: blur(0)) or
>           (backdrop-filter: blur(0)) {
> }

[Simon Fraser (smfr)]

Created attachment 333331 [details]
Testcase

This is correct behavior. The contents of @supports have to be a full-formed property/value pair. Our behavior is the same as Chrome and Firefox here.