CSS Fonts Level 4 provides additional means of selecting or filtering font resources. The tech() function was introduced, which allows passing in a list of font technologies that this respective font blob requires to function. Based on that, the UA will select the first suitable resource.
I will hold shipping until one remaining clarification is reached on whether the keywords should be phrased in singular or plural form, compare item 3 in https://github.com/w3c/csswg-drafts/issues/7633.
Motivation
With COLRv1 font supports, it's now more important to give authors an opportunity to check feature support. Doing this in the tech() function in the src: descriptor of @font-face is one useful tool for incremental upgrade of the user experience. If the UA supports COLRv1 or other new font technologies, the richer font is loaded, otherwise fallback occurs.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
Limited debuggability but unchanged to before: @font-face declarations are viewable as source in DevTools, but otherwise no particular tooling support is provided. However this is unchanged from before, as this change only affects the syntax inside the @font-face src: line.
107
See above, holding shipping until clarification is reached on singular or plural naming of features- keywords.
(re-sent from @chromium.org address)
On Monday, August 29, 2022 at 3:09:39 PM UTC+2 Dominik Röttsches wrote:(re-sent from @chromium.org address)I think that a short explainer outlining exactly what you're planning to ship here and how you're expecting developers to use it would be helpful. Can you add one? (potentially even inline, if it's rather short)
I think that a short explainer outlining exactly what you're planning to ship here and how you're expecting developers to use it would be helpful. Can you add one? (potentially even inline, if it's rather short)
[...] and how you're expecting developers to use it would be helpful [...]
We discussed this at today's API OWNERs meeting and, while I realise I should perhaps be directing most of these comments at the CSS WG more broadly, I'm concerned that the bundle of features that this function is designed to support are not clearly articulated, which argues for an explainer and perhaps a TAG review.Specifically:
- What problems do the "variations", "palettes", and "incremental" values address? There should be clear enunciation of those issues in an explainer, a discussion of considered alternatives, and example code describing how this specfic design best meets those needs.
- Related, why is "tech()" overloaded for whatever those values do as well as explict named technologies and sub-features?
- Since we're going first, and the only group that seems to have looked at this is the CSS WG, shouldn't there be a TAG review?
The CSS WG continues to work outside of our incubation and explainer-based model for feature development, and as a general matter it's not OK.I realise this feature is hostage to a bad work mode and it isn't the developer's of this syntax's fault, but we need to break the cycle.Future CSS features that do not incubate, center developer feedback (perhaps through OT), and show signs of incubation may also invoke delays from me.
(Chrome OWP Privacy reviewer drive-by)I'm trying to understand whether the various tech() capabilities are directly derivable from already exposed information, and this is just a convenience, or whether otherwise identical UAs might give out different values based on the platform or user configuration.The privacy section in the spec about " What data does this specification expose to an origin?" seems silent on this,
We discussed this at today's API OWNERs meeting and, while I realise I should perhaps be directing most of these comments at the CSS WG more broadly, I'm concerned that the bundle of features that this function is designed to support are not clearly articulated, which argues for an explainer and perhaps a TAG review.Specifically:
- What problems do the "variations", "palettes", and "incremental" values address? There should be clear enunciation of those issues in an explainer, a discussion of considered alternatives, and example code describing how this specfic design best meets those needs.
- Related, why is "tech()" overloaded for whatever those values do as well as explict named technologies and sub-features?
- Since we're going first, and the only group that seems to have looked at this is the CSS WG, shouldn't there be a TAG review?
The CSS WG continues to work outside of our incubation and explainer-based model for feature development, and as a general matter it's not OK.I realise this feature is hostage to a bad work mode and it isn't the developer's of this syntax's fault, but we need to break the cycle.Future CSS features that do not incubate, center developer feedback (perhaps through OT), and show signs of incubation may also invoke delays from me.
--
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d49673b0-57c6-4cc3-ae75-7169c4c380f5n%40chromium.org.