[css-nesting] selecting grandparent selector with @nest

[lubomirblazekcz]

The current spec might seem to have missing grandparent selector, which is also very used feature in many preprocessors.

This is currently still possible with postcss-nesting, with noIsPseudoSelector: true option. Which results in following:

.a {
  color: blue;
  & .b {
    @nest :not(.c)& {
      color: red
    }
  }
}

.a:not(.c) .b {
    color: red;
}

This is also the same way Less uses grandparent, and Sass uses @at-rule

.a {
  color: blue;
  .b {
    :not(.c)& {
      color: red
    }
  }
}

.a:not(.c) .b {
    color: red;
}

My question, is this something that should also be added to spec? Becuase I didn't find any mention of this in there. Or should some different syntax be proposed for selecting gradparent selector? Any thoughts on this @tabatkins ?

This issue is also related to grandparent selector - #6330

Also related postcss issue here - csstools/postcss-plugins#195 and supposedly grandselector syntax that previously worked in postcss-nesting was a bug

Current way that works in postcss-nestning is following, which I am not sure if is corect

.a {
  color: blue;
  & .b {
    @nest .a:not(.c) & {
      color: red
    }
  }
}

.a:not(.c) :is(.a .b) {
    color: red;
}

[romainmenke]

Adding a bit more context from postcss-nesting plugin.

The example above fed to the plugin.

pbpaste | npx @csstools/csstools-cli postcss-nesting --no-map

Source

.a {
  color: blue;
  & .b {
    @nest :not(.c)& {
      color: red
    }
  }
}

Result

.a {
  color: blue
}

:not(.c):is(.a .b) {
  color: red
}

---

pbpaste | npx @csstools/csstools-cli postcss-nesting --no-map --plugin-options '{ "noIsPseudoSelector": true }'

Source

.a {
  color: blue;
  & .b {
    @nest :not(.c)& {
      color: red
    }
  }
}

Result

.a {
  color: blue
}

.a:not(.c) .b {
      color: red
}

---

This behaviour is not intended as a feature or an operating mode.

The flag exists to give CSS authors the option of having CSS output without :is() selectors. This was added because browser support for :is() is not good enough yet.

We could do a better job explaining that this flag should be avoided as it introduces two issues : specificity and complex selector matching.

see : https://github.com/csstools/postcss-plugins/tree/main/plugins/postcss-nesting#noispseudoselector

Currently it reads more like a feature if you do not have in depth knowledge of the nesting spec.

---

There is now also a plugin for :is() which can almost match specificity behaviour of :is(). This works well enough and is better than not doing anything for specificity.

see : https://github.com/csstools/postcss-plugins/tree/main/plugins/postcss-is-pseudo-class#%EF%B8%8F-known-shortcomings

However for complex selectors there is not much we can do.
It is not possible to write a selector transform that removes :is() and always matches the intended element. If there was a way we would not have needed :is() in CSS.

---

Part of the issue here (imho) is that nesting has existed for so long in CSS pre-processors and that there are certain expectations of how it work. These do not always match the actual spec.

Without any actual implementation CSS authors also do not have a good reference point.

Maybe more can be done to explain and illustrate the feature for CSS authors?

---

I think the suggestions by @LeaVerou in #6330 are really insightful and would introduce an explicit mechanism to reference the selector you intend.

[lubomirblazekcz]

The suggestions by @LeaVerou in #6330 are insightful yes, but maybe to much complex. To be clear, following behaviour in postcss was working even prior noIsPseudoSelector

.a {
  color: blue;
  & .b {
    @nest :not(.c)& {
      color: red
    }
  }
}

.a {
  color: blue
}

.a:not(.c) .b {
      color: red
}

That why I though it was something that was part of the spec previously. Which is not the case, hence why I've created this issue. I think this syntax for selecting grandparent is less complex and it would benefit the spec.

There are a lot of cases where this might be useful, for example

.ui-input {
  & input {
    @nest :not(.is-active)& {
      color: red
    }
  }
}

.ui-input:not(.is-active) input {
    color: red;
}

Once you are nested little deeper (for example in pseudo selector too), you have no simple clear way of accessing parent selector, for example component with different states.

Here are also some real world examples in UI library written in nesting syntax - https://github.com/newlogic-digital/ui/blob/main/src/styles/Ui/Input.css#L200

