Proposal for peer-group

[brandonmcconnell]

Table of Contents

• Background (use case)
• Proposal
• API (& thoughts on the subject)
  0. Snapshot preview of `peer-group` API syntax/usage
  1. Descendant variant options (peer-group vs. group) — mostly solved ✅
  2. Naming/labeling (or lack thereof)
  3. "Double-duty" peers

Background (use case)

Here's that demo I put together to demonstrate the layout shift difference between hidden and collapse, leading up to Tailwind CSS v3.2: https://play.tailwindcss.com/wi5PCW5ZwU

While putting this together, I came across a use case I sometimes need in Tailwind but for which no utility exists.

This was my implementation (same link as above), which required me to use a non-Tailwind-standard class (hideable) in order to target specific elements, since there was no Tailwind-standard class for performing such an operation:

◯━━┳━ peer
   ┗━ peer-checked:[&_.hideable]:collapse
       ┗━ hideable

Proposal

It'd be really convenient to be able to handle situations like that in a more Tailwind-y way, like this:

◯━━┳━ peer
   ┗━ peer-group
       ┗━ peer-group-checked:collapse

In an actual implementation, that same example might look more like this: https://play.tailwindcss.com/K4u4xjaQpJ (this won't actually work as is, since this is only proposed functionality, but the proposed code is there)

The huge benefit to this approach is that a peer can pass down its peer's state to all its descendants to react to.

In these cases, I usually reach for JS or an arbitrary variant in these sorts of situations, but I'd love to see a native solution added for this. Without this, a developer may need to add several different arbitrary classes to an ancestor element simply to target descendant elements like this when a peer's state changes.

API (& thoughts on the subject)

0️⃣ Snapshot preview of `peer-group` API syntax/usage

◯━━┳━ peer/label ◄┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ supports optional variant modifier (same as peers and groups)
   ┣━ peer-group/label ◄┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ peer-group initializes a special peer-linked group
   ┃   ┗━ peer-group-checked/label:utility ◄┈┈┈ using the peer's state via peer-group
   ┗━ peer-checked/label:utility ◄┈┈┈┈┈┈┈┈┈┈┈┈┈ original peer can still be used as simple peer

1️⃣ Descendant variant options (peer-group vs. group) — mostly solved ✅

💡 Rule(s) of thumb:

• peer evaluates the state of a preceding peer (of the same/lacking name, same applies to both bullets below)
• group evaluates the state of an ancestor group
• peer-group evaluates the state of an ancestor group's linked peer

Preface— I initially saw 2 different APIs for how this could be implemented (specific to order), the inheriting recipients of the peer-group state to either keep the full name peer-group or only use group since they'd likely be sharing the same namespace anyway.

1. Persist peer-group 🎉

   ◯━━┳━ peer
      ┗━ peer-group
          ┗━ peer-group-checked:utility
   

2. Use only group for descendants 🤮

   ◯━━┳━ peer
      ┗━ peer-group
          ┗━ group-checked:utility
   

While both of these could hypothetically work, I think the former (no. 1) is better. While being slightly more verbose, my reasoning is that it's likely not straightforward enough for the compiler to recognize when evaluating peer-group -> group:utility (vs. peer-group -> peer-group:utility) that it should not look to the group but the group's linked peer.

This would likely be much easier for the compiler to work with, if not the only option actually possible:

◯━━┳━ peer
   ┗━ peer-group
       ┗━ peer-group-checked:utility

2️⃣ Naming/labeling (or lack thereof)

As the above examples suggest, peer-group should work with or without a variant modifier (aka label), the same as peer or group and would work as expected with or without them, so long as all three have the same name/label or lack thereof:

◯━━┳━ peer/some-label ───────────────────────────╮   all three must have the
   ┗━ peer-group/some-label ─────────────────────┼─► same name/label or lack
       ┗━ peer-group-checked/some-label:utility ─╯   thereof to be linked

3️⃣ "Double-duty" peers

Because this uses a regular peer for the initial peer (the peer-group initializer is actually the second element in the setup), peers can essentially do double duty. Peers continue working as regular peer's and peer-group's use their state to setup groups based on that peer instead of themselves.

This way, something like this would be totally expected and functional:

◯━━┳━ peer
   ┣━ peer-group ◄┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ using the peer to initialize a peer-group
   ┃   ┗━ peer-group-checked:utility
   ┗━ peer-checked:utility ◄┈┈┈┈┈┈┈┈┈┈┈┈┈ original peer can still be used as simple peer

---

If this is approved, I'd be happy to put together a PR for this change.

[y1n0]

you can manage to make something like this work with the current api:

<input class="peer" type="checkbox" />
<span class="[--state:none] peer-checked:[--state:block]" >
  <nested>
    <span class="[display:var(--state)]">propagated!</span>
  </nested>
</span>

https://play.tailwindcss.com/c8wq9AcS7g

[brandonmcconnell]

@y1n0 What if you need to apply a handful of utilities when that condition is true, like this?:

peer-group-checked/named:block
peer-group-checked/named:font-bold
peer-group-checked/named:underline
peer-group-checked/named:hover:opacity-100

It's already verbose, but doing that using CSS vars for each property value just doesn't feel very sustainable.

[adamwathan]

@brandonmcconnell I think this will just work automatically in v4, give the alpha a shot and let me know if it does what you need 👍🏻

[brandonmcconnell]

Planning on it 🙂

No playground for that yet, right? I'll prob spin it up over the weekend

[brandonmcconnell]

@adamwathan Pre-v4, any better way to pass peer state through a group than this workaround of mine below using group-[]?

<input type="checkbox" class="peer" /> 👈🏼 check/uncheck here <div class="group"> <div class=" bg-red group-hover:bg-blue peer-checked:group-[]:bg-green peer-checked:group-hover:bg-purple ">or hover here</div> </div> Open this example in Tailwind Play: https://play.tailwindcss.com/xAd4hiATyE

It might be worth simply supporting group as a variant without a modifier, which would yield the extra benefit of being able to filter to grouped values of that name (or lack thereof).

That's what the group-[] is doing in my example above. I was actually kind of surprised that peer-checked:group-hover:bg-purple worked here without needing a workaround, too. That alone would have solved the original question fro,m this discussion.

---

Much of this was my primary motivation to create and launch Signals for Tailwind CSS this week. With signals, this could be abbreviated to the below.

<input type="checkbox" class="peer" /> 👈🏼 check/uncheck here <div class=" signal/vader hover:signal/obiwan peer-checked:signal/yoda peer-checked:hover:signal/macewindu "> <div class=" signal/vader:bg-red signal/obiwan:bg-blue signal/yoda:bg-green signal/macewindu:bg-purple ">or hover here</div> </div>

I am still working on the specificity sorting for applying the same property with different signals. It's an edge case, but one I'd like to tackle, probably similarly to how Tailwind CSS handles media query sorting, but using the specificity score rather than the query size. Tracking my thoughts and progress at toolwind/signals#2

[masrestu]

Open this example in Tailwind Play: https://play.tailwindcss.com/xAd4hiATyE

I just tried the code from your link, and it ran successfully. However, after updating to Tailwind v4, it unfortunately stopped working. :(

[kyleboe]

Any updates on this? AFAICT this does not work on Tailwind v4 especially so with named peers/groups.

[brandonmcconnell]

Do you have a Tailwind Play link I can tinker on?

[kyleboe]

I'm not even sure what combination to put the group/peer hover states but I've been trying permutations for a while and can't get them to work.
https://play.tailwindcss.com/Ka58UexSQQ