- 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