- From: Emilio Cobos Álvarez via GitHub <sysbot+gh@w3.org>
- Date: Wed, 21 Apr 2021 17:37:12 +0000
- To: public-css-archive@w3.org
So I think some of the concerns @mirisuzanne mentioned (of needing to support this condition way before `@container` works) are really an issue, but only because browsers disagree on this case: ```js CSS.supports("not foo()") ``` That returns `true` in Firefox (as I'd expect, fwiw), but `false` in Chrome and Safari. So you can't use `@supports not container(..)` unless they implement the new thing. We should probably get interop on that. My understanding given the supports syntax in https://drafts.csswg.org/css-conditional/#typedef-supports-condition is that this is a Chromium / WebKit bug. Does it match yours @lilles? Now with that said, in terms of fixing this, yeah, the proposal was on the lines of: ```css @supports at-rule(<ident>) ``` To test support for an specific at-rule. @frivoal raised the concern of it being a bit footgunny in cases we extend the syntax of the at rules, so I think this was the most controversial. Then there was: ```css @supports container(<container-expression>) ``` And: ```css @supports media(<media-query>) ``` And these need specific definitions because `<media-query>` has a `<general-enclosed>` clause that would parse all media queries successfully (I think this is a mediaqueries-4 feature which we weren't implementing). -- GitHub Notification of comment by emilio Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6175#issuecomment-824237638 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 21 April 2021 17:37:14 UTC