[romainmenke]

Can you clarify with comments in your source CSS which selector each & would become?

To me it is not fully clear what "selecting grandparent" means.
As I currently interpret it :

.grandparent {
  & .parent { /* "&" references ".grandparent" */
    & .child { /* "&" references ".grandparent .parent" */
      color: red;
    }
  }
}

Only set a style on .child if .grandparent matches :hover.

.grandparent {
  & .parent { /* "&" references ".grandparent" */
    @nest .grandparent:hover & .child { /* "&" references ".grandparent .parent" */
      color: red;
    }
  }
}

equivalent to .grandparent:hover :is(.grandparent .parent) .child

---

But then a new addition to the spec to write this without needing to add .grandparent.

Taking the first example from #6330 :

.grandparent {
  & .parent { /* "&" references ".grandparent" */
    /* "&1" references ".grandparent" */
    /* "&" references ".grandparent .parent" */
    @nest &1:hover & .child { 
      color: red;
    }
  }
}

This final example would be equivalent to :

.grandparent:hover :is(.grandparent .parent) .child

Which matches this html

<div class="grandparent">
  <!-- possible with extra html elements in between -->
  <div class="parent">
    <!-- possible with extra html elements in between -->
    <div class="child"></div>
  </div>
</div>

[lubomirblazekcz]

I just found out that following syntax is also possible to select grandparent in postcss-nesting, but it is still something that should be added to the spec to clear things up, if it's the correct way to do this.

grandparent {
  & .parent { /* "&" references ".grandparent" */
    @nest :hover > & .child { /* "&" references ".grandparent .parent" */
      color: red;
    }
  }
}

equivalent to :hover > :is(.grandparent .parent) .child

And to be honest, according to spec I would expect the result be :hover > .grandparent .parent .child, which would not be good for this case obviouslly.

It might be possible to select grandparent, but it might not.. it's not very clear in spec right now.

EDIT:
@romainmenke your examples are correct, my only concern is if the wraping the parents in :is. It's something that is not very clear in spec It is also the important part for grandparent selection to work.

[romainmenke]

And to be honest, according to spec I would expect the result be :hover > .grandparent .parent .child, which would not be good for this case obviouslly.

Can you reference the spec sections that imply this?
Maybe these are not well defined yet?

---

grandparent {
  & .parent { /* "&" references ".grandparent" */
    @nest :hover > & .child { /* "&" references ".grandparent .parent" */
      color: red;
    }
  }
}

This can have unexpected effects.

works as intended :

<div class="grandparent"><!-- CSS matches when this is hovered -->
  <div class="parent">
    <div class="child"></div>
  </div>
</div>

does not work as intended :

<div class="grandparent">
  <div class="other"><!-- CSS matches when this is hovered -->
    <div class="parent">
      <div class="child"></div>
    </div>
  </div>
</div>

[lubomirblazekcz]

@romainmenke yes that is what I mean, it is not well defined.

According to spec, there is no wrapping :is here for example

Also you are correct, that solution could have unexpected effect, hmm :/

[LeaVerou]

First, I have to say I keep stumbling on use cases for this. Things like:

.container {
	& .widget {
		@nest .container.selected & {
			/* FAIL, gets rewritten to .container.selected .container .widget, 
			   not .container.selected .widget */
		}
	}	
}

Also, I agree my proposal in #6330 (comment) is overkill. Also, it introduces a CSS property that is not actually applied on any elements, but is just used to evaluate syntax. Yikes.

Instead, I think we should go for a simpler solution, with predefined names for going up 1, 2, 3, ... levels. Perhaps &1, &2, &3 etc. Then the example above would become:

.container {
	& .widget {
		@nest &1.selected & {
			/* Gets rewritten to .container.selected .widget */
		}
	}	
}

Is &1 cryptic? Yes. But it isn't more cryptic than & itself, and it kinda reminds me of $1, $2 etc in JS string replacement.

[lubomirblazekcz]

Whatabout :parent pseudo-class? Same as your proposal, but maybe more cleaner syntax.

.container {
	& .widget {
		@nest &:parent.selected {
			/* Gets rewritten to .container.selected .widget */
		}
	}	
}

Still this as an advanced usage, and maybe needed only in few cases.

