[css-nesting-2] Syntax to customize how a nest-containing selector is resolved?

[flachware]

I’m very exited about the upcoming nesting feature (https://drafts.csswg.org/css-nesting/). But with nesting new troubles emerge. This is a proposal for a Sass-like :selector-replace() pseudo-class function that allows authors to modify the nesting selector &.

In complex user interfaces elements tend to have multiple states which depend in part on parent elements. The deeper an element is nested the more likely it becomes that you have to define a state that is based on a modified selector somewhere in the middle of the 'selector chain'.

Example:

.component {
  color: green;
  
  & .container {
    color: brown;
  }
  
  & .child {
    color: blue;
    
    &:hover {
      color: yellow;
    }
    
    &:selector-replace(.component, .component:focus) {
      color: red;
    }
    
    &:selector-replace(.component, .component .container.active) {
      color: white;
    }
  }
}

is equivalent to

.component {
  color: green;
}

.component .container {
  color: brown;
}

.component .child {
  color: blue;
}

.component .child:hover {
  color: yellow;
}

.component:focus .child {
  color: red;
}

.component .container.active .child {
  color: white;
}

In this simplified example the .child element has four states, two of these states depend on its ancestors. Of course this could be written by adding these states to .component and .container. But this would not be DRY and the .child styles start to scatter around, in the worst case you would have to replicate the nesting multiple times in various places just for one modified part at a time (and there would be a lot more nesting levels and elements in reality).

The proposed :selector-replace() pseudo-class function addresses this issue by allowing you to modify nested selectors wherever you need it. I do not propose that particular name, I think something like :mod() (modify) might make more sense with regard to brevity.

Disclaimer: I did not come up with this feature, it is part of Sass – for good reason.

[Loirooriol]

I would probably use something like

.component {
  color: green;
  --child-color: unset;
  & .container {
    color: brown;
  }
  &:focus {
    --child-color: red;
  }
  & .container.active {
    --child-color: white;
  }
  & .child {
    color: var(--child-color, blue);
    &:hover {
      color: var(--child-color, yellow);
    }
  }
}

[LeaVerou]

I find the proposed solution really difficult to read and process.

Indeed, what @Loirooriol suggests would address a lot of these use cases in a far more readable way, but not all, since the state often needs to toggle multiple properties with different types, that cannot (currently, see #5624 ) be toggled with one custom property.

I wonder if a better solution for those cases would be some way to reference the & of ancestor scopes (maybe &1, &2 etc?)

[flachware]

@Loirooriol that’s an interesting idea, but as @LeaVerou already pointed out, I’d like to define any type or number of properties for a given state (sorry for the overly simplified example). And in this case that approach would basically double the number of lines, as you have to define multiple custom properties in the parents and assign them in the child afterwards. Also, I believe that all styles belonging to the child should be defined in the child.

@LeaVerou I’m not totally opposed to reference different levels with something like &1 or &2, but I submit that this results in a tighter coupling – whenever you change the nesting these references might break silently.

[LeaVerou]

@LeaVerou I’m not totally opposed to reference different levels with something like &1 or &2, but I submit that this results in a tighter coupling – whenever you change the nesting these references might break silently.

Oh that's a good point, we don't want that.

I wonder then if it should be explicit: You'd declare a name for the & in the ancestor scope that would allow you to reference it in descendants and how.

E.g. something like:

.foo {
	scope-name: bar;

	& .bar {
		&bar:focus .baz {

		}
	}
}

Of course lots to figure out: where does & stand in &bar:focus .baz? Is there an implicit & between them? Would it still be mandatory to include & as well somewhere in the selector to make it explicit?

[flachware]

Would this be the equivalent?

.foo:focus .bar .baz { }

[LeaVerou]

That depends on how it's defined. I think & should still be mandatory in these selectors, because otherwise the meaning is very ambiguous. And yes, if it's &bar:focus & .baz then it should be equivalent to .foo:focus .bar .baz. Not sure how to define it so that it doesn't become .foo:focus .foo .bar .baz when that & is expanded though. 🤔

[flachware]

Ok, so if .foo:focus .bar .baz is the intended output, I think I would define it like this, following your proposal:

.foo {
  scope-name: foo;

  & .bar {
    & .baz {
      &foo:focus {
      
      }
    } 
  }
}

I guess you named the scope bar to make it clear that this is an arbitrary label. But in a real case you’d probably use part of the class name of the scope (foo)? And I think &foo:focus should go inside .baz, because this way you can also have .baz styles without the focus modifier.

In my understanding &foo:focus would mean: extend & to the full selector but modify the level the scope-name was defined at with :focus. I think there could only be one & otherwise you would double the selector.

The issues I see with this approach:

• This introduces a new scope-name property, that is merely used as an aid for the syntactical sugar of nesting. I’m not sure this is legit, I believe this would be a precedential case?
• I chose the original example above deliberately as it features an edge case: what if you didn’t just want to add a pseudo-class like :focus somewhere in the full selector but wanted to modify it with a more complex selector? E.g. how would you modify .foo .bar .baz to .foo .qux.active .bar .baz with the proposed approach?

The benefit of the originally proposed :selector-replace() function is that it can take selectors of any complexity as arguments.

I believe any solution will contain three ingredients: &, some kind of reference to the part you want to modify, and the actual modification. But let’s take a step backward. To be clear, I’m not attached to the original syntax, first and foremost I would like to come to an understanding in terms of the & nesting selector – I believe the draft of the nesting spec is incomplete. The & allows us to append something to the full selector, like:

.foo {
  & .bar {
    &:hover {
    
    }
  }
}

It also provides means to prepend something to the full selector, like:

.foo {
  & .bar {
    @nest :hover & {
  
    }
  }
}

And you can have media queries right in place (which is great for responsive layouts):

.foo {
  & .bar {
    @media (min-width: 768px) {
      & {
      
      }
    }
  }
}

So you can basically do everything you want within an existing nesting – except if the selector in question is accidentally part of the nesting. In this case the only way (currently) is to replicate the modified nesting (and that’s a bad thing for several reasons). It is kind of 'discriminatory' to the selectors that happen to be in the nesting:

.foo {
  & .bar {
  
  }
  
  &:hover {
    & .bar {
   
    }  
  }
}

So I think once nesting is introduced there should not only be means to prepend and append something to &, but also means to modify &. Are we on the same page here?

[Loirooriol]

I don't like being able to arbitrarily replace parts of parent selectors to something completely different. At that point I think you should just move that part outside of the nesting.

But being able to reference the elements matched by some ancestor rule (not just the parent) may be reasonable.

Using a property (or descriptor, I guess?) seems strange, though. I would add some syntax just after the selector, like

.foo => &(foo) {
  & .bar {
    & .baz {
      @nest &(foo):focus & {}
    }
  }
}

Note that &foo means &:is(foo), so we need a different syntax like &(foo), or change the spec:

The nesting selector is allowed anywhere in a compound selector, even before a type selector, violating the normal restrictions on ordering within a compound selector.

Also, I think you would still need to use a plain & in order to tell where the parent selector is.

[flachware]

I actually don’t necessarily want to replace parts of the parent selectors either, but I’d like to be able to insert arbitrary modifications. Would your proposed approach allow something like this:

.foo => &(foo) {
  & .bar {
    & .baz {
      @nest &(foo) .qux.active & {}
    }
  }
}

as an equivalent to this?

.foo .qux.active .bar .baz {}

I’m not sure about the &(foo) syntax though, I think the & should be used consistently as a representation for the parent selectors only.

And at that point I’m wondering why we couldn’t select the ancestor directly? This would modify all occurrences of .foo in &, but I think that’s ok, the same way any selector can match multiply elements:

.foo {
  & .bar {
    & .baz {
      @nest &(.foo):focus & {}
    }
  }
}

[Loirooriol]

as an equivalent to this? .foo .qux.active .bar .baz {}

Well, technically I think it would be like .foo .qux.active :is(.foo .bar .baz) {}. & matches the elements that match the parent selector. It doesn't directly insert a selector into another, you may need :is() if there are combinators.

I’m not sure about the &(foo) syntax though

&(foo) was just some random syntax different than &foo which has another meaning. Can be something else.

I believe the second & is actually not needed as (.foo) already makes it clear where the :focus belongs?

But it's not clear what's the relationship with .baz.

shouldn’t this then work with direct nesting without @nest?

Probably, if it's at the beginning, I guess.

[Loirooriol]

I guess a possible problem is if you have

<div class="foo"><div class="bar"><div class="foo"><p>Foo</p></div></div></div>

.foo => &(foo) {
  & .bar {
    & p {
      @nest &(foo):focus & {}
    }
  }
}

Then this will be like .foo:focus :is(.foo .bar p), meaning that it will match if e.g. the focus is on the inner .foo, but the author may want the focus to be on the .foo that contains the .bar.

[flachware]

Well but sadly in that case it’s kind of useless, you could simply write that with existing syntax:

.foo {
  & .bar {
    & p {
      @nest .foo:focus & {}
    }
  }
}

is equivalent to

.foo:focus .foo .bar p {}

This is prepending to &, but this issue is all about modifying & or rather inserting into &. So I’m looking for a way to achieve .foo:focus .bar p or .foo :focus .bar p.

[flachware]

I’m basically looking for something like that:

.foo {
  & .bar {
    & p {
      &:mod(:ancestor(.foo):focus) {} /* => .foo:focus .bar p */
    }
  }
}

[flachware]

@Loirooriol @LeaVerou I realize that if my claim that the nesting spec is incomplete holds true, then the conclusion must be to focus on the existing @nest & syntax and add more capabilities right there. Logically, there are three ways the nesting selector can change: A selector is prepended, appended, or inserted. So in addition to being able to append a selector to the nesting selector with @nest &:hover and prepend a selector with @nest :hover & merely by changing the order, I propose a way to append a selector to an ancestor within the nesting selector using a &() modifier.

.foo {
  & .bar {
    & .baz {
      &:hover {
        /* => .foo .bar .baz:hover */
      }
      
      @nest :hover & {
        /* => :hover .foo .bar .baz */
      }

      &(.foo:hover) {
        /* => .foo:hover .bar .baz */
      }
    }
  }
}

&(.foo:hover) would be processed from left to right, so the first selector .foo in the modifier would be used to find any ancestor in the nesting with that class name and then append :hover.

I believe that appending a selector to an ancestor is equally important as prepending a selector to the nesting selector and thus the burden to work around this situation should not be passed onto the users of CSS. Instead, there has to be a way that allows users to append selectors to ancestors right in place. Without a syntax that facilitates this, users have to recreate slightly modified nestings various times – which contradicts the whole point of nesting as an approach to avoid redundancy.