[csswg-drafts] [css-nesting] A proposal, using a pseudo-class (#5491)

matthew-dean has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-nesting] A proposal, using a pseudo-class ==
### :and()

**Related to the [CSS Nesting proposal](https://drafts.csswg.org/css-nesting-1/)...**

I was re-reading [this issue](https://github.com/w3c/csswg-drafts/issues/2937), in which I talked about the conflict between the CSS Nesting proposal and Sass / Less (/ PostCSS, etc)

I think the CSS nesting proposal can be satisfied without conflicting with Sass / Less, and more closely align with CSS, by the use of pseudo-class. **Specifically, replacing `&` with `:and()` (as an analog to `:not()`)**

It would be:
```css 
.component-1, .component-2 {
  :and():hover { a: b; }
} 
```
This would be the equivalent of:
```css
:where(.component-1, .component-2):hover { a: b; }
```
That is, like `:where()`, `:and()` would not add 0 specificity.

#### With `@nest`

Similarly, I think the proposal is right that the use of `@nest` is necessary to remove ambiguity, as in:

```css
.component {
 @nest tag:and() { a: b; }
}
```

This would be the equivalent of:

```css
tag:where(.component) { a: b; }
```

#### Using at root

If `:and()` is not nested, it would just collapse, as in, these two are equivalent, both in what they select, and in specificity:
```css
.component { }
.component:and() { }
```
#### Uses with Less / Sass / PostCSS

This proposal would allow co-mingling with languages that currently support `&`, as in, with this input:

```less
// Less code
.component {
  :and().component-2 { a: b; }
  &:hover { c: d; }
} 
```

The Less output would (could) be:
```css
.component {
  :and().component-2 { a: b; }
}
.component:hover {
  c: d;
}
```
In other words, it's no longer ambiguous whether or not rules should flatten, and there's no conflict between the meaning of `&` in the existing CSS Nesting proposal and [its (different) meaning in Sass / Less](https://github.com/w3c/csswg-drafts/issues/2937).

#### Other syntaxes

I used `:and()` vs `:and` because it seems more semantically similar to `:where()`, `:not()`, `:is()` etc; that is, that it's returning a selector to match, even if it doesn't have arguments. However, CSS spec authors may feel that `:and` is sufficient, as in:
```css
.component {
  :and:hover {}
}
```
My feeling was also that arguments may be added to `:and()` in the future, such as partial matching of selectors, but CSS spec authors may disagree.

Another syntax possibility I considered, for brevity, would be something like an empty pseudo-class, as in `:()`.

As in: 
```css
.component {
  :():hover {}
}
```
This has the drawback of no longer being a valid pseudo-class, but may be an improvement over `&`.

#### Changes to CSS parsing

Obviously, like the CSS Nesting proposal with `&`, a change would be needed to allow the "and identifier" at the start of a rule, but unlike the `&` proposal, IMO this change is not a significant, since `:and()` is a valid selector.

---

Thoughts welcome.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5491 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 2 September 2020 17:55:12 UTC