- From: Dominik Röttsches via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Sep 2021 13:52:39 +0000
- To: public-css-archive@w3.org
@litherum wrote: > @else would have to come first, though, so we don't teach authors to do the wrong thing because the better tools aren't available yet. @svgeesus wrote: > I also don't want us to adopt a solution "for now" that has the multiple download and fallback problems that @jfkthame has explained so well. If we add an `@else` construct, and only _after that_ define a `font-technology()` function for feature detection and `@supports` conditionals, we supposedly gain a form of educational advantage. But if both are shipped in the future, whom are we preventing from still writing the less performance optimised version that @jfkthame explained where the font blobs accumulated into a family through which we need to fallback? Aren't we overestimating this advantage of shipping @else before the feature detection function, given that it will still be possible to spell out the less performant version (which I still consider a niche case given that font CSS is generated in the majority of use cases)? Aren't we undererstimating the uptake of a better `@else` construct once it's available? -- GitHub Notification of comment by drott Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-920038831 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 September 2021 13:52:41 UTC