- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Tue, 18 Jan 2022 19:43:09 +0000
- To: public-css-archive@w3.org
Sure, they can test for an at-rule and miss a descriptor, but the same is true of existing property tests; you can easily test for a simple version of a property and fail to realize that the more complex version you're using in your actual styles isn't supported. That's a risk authors take when they're weighing the competing concerns of terseness/readability vs accuracy, and it's not something we need to work *too* hard to protect people from, imo. (Fun fact: an early proposal for @supports, way back when, worked by having *no* test in the prelude; instead you tagged individual properties in the contained styles with a !keyword, and it matched based on whether those properties parsed or not. No repetition at all, but what was being matched was a lot less clear up-front.) I think the trade-off of accuracy vs terseness in allowing just the at-rule name is reasonable here. *Most* of the time, the mere presence of the at-rule is a sufficient test. When there have been gradual upgrades to an at-rule's feature set and you need to discriminate between support levels, the full-fat version of the query is there for you, but I don't think we need to force that on everyone the rest of the time. For example, I do not want people to have to write out that full `@counter-style` example just to test if the at-rule is allowed at all; that's way excessive. (Properties, on the other hand, change their value set pretty regularly, and are a lot shorter to write, so the trade-offs of requiring the full `(prop: val)` over a simple `(prop)` isn't nearly as onerous.) -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2463#issuecomment-1015774159 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 18 January 2022 19:43:11 UTC