[css-nesting-1] nesting limited to conditional styling of the current element (another proposal)

[romainmenke]

The points by @mirisuzanne about the overlap between @scope and nesting made me consider another possible direction for nesting.

I think the main takeaway here is that we need to keep thinking of these features as intertwined. Specifically, the implementation of scope might change what people need or want from nesting.

All current proposal are based on what is done in preprocessors and try to make some version of that work in a browser context. None of them consider the existence and use cases of @scope.

The feature in preprocessors can be roughly split in these groups :

1. templating to construct BEM style selectors
2. grouping styles for different elements but all part of the same component
3. grouping conditional styles for the same element
4. side effects of the lax syntax in preprocessors
5. reduce repetition

1. templating to construct BEM style selectors

Examples :

• &__element
• &--modifier

This is not part of any of the proposals because it can not (and should not) be implemented.
Authors however use this a lot.

The underlying need is that @scope doesn't exist (yet) and that BEM and friends are popular ways to style a component without leaking style to other parts of the document.

& templating reduces the amount of writing for authors.

I however think this could remain a preprocessor feature.
That it can not be implemented in browsers doesn't mean that authors are not allowed to have a tool to help them write repeated bits in selectors.

2. grouping styles for different elements but all part of the same component

Example :

.my-component {
  display: flex;
  gap: 3rem;
  margin: 2rem;


  .column {
    width: 50px;

    &.column--left {
      text-align: right;
    }

    &.column--right {
      text-align: left;
    }
  }
}

This source code is still flawed and authors will still need to use things like BEM because the html might look like this :

<div class="my-component">
  ...
    <div class="column">
      ...
        <div class="other-component">
          ...
            <div class="column">

The second .column is completely unrelated to .my-component but it will still match .my-component .column.

@scope solves this and removes the need for BEM methodologies.

3. grouping conditional styles for the same element

Example :

.element {
  color: blue;

  &:hover {
    color: pink;
  }

  &:has(img) {
    color: cyan;
  }

  &.element--red {
    color: red;
  }

  @media (prefers-color-scheme: dark) {
    color: yellow;
  }

  @supports (color: oklch(...)) {
    color: oklch(...);
  }
}

This is the one thing where I think nesting truly shines and it is something that isn't made obsolete by @scope.

4. side effects of the lax syntax in preprocessors

Examples :

.element {
  & + .bar {
    /* writing CSS inside `.element` but the matched element is a sibling */
  }
}

.element {
  :not(&) {
    /* writing CSS inside `.element` but the matched elements are everything except `.element` */
  }
}

It is at least unusual that a nested block can be reached/executed for conditions where the outer block can not.

if (foo) {
  if (!foo) {
    /* unreachable */
  }
}

@media screen {
  @media not screen {
    /* unreachable */
  }
}

I am not convinced these types of selectors are needed.
I am sure that someone will have found a use for them, but are they really needed and do they really help?

5. reduce repetition

Example :

h1, h2, h3, h4, h5 {
  /* styles for headings */

  @media (min-width: 300px) {
    /* styles for headings */
  }

  & + p { /* repeating the selector manually is a lot of work, easier to add "+ p" here */
    /* styles for paragraphs that follow headings */
  }
}

Nesting allows authors to reduce repetition of selectors.
In general I think this is a good thing but I am unsure if it must be tied to nesting.

Can we reduce repetition outside of nesting?
Isn't @custom-selector the better solution to this?

This is much more in line with what exists in other contexts/programming languages.
If you want to reuse something you first assign it to a variable.

@custom-selector :--h h1, h2, h3, h4, h5;

:--h {
  /* styles for headings */

  @media (min-width: 300px) {
    /* styles for headings */
  }
}

:--h + p {
  /* styles for paragraphs that follow headings */
}

Having nesting as the tool to reduce repetition means that people will nest code for this alone. Code they might not nest if @custom-selector was supported.

---

Proposal

This makes me wonder how nesting could look like if it had never existing in preprocessors and if we had @scope in all browsers today.

