[css-nesting-1] Nesting conditional rules

[sesse]

Hi,

I'm working on implementing css-nesting-1 (and I hear @emilio is doing the same for Gecko). Most of the standard is fairly straightforward, but this section gives us pause:

https://csswg.sesse.net/css-nesting-1/#conditionals

This kind of free-form nesting causes a fair bit of headaches for us; we don't represent style rules and the various @media etc. stuff using the same structures in the stylesheet, and untangling that would be a fair bit of work for what seems to be a small gain. It seems also that we'd need to start merging media queries, since this kind of syntax encourages spreading them around the stylesheet N times. Finally, this allows properties directly into @media for the first time (with an implicit & selector wrapped around it), which looks pretty strange compared to how CSS looks and feels normally?

It's not impossible for us to support, but it's entirely possible that we'll implementing this part even it if remains in css-nesting-1. It would be nice to take it out or punt to a future level (css-nesting-2), though.

[sesse]

Seemingly this was first requested in #2891, for reference.

[sesse]

Also, “that we'll implementing this part” should of course be “that we'll skip implementing this part”.

[tabatkins]

This feature is pretty commonly used and useful in Sass; it means you can add MQ-specific properties without having to repeat your selector. (If you do it a bunch you repeat the MQs, but which of those is clearer or easier in your code varies on exact usage.)

[tabatkins]

But punting at-rule nesting might be possible, especially since we want to make sure we're complete and consistent in the feature (allowing nesting of @layer, @scope, etc as well). Letting Level 1 just be the basic nesting to avoid blocking while we work on the rest of the details sounds fine to me.

[romainmenke]

Authors might be confused if this is split up.
Nesting is often used to group related code within a single rule.

.my-component {
  /* base styles */
  color: green;


  /* states */
  &:hover {
    color: yellow;
  }

  /* responsive */
  @media (prefers-color-scheme: dark) {
    color: lime;
  }
}

Not being able to nest conditional rules would prevent a significant number of authors from using nested css in browsers and would still rely on tooling to downgrade.

Making tools like PostCSS Nesting capable of partially downgrading would also be terribly complex.

---

Would it be technically possible to detect support for nested conditionals alone?
I always assumed that something like @supports selector(&) could be used to detect nesting support (maybe it doesn't).

[sesse]

We'd definitely need to have a long, hard think about implementation before we implement this as part of css-nesting-1, at least :-) Even if authors may find it useful, it is potentially as much work for us to implement as the rest of the spec combined. (This is a very rough estimate based on initial impressions; don't hold me to it.)

[bradkemper]

I really would prefer @media is included in nesting level 1. It is such a common and powerful thing in SASS, and one of the big benefits of nesting.

[LeaVerou]

untangling that would be a fair bit of work for what seems to be a small gain.

Not a small gain at all, this is fairly commonly used in Sass and PostCSS, as it allows authors to keep related parts together.

[romainmenke]

We'd definitely need to have a long, hard think about implementation before we implement this as part of css-nesting-1

Given the complexity of the feature and how it will effect future feature additions I do understand the need to split this up.

If splitting it up is the best way to get a solid implementation in the end, then we (making the PostCSS plugins) will obviously do our best to support this. A specific fallback for at rules alone is possible.

[SebastianZ]

A little note aside from the discussion. Could you all please make sure to wrap your at-rules in back ticks here on GitHub to avoid pinging people unrelated to the CSSWG?

Sebastian

[tabatkins]

Agenda+ to discuss if it's okay to do an initial ship of Nesting without nested at-rules, or if we should punt this entire feature to level 2.

[fantasai]

I think the choice is whether to punt it or not. If we're punting it, it should split out into L2 so that L1 represents what authors can use.

[bramus]

Would prefer to have nested at-rules in L1, as it feels like the natural thing to do while trying out nesting.

I guess the decision is dictated by to the outcome of #7850 (comment), or are there other hurdles I’m overlooking right now?

[sesse]

FWIW, we've implemented this in Chromium (with the workarounds in #7850, adding implicit & {}); it was easier than we originally thought.

[css-meeting-bot]

The CSS Working Group just discussed [css-nesting-1] Nesting conditional rules, and agreed to the following:

• RESOLVED: Close no change

The full IRC log of that discussion

<fantasai> TabAtkins: implementer in Chrome was wonering if we could punt conditional rules to L2, but he ended up implementing and it wasn't that ba anyway
<fantasai> ... so proposal is to close this no change
<fantasai> RESOLVED: Close no change

[sircumferencee]

Looks like the resolution is to close this issue