- From: Bramus! via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Apr 2023 09:03:09 +0000
- To: public-css-archive@w3.org
> It wasn't a pre-release version of Chrome that incorrectly claimed to support `&` :) True. There’s [a workaround](https://github.com/w3c/csswg-drafts/issues/8399#issuecomment-1427847117) – which covers all browsers – I mentioned before, but admittedly it’s a nasty hack. > There also isn't a way to differentiate between what shipped in Chrome 112 and the highly likely direction of the specification If more robust/reliable feature detection through _< method-this-issue-settles-on >_ lands, Chrome 112 wouldn’t support that new detection method, so it would still get the non-nested styles because it has a more limited nesting support. --- Rewinding a bit. Say the suggested `@import … supports(…);` lands. Currently using those statements in any browser does not load any of the referenced CSS files, as they don’t understand the statements. ```css @import "nested-and-small.css" supports(<method-to-detect-nesting>); @import "not-nested-and-large.css" not supports(<method-to-detect-nesting>); ``` That means, the snippet above won’t cut things here: - Browsers that support `@import … supports(…);` + nesting will load `nested-and-small.css`. - Browsers that don’t support `@import … supports(…);` will load none of those files. What is parseable is, is this … but then you’d end up with double loads + competing stylesheets in browsers that do support `@import … supports(…);` ```css @import "not-nested-and-large.css"; @import "nested-and-small.css" supports(<method-to-detect-nesting>); ``` Not sure how this could be solved in a nice way 🤔 -- GitHub Notification of comment by bramus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8399#issuecomment-1504918303 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 April 2023 09:03:11 UTC