1228082 - @supports and CSS.supports should have a way to detect unicode-range support

Status: UNCONFIRMED

(Core :: CSS Parsing and Computation, defect)

Description

[Calvin Freitas]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151029151421

Steps to reproduce:

* Tried to apply styles using @supports(unicode-range: inherit)
** repro case: http://jsbin.com/monoli/3/edit?html,console,output 
* Tried to gate JS code with CSS.supports('unicode-range', 'inherit') check
** repro case: same as above


Actual results:

* pages using @supports(unicode-range: inherit) don't apply styles
** repro case: http://jsbin.com/monoli/3/edit?html,console,output 
* JS code gated by CSS.supports('unicode-range', 'inherit') doesn't run
** repro case: same as above


Expected results:

* @supports and CSS.supports should detect support for unicode-range
* behavior similar to Chrome
** test case: same jsbin as above
** tested in Chrome 46: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36

Comment 1

[Calvin Freitas]

I tested this against the current FirefoxDeveloperEdition and FirefoxNightly builds:
* Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:44.0) Gecko/20100101 Firefox/44.0
* Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Firefox/45.0

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Per spec (https://drafts.csswg.org/css-conditional/#support-definition ) this is correct behavior, since @supports is only about properties and values, not @font-face descriptors.  I believe there are proposals to extend @supports to check other things, but I can't find them right now.

Comment 3

[John Daggett (:jtd)]

The testcases here rely on a side-effect of the way Webkit implemented the CSS OM support for the @font-face rule. The old CSS2 spec definition of stuck a CSSStyleDeclaration into @font-face rules:

http://www.w3.org/TR/2011/WD-cssom-20110712/#css-font-face-rule

This means an author can adjust @font-face rules:

  var fontFaceRule = document.styleSheets[0].cssRules[0];
  fontFaceRule.fontWeight = "bold";

This also made it so that all @font-face rule descriptors needed to be hung off the CSSStyleDeclaration. But that doesn't make much sense for descriptors like 'unicode-range' which have no parallel property in CSS. The CSS3 Fonts spec defines a different OM but is not implemented in user agents (for Firefox implementation, see bug 1058408). 

The Firefox @font-face OM implementation is read only while the implementation in Chrome is very buggy. Safari seems to do a good job:

  http://people.mozilla.org/~jdaggett/tests/fontfaceruleomtest.html

Chrome/Safari do different things to "hide" the unicode-range value within element styles but it looks like for their @supports implementation it ends up exposed. Rather than that being considered a feature, I think we should look at that as a bug. In particular, 'unicode-range: inherit' is invalid in terms of a descriptor value.

The larger question of how to test for features like unicode-range support is trickier than just adding syntax to support @-rules within @supports blocks. For unicode-range, from Firefox 44, Firefox behaves like Chrome where the unicode-range value affects whichs fonts are loaded and used within text. For the Safari and IE implementations, the unicode-range value only affects *usage* and not which font resources are downloaded.