Open
Bug 1228082
Opened 9 years ago
Updated 2 years ago
@supports and CSS.supports should have a way to detect unicode-range support
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
UNCONFIRMED
People
(Reporter: calvin.freitas, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: testcase)
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
Reporter | ||
Comment 1•9 years ago
|
||
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
Updated•9 years ago
|
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.
Summary: @supports and CSS.supports don't detect unicode-range support → @supports and CSS.supports should have a way to detect unicode-range support
Comment 3•9 years ago
|
||
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.
Updated•7 years ago
|
Blocks: css-conditional-3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•