- From: Pierre-Yves Gérardy via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Feb 2020 12:53:27 +0000
- To: public-css-archive@w3.org
While exponentially large Cartesian products can be problematic, the current spec also has drawbacks:
1) It lends itself to priority hacking `:is(.foo, a:is(b#cant-match-but#lots-of#dummy#ids))` lets one match only `.foo` with a very high priority. Not sure if it is a feature or a bug...
2) it can't be accurately polyfilled
```CSS
:is(.foo, #bar) {color: red;}
.foo {color: blue;}
```
gives a red `.foo`, but a manual expansion to
```CSS
.foo {color: red;}
#bar {color: red;}
.foo {color: blue;}
```
gives a blue one. (Expanding to multiple rulesets because `:is()` is fault tolerant, unlike the plain selector lists).
This can be mitigated per sheet, but if the definitions are in distinct sheets it will bite people.
3) The way nesting with `&` is currently implemented in SASS and Postcss also involves Cartesian products. Since `&` defers to `:is()` (well, the [spec](https://drafts.csswg.org/css-nesting/#at-nest) still has `:matches()` :-) not sure where to file a PR) porting nested sheets to native nesting will be hazardous (beyond the fact that native nesting doesn't support BEM-like `&-foo`).
If instead you went for a Cartesian product approach, (maybe with an expansion limit for sanity), these three concerns would be addressed.
--
GitHub Notification of comment by pygy
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3325#issuecomment-582892410 using your GitHub account
Received on Thursday, 6 February 2020 12:53:30 UTC