Contact [email protected] Explainer https://github.com/w3c/csswg-drafts/blob/main/css-conditional-5/font-tech-format-explainer.md
Specificationhttps://www.w3.org/TR/css-conditional-5/#at-supports-ext Summary The font-tech() and font-format() are extensions to the @supports rule CSS Conditional Syntax enable declarative and programmatic access to feature detection of font stack features. Using these conditions together with @supports allow progressive enhancement of content depending on font format support. In particular with UAs differing in support for color font formats, this is useful for including color font style rule and @font-face definitions only if the user agent supports it. Using JS CSS.supports() calls this is also the first ergonomic way of testing for font stack capabilities on the web without UA sniffing or canvas pixel readback as in Chromacheck (https://pixelambacht.nl/chromacheck/). This feature is closely related to the @font-face src: descriptor syntax extension which was recently discussed and LGTM'ed here <https://groups.google.com/a/chromium.org/g/blink-dev/c/_9k-Ne8FRu4>: - the same font format and technology keywords are used and synchronized between these two features. *Motivation* While font files look the same from the outside in their mime type and file signature, they may contain information that requires specific features of the UA's font stack. If an author wants to progressively enhance their site depending on font format capabilities of the UA, feature detection is needed. This feature here provides such a capability on the client side in two ways, declaratively in CSS, or programmatically in JS using CSS.supports(). Examples: - If OpenType variations are supported, I want to use a set of different style rules than when variations are not available - If color font support is available, I want to enhance my site with a color fonts plus style rules affecting other parts of my page. Blink componentBlink>Fonts <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFonts> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/666 TAG review statusIssues addressed Risks Interoperability and Compatibility *Gecko*: In development ( https://github.com/mozilla/standards-positions/issues/563#issuecomment-1224131600) Implemented behind flag and standards position concluded with positive stance towards this feature. Jonathan Kew plans to ship this soonish and in any case in sync with COLRv1 support. *WebKit*: From the standards discussion on this, my take-away of the discussion with Myles is that the feature is useful, but Myles suggests to ship it only in combination with @else <https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-947346133> - my position is that @else is not essential for this feature to provide value. *Web developers*: Positive Feedback we received from partners is that robust feature detection for this feature is a requirement and helps activation of usage of color fonts. More info available internally. (See previous I2S for tech() and format() in the src: descriptor of font-face) *Other signals*: Ergonomics This feature is intended for situations where the progressive enhancement choice is made client side. Feature detection on the server side, at the time for example the UA makes a request for a style sheet is out of scope for this proposal. In those situations, UA sniffing on the server side is still performed on the server based on request headers and user-agent string - which may be addressed by font feature client hints in the future. Activation Low: If this feature is not supported, the respective CSS styles are not included, so the progressive enhancement fails, which is the nature of this approach. If CSS.supports() calls are failing because they are not available, then the program logic trying to feature detect font stack capabilities, may need to resort to other methods of testing font support, for example through Canvas pixel probing or hardcoded UA lists. WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? No. Debuggability Equivalent to other @supports debugging. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?Yes Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?Yes, tests were added by Mozilla's Jonathan Kew initially while developing support for this feature in Gecko with additional tests and modifications to them when I developed the feature behind a flag. Flag namechrome://flags/#enable-experimental-web-platform-features Requires code in //chrome?False Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1255685 Sample links https://github.com/w3c/csswg-drafts/blob/main/css-conditional-5/font-tech-format-explainer.md#use-case-1---progressive-enhancement-with-color-fonts Estimated milestones 108 Anticipated spec changes Additional keywords may be added in the future. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5155718374621184 This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN6muBvYtHHtgDGtJ-7j%3DJdzWTOA8MFf8O6VT%3DOyovcfYihmog%40mail.gmail.com.