Selecting top level grandparent is much common use as I mentioned previously. But that is not clear if it's possible with the current spec or not - that is my main concern

[romainmenke]

@LeaVerou

.container {
	& .widget {
		@nest .container.selected & {
			/* FAIL, gets rewritten to .container.selected .container .widget, 
			   not .container.selected .widget */
		}
	}	
}

Doesn't that get rewritten to this :

.container.selected :is(.container .widget)

Which would actually match this :

<div class="container selected">
  <div class="widget">

---

.container {
	& .widget {
		@nest &1.selected & {
			/* Gets rewritten to .container.selected .widget */
		}
	}	
}

Becomes :

:is(.container).selected :is(.container .widget)

or :

.container.selected :is(.container .widget)

[romainmenke]

@lubomirblazekcz

#6977 (comment)

According to spec, there is no wrapping :is here for example

These example mostly have simple selectors, no compound or complex selectors.
Writing them with or without :is() is equivalent.

The example with .bar .foo.baz is indeed confusing.
It happens to work without :is() because the next bit is a simple selector and there is no combinator in between.

Maybe it should be written as : :is(.bar .foo).baz.

[Griffork]

Instead, I think we should go for a simpler solution, with predefined names for going up 1, 2, 3, ... levels. Perhaps &1, &2, &3 etc. Then the example above would become:

.container {
	& .widget {
		@nest &1.selected & {
			/* Gets rewritten to .container.selected .widget */
		}
	}	
}

Is &1 cryptic? Yes. But it isn't more cryptic than & itself, and it kinda reminds me of $1, $2 etc in JS string replacement.

Personally if you're going to go the &1, &2, &3 route I'd argue that & should be all of them and &0 should be the last child selector, so

 .container {
 	& .widget {
		@nest &1.selected &0 {
/* Gets rewritten to .container.selected .widget */

 .container {
 	& .widget {
		@nest &.selected {
/* Gets rewritten to .container .widget.selected */

The & referring to the whole of the parent selector is the most common use-case, users shouldn't have to write long chains of & that match exactly how many nested selectors there are just to add another selector on the end, instead use &0 to get the last selector without the previous.

Because forcing this is a recipe for disaster:

.container {
    & .widget {
         &1 &.selected {
              &2 &1&:hover {
/* Becomes .container .widget.selected:hover */

Particularly if you have to remember which ones have spaces and which ones don't.

Unless the suggestion is that & always includes the parent selector except if &1 (or another number is present) which I think is unnecessarily inconsistant and confusing when you could just use &0 for that.

Most of the bugs resulting from & changing behaviour would occur when refactoring.

[romainmenke]

The & referring to the whole of the parent selector is the most common use-case, users shouldn't have to write long chains of & that match exactly how many nested selectors there are just to add another selector on the end, instead use &0 to get the last selector without the previous.

@Griffork I think there is some confusion here :)

In general I don't think it is or should be possible to start writing a completely unrelated selector with nesting.

For example :

.container {
	& .widget {
		@nest &1.selected {
			color: red;
		}
	}	
}

@nest &1.selected should be invalid as it doesn't contain &.
Logically it might resolve to .container.selector but it would not make sense to support this in the spec in my opinion.

You can simply write this :

.container {
	&.selected {
		color: red;
	}	
}

The issue brought up here is that you might want to manipulate two parts of a selector when nesting.

example :

Only apply a color to .widget on :hover when .container is .selected.
You might want to write this in the same nesting blocks.

Works with todays spec :

.container {
        /* base styles for .container */
	& .widget {
		/* base styles for .widget in .container */

                &:hover {
                  /* base styles for .widget:hover in .container */
                }
	}

	&.selected .widget:hover {
		color:red
	}
}

Or :

.container {
        /* base styles for .container */
	& .widget {
		/* base styles for .widget in .container */

		&:hover {
			/* base styles for .widget:hover in .container */

			@nest .container.selected & {
				color:red
			}
		}
	}
}

But in both cases you have repetition of either .container or .widget.
Something like @nest &<N>.selected & would remove this repetition.

It would not change how & works or should be used.

[romainmenke]

@lubomirblazekcz relevant comment on the use of :is() : #2881 (comment)

[lubomirblazekcz]

@romainmenke I see, but it's still something that is not very clear in spec here - https://www.w3.org/TR/css-nesting-1/#direct and that was my main concern