- From: Bramus! via GitHub <sysbot+gh@w3.org>
- Date: Tue, 11 Apr 2023 09:01:21 +0000
- To: public-css-archive@w3.org
> [#](https://github.com/w3c/csswg-drafts/issues/8399#issuecomment-1497825549) The CSS Working Group just discussed `[css-conditional-5][css-nesting-1] Feature detection for nesting`. > … > < heycam> @supports rule(p { & { } }) > < fremy> @supports (&{}) > < bradk> @supports (nesting) { … } I like @heycam’s suggestion here to be able to pass an entire rule-set into `@supports`. Of the three suggestions, it has the widest coverage. This would help not only here with nesting, but also cover future/other CSS features such as `@scope`, as authors can pass in `@scope (.foo) to (.bar) { & { color: hotpink; } }` to detect if that specific syntax is supported or not. Using a keyword like `nesting` doesn’t cover that. This extension to `@supports` would pair really nicely with [`@import … supports(…)`](https://github.com/w3c/csswg-drafts/issues/8399#issuecomment-1416907375) _(suggested by @plinss above)_ and [`link[media="supports()"]`](https://github.com/whatwg/html/issues/7540) _(something that was discussed for Cascade Layers)_. This extension to `@supports` doesn’t seem mandatory to be able to detect nesting though, as passing `selector(&)` will cover _“is nesting supported?”_ just fine as the reality is that nesting and `&` ship together. Yes, some pre-release versions of Chrome/Safari incorrectly claim (or don’t claim) support for `&`, but given that these are pre-releases or versions that require the user to enable a feature flag, I think it’s safe to assume that users of those versions update their browsers very often. -- GitHub Notification of comment by bramus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8399#issuecomment-1502946954 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 11 April 2023 09:01:23 UTC