Bug-proof the group- modifiers by allowing safe nesting of .group elements

[MichaelAllenWarner]

A subtle problem with the group- modifiers is that .group elements generally can't be safely nested (because, e.g., .group-hover: classes within the inner .group will activate when the outer .group is hovered). See this recent discussion for an illustration of the problem: #7541. As I mention in a comment there, the problem can be hard to spot in development, since the outer and inner .group stuff might be in completely separate files!

I propose replacing the simple `:merge(.group)${result} &` selector with something that can withstand a layer or two of nested .group elements.

This array of selectors in an addVariant() would allow for one layer of nesting:

[
  `:merge(.group)${result} &:not(.group .group *)`,
  `.group :merge(.group)${result} &`
]

And this allows for two layers of nesting (overkill maybe?):

[
  `:merge(.group)${result} &:not(.group .group *)`,
  `.group :merge(.group)${result} &:not(.group .group .group *)`,
  `.group .group :merge(.group)${result} &`
]

I'm not sure if I've handled the :merge() business correctly (I think @RobinMalfait would know), but the basic idea is to stop each .group element from affecting any .group- classes within .group descendants. Here is a working demo with two layers of nesting: https://play.tailwindcss.com/LLuZ71wHxA

[adamwathan]

Hey! Interesting idea for sure — I’ve been planning to solve this for a long time using a different approach, which is named groups. Originally just having group-a, group-b, etc, but now with arbitrary value support in Tailwind I’m hoping to get things to a point where you can have arbitrary identifiers, like group-[wrapper]-hover:.

My gut is that this is gonna be more flexible but does have the disadvantage of still having potential naming collisions if you don’t know about groups in the parent tree. Feels low risk to me though — even in the 500+ templates we’ve built for Tailwind UI we’ve never hit a situation where we needed nested groups so I think it’s already pretty rare.

[MichaelAllenWarner]

Interesting. The solutions aren't mutually exclusive—i.e., could add a named-group feature for flexibility and also give the vanilla group a nesting failsafe (if desired). Could even give the named-group feature a nesting failsafe (to preempt naming collisions):

[
  `:merge(.group-\\[name\\])${result} &:not(.group-\\[name\\] .group-\\[name\\] *)`,
  `.group-\\[name\\] :merge(.group-\\[name\\])${result} &`
]

[onmax]

I just developed a new plugin very similar to this one that has all Tailwind 3 features.

Check it out here: https://github.com/onmax/tailwindcss-labeled-groups

[MichaelAllenWarner]

@onmax @adamwathan

The named-group solutions certainly work, and there's something to be said for them if you find yourself facing the nested-groups problem in a single file, where you know there's a conflict as you're developing.

What I don't like about the named-group approach is that it adds some conceptual overhead to solve a problem that rarely comes up in practice. It also doesn't really solve the conflicting-groups problem when the .groups in question occur in different files. Or rather, it can solve the problem once you're aware of it, but the across-files situation is where the conflict can easily escape your notice during development and lead to a bug in production.

For these reasons, I prefer my selector-approach upthread that simply gives the plain-old group- modifier a safety net, allowing for one or two nested layers (at the cost of a little more CSS). It's not perfect, but again, the problem is uncommon, and this would solve it for the vast majority of cases.

I also think a parent- modifier that uses the child-combinator (>) is worth considering. Wouldn't always suffice, but using it where it does would sidestep the nested-group problem entirely.

[MichaelAllenWarner]

@onmax

Yes, I'd like to see your example!

And to be clear: I wasn't trying to say that there isn't a place for a named-group mechanism like your plugin provides. For example, my selector-based approach does not allow something inside the inner .group to be affected by the state of the outer .group (the whole point is to prevent this from happening!). For that, you need something like named groups.

My comment was more about what should maybe be included in Tailwind's core, or at least what should be prioritized. IMO, the issues here are the following, ranked from most pressing to least:

1. the risk of bugs creeping in because you've accidentally nested .groups (across files), or because you're simply not aware that .groups can't be safely nested;
2. developers who understand how .group works might want to nest them in the "obvious" way (where what's inside the inner .group is not affected by the state of the outer .group);
3. developers who understand how .group works might want to nest them in the more complicated way (where what's inside the inner .group can be affected by the state of the outer .group, if desired).

Issue 3 is really where something like named-groups become necessary. A plugin is great for that, and maybe it should even be incorporated into Tailwind's core. But I think issues 1 and 2 are more important, and, unless I've overlooked something, they're also the low-hanging fruit: my selector-approach would solve them for the vast majority of cases, without introducing any new concepts or breaking changes.

[onmax]

I see. I think your idea for nesting groups might have more use cases in fact.

But, here I guess we are talking about two different things and maybe calling them both group might be confusing although the share the same functionality... Anyway, you can see one example of multiple groups here: https://play.tailwindcss.com/qpLDnnE4aY

I know I could've made the nav with HTML li markers or also using ::before on the li element, but those solutions have their trade-offs and it didn't fulfil what I wanted to achieve so that's why the DOM is so chaotic. You can see, the same component with a little bit of JS here.

But, my point is that, named groups also have their use cases but maybe they are not so important to be in the core after all. This can be a plugin like the one I did and leave it as it is 😃

[onmax]

Also, in the other hand I have created also this other plugin called tailwind-write-variables and I think you can replicate the functionality of group class only using var such as:

<div class="var-[my-color=#999] hover:var-[my-color=#111]">
    <p class="text-[color:var(--my-color)]">I am a black text!</p>
</div>

Tailwind Play

I think is also a good alternative, but not sure if this could help with nesting groups...

[MichaelAllenWarner]

@onmax

Yes, named-groups allow for more complex scenarios like yours.

Tailwind actually already natively supports setting CSS variables (and arbitrary properties in general). The syntax is like [--my-color:dodgerblue] and [clip-path:circle()]: Tailwind Play

[onmax]

Wow, didn't know that. I was looking in the documentation and I didn't find it. Thanks!

[ojvribeiro]

Just in case you came from Google looking for a solution (like me), it is documented here:

https://tailwindcss.com/docs/hover-focus-and-other-states#differentiating-nested-groups