Would this be sufficient?

• only nest at rules which affect the matching or priority of the parent rule (no @property, ...)
• selectors in nested rules can only be compound selectors containing only pseudo selectors¹
• & doesn't exist
• @nest doesn't exist

Allowed at rules :

• @media
• @supports
• @layer
• @container
• ...

In other words, nesting is only a mechanic to "filter" the elements matched in the parent block.

• it is simple to learn, both syntactically and which elements will match.
• it is consistent
• it is expressive

@scope (.my-component) {
  :scope {
    /* declarations */

    :hover {}

    @media (min-width: 300px) {}
  }
  
  .element {
    /* declarations */

    :focus {}

    :is([data-theme=red]) {}

    :has(img) {}
  }
}

equivalent to :

@scope (.my-component) {
  :scope {
    /* declarations */
  }

  :scope:hover {}

  @media (min-width: 300px) {
    :scope {}
  }
  
  .element {
    /* declarations */
  }

  .element:focus {}

  .element:is([data-theme=red]) {}

  .element:has(img) {}
}

The downside of anything in this direction is that authors will dislike it today.
@scope must have been widely adopted before a version of nesting with these limitation will be perceived as useful.

Footnotes

1. The requirement for all pseudo's is debatable and the same restrictions as exist in proposal 3 would work. I personally like :is(..) and :has(...). ↩

[mirisuzanne]

I do like breaking it down into individual grouped use-cases like this to get a clearer view. There are a few small nits, like @layer is partly designed for handling the interactions of 'conditional styles for the same element', so it would be a mistake to exclude that from nested contexts.

That said, your proposal still allows basically any selector, since :is & :where are able to capture the relationships in category 4 - it's just opinionated about where those selectors live. I'm not sure there's much reason to limit what can go inside them, beyond existing limitations?

On first glance, I feel like I could accomplish most of what I need with this general approach, but I might be missing something. Most interesting to me:

• the selectors that might be copied into a nested context as-is all fall into the category of @scope-able, and so they just work without adjustment
• the selectors that require some special handling with a pseudo-class are the sort of thing you couldn't copy/paste into a nested context anyway, because they require more careful integration.

[romainmenke]

There are a few small nits, like @layer is partly designed for handling the interactions of 'conditional styles for the same element', so it would be a mistake to exclude that from nested contexts.

I didn't consider this and you are right @layer is useful in this context.

I do however think it makes sense to limit the types of at rules.
I don't think it makes sense to nest at rules which declare globals like @property.

Updated this in the proposal

---

That said, your proposal still allows basically any selector, since :is & :where are able to capture the relationships in category 4 - it's just opinionated about where those selectors live.

It does really enforce limits.
It would be impossible to match elements in a nested rule that weren't matched in the outer rule.

That is why & can be omitted. There is no need to express the relationship between the outer and inner selector in this proposal.

.foo {
  .foo + bar {} /* invalid, is a complex selector */
}

.foo {
  :is(.bar + .foo) {}
}

.foo {
  :not(.foo) {} /* never matches anything */
}

equivalent to :

.foo:is(.bar + .foo) {}

.foo:not(.foo) {} /* never matches anything */

Today this would be seen as a massive downside compared to nesting in preprocessors.
But I am curious how it would be perceived after having @scope in browsers for a few years.

---

but I might be missing something.

Pseudo elements :)

I want these to be allowed, but they are tricky things and change the rule.

.foo {
  ::before {}
}

equivalent to :

.foo::before {}

So this affects something that isn't .foo.
But this might be a technical distinction most authors won't make.

[tabatkins]

I strongly disagree that your Category 4 is just "lax syntax in preprocessors". The underlying reason for Nesting to exist is to reduce repetition. Whether this repetition exists because you're repeatedly styling the same element with different more specific things, or styling descendants of the element, or styling siblings and other things, is irrelevant; they're all addressed exactly equally by Nesting, and that's a strength of the feature.

