Proposal for peer-group
#9611
Replies: 4 comments 7 replies
|
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> |
|
@y1n0 What if you need to apply a handful of utilities when that condition is true, like this?: It's already verbose, but doing that using CSS vars for each property value just doesn't feel very sustainable. |
|
@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 👍🏻 |
|
Planning on it 🙂 No playground for that yet, right? I'll prob spin it up over the weekend |
|
@adamwathan Pre-v4, any better way to pass peer state through a group than this workaround of mine below using
It might be worth simply supporting That's what the 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.
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 |
I just tried the code from your link, and it ran successfully. However, after updating to Tailwind v4, it unfortunately stopped working. :( |
|
@rozsazoltan's suggestion here to stack the variants is exactly what you're looking for: #9611 (reply in thread) |
|
Any updates on this? AFAICT this does not work on Tailwind v4 especially so with named peers/groups. |
|
Do you have a Tailwind Play link I can tinker on? |
|
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. |
|
@kyleboe just stack the variants. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Table of Contents
peer-groupvs.groupBackground (use case)
Here's that demo I put together to demonstrate the layout shift difference between
hiddenandcollapse, leading up to Tailwind CSS v3.2: https://play.tailwindcss.com/wi5PCW5ZwUWhile 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 ┗━ hideableProposal
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:collapseIn 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
1️⃣ Descendant variant options (
peer-groupvs.group💡 Rule(s) of thumb:
peerevaluates the state of a precedingpeer(of the same/lacking name, same applies to both bullets below)groupevaluates the state of an ancestorgrouppeer-groupevaluates the state of an ancestorgroup's linkedpeerPreface— I initially saw 2 different APIs for how this could be implemented (specific to order), the inheriting recipients of the
peer-groupstate to either keep the full namepeer-groupor only usegroupsince they'd likely be sharing the same namespace anyway.peer-group🎉◯━━┳━ peer ┗━ peer-group ┗━ peer-group-checked:utilitygroupfor descendants 🤮◯━━┳━ peer ┗━ peer-group ┗━ group-checked:utilityWhile 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:utility2️⃣ Naming/labeling (or lack thereof)
As the above examples suggest,
peer-groupshould work with or without a variant modifier (aka label), the same aspeerorgroupand 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 linked3️⃣ "Double-duty" peers
Because this uses a regular
peerfor the initialpeer(thepeer-groupinitializer is actually the second element in the setup), peers can essentially do double duty. Peers continue working as regularpeer's andpeer-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:
If this is approved, I'd be happy to put together a PR for this change.
All reactions