- From: Myles C. Maxfield via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Oct 2021 05:42:21 +0000
- To: public-css-archive@w3.org
@fantasai's proposal in https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-934811808 makes sense to me. Regarding the question of whether or not we can avoid changing the `src` descriptor, I think it comes down to how authors would implement fallback with `@supports` instead. Ideally, the same fallback code should be applied in both situations: 1) you're on an old browser that doesn't understand the new `@supports` syntax, and 2) You're on a new browser, but the browser doesn't actually support the font technology you're requesting. I think handling fallback for both these situations using the same code should be considered a requirement (otherwise it's too hard and authors will get it wrong). A quick check shows that, in today's browsers (which are the first situation above), ``` @supports not font-format(truetype variations) { div { background: blue; } } ``` does _not_ cause `<div>`s to get `blue` backgrounds. On the other hand, ``` @supports not ( font-format(truetype variations) ) { div { background: blue; } } ``` _does_ cause `<div>`s to get `blue` backgrounds. Maybe the solution is to change `<supports-decl>`'s definition from `( <declaration> )` to `( <declaration> | font-format(<font-format>) )`? I'm not sure we can actually use this, though, because I think it was an intentional choice to make the thing between the parentheses a `<declaration>`. If we can come up with a solution that satisfies these constraints, we can leave the `src` descriptor alone. However, if we can't, then I think we need to add expressiveness to the `src` descriptor because that's how authors would achieve correct fallback behavior. -- GitHub Notification of comment by litherum Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-947346133 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 October 2021 05:42:23 UTC