Losing those other categories would be a huge limitation and render the feature much less attractive.

[romainmenke]

I strongly disagree that your Category 4 is just "lax syntax in preprocessors". The underlying reason for Nesting to exist is to reduce repetition.

I added 5 reduce repetition as a specific category.
You are right that there is a need for this outside of the other categories.

I had something very specific in mind with 4 but I clearly didn't express that well :)
I have added more comparisons which might help?

---

Losing those other categories would be a huge limitation and render the feature much less attractive.

I think this can be considered for CSS as a whole.
Which is why other features like @scope and @custom-selector could be taken into account.

Does CSS as a whole meet the needs previously filled by nesting in preprocessors?

This in contrast with :
Does nesting in browsers meet the needs previously filled by nesting in preprocessors?

[tabatkins]

No, CSS as a whole does not meet the full needs.

The purpose of nesting, the reason it exists in preprocessors, is that it reduces repetition when you're writing a bunch of selectors that elaborate on a base selector. Exactly what that elaboration is doesn't matter; the point is that in all scenarios, you have some base selector, and you're adding more stuff to it.

As already mentioned, @scope is not sufficient for this. You can use it for some uses, but only ones where the target elements are the same as the parent elements or descendants of them. This restriction makes sense when you're trying to define a styled component; that's a semantically meaningful thing, and intrinsically carries a notion of containment. But when you're not trying to do that, just trying to write some selectors without repeating yourself a bunch, it's an odd restriction.

@custom-selector isn't sufficient for this, either. In theory it has all the necessary functionality, but it doesn't have the right shape. Custom selectors also carry semantic meaning - they have a unique-across-the-whole-page name, they live separately from any particular rule, etc. Using them instead of Nesting would be incredibly awkward - I request that you attempt to convert any non-trivial real-world usage of Nesting into using @custom-selector, and see how far you get before you start just using junk names, especially for the second or third level of nesting in a rule. ^_^

[romainmenke]

I agree and I think this is a good description :

This restriction makes sense when you're trying to define a styled component; that's a semantically meaningful thing, and intrinsically carries a notion of containment.

I think that the combination of this proposal with @scope and @custom-selector does fully cover the needs, but only within a single coding style or methodology.

That is not a good thing, it will only work well for a small group of authors and only when doing specific tasks.

The other proposals don't have this problem.

---

reduce repetition

I think ultimately nesting is mostly about reducing friction when writing CSS.

Nesting in proposal 3 is a really awesome writing tool.
It allows you to write linearly, carrying the meaning/context of & as you add more bits.

To add a @custom-selector you need to do these steps :

• add @custom-selector :--foo .foo, .fooz, ...; add the top of the file or grouped in a specific file
• replace other instances of the selector with :--foo.
• continue writing more code

This is a lot of friction compared to just writing &.
This friction is also immediate, from the first level of nesting.

This is subtly different from purely reducing repetition.
In a way having & everywhere is a lot of repetition but it doesn't have any friction.

---

Proposal 3 can arguably make the final source code problematic for code reviews, refactoring, ...
Having to figure out the meaning of & in non-trivial examples during code review can be painful.
(this is shared with preprocessor nesting and all other proposals)

I personally favor readability over ease of writing which is also why something like this proposal is appealing to me.

---

Proposal 3 is easy to write but can lead to less-readable code.
linters can help teams keep code readable for each other, which can make this a non-issue

Proposal 4 is problematic because it is harder to write and harder to read.
requires a very specific code format to make it somewhat readable

Proposal 5 is problematic because it is harder to write.
requires going back and changing previous bits of code

This proposal is problematic because it is harder to write.
requires going back and changing previous bits of code, same as 5
sacrifices a lot of functionality

---

To summarize, I agree with @tabatkins that this will not work in practice.

• @scope does have significant overlap with nesting
• some pieces could be considered better written using @scope, @custom-selector and only minimal nesting
• full feature of nesting has benefits that no other feature can replace

[romainmenke]

This is no longer relevant