Proposal for peer-group
#9611
Replies: 3 comments 2 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> |
Beta Was this translation helpful? Give feedback.
-
@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 👍🏻 |
Beta Was this translation helpful? Give feedback.
-
@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 brandonmcconnell/tailwindcss-signals#2 |
Beta Was this translation helpful? Give feedback.
-
Table of Contents
peer-group
vs.) — mostly solved ✅group
Background (use case)
Here's that demo I put together to demonstrate the layout shift difference between
hidden
andcollapse
, 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:Proposal
It'd be really convenient to be able to handle situations like that in a more Tailwind-y way, like this:
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
1️⃣ Descendant variant options (
peer-group
vs.) — mostly solved ✅group
💡 Rule(s) of thumb:
peer
evaluates the state of a precedingpeer
(of the same/lacking name, same applies to both bullets below)group
evaluates the state of an ancestorgroup
peer-group
evaluates the state of an ancestorgroup
's linkedpeer
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 namepeer-group
or only usegroup
since they'd likely be sharing the same namespace anyway.peer-group
🎉group
for descendants 🤮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:
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 aspeer
orgroup
and would work as expected with or without them, so long as all three have the same name/label or lack thereof:3️⃣ "Double-duty" peers
Because this uses a regular
peer
for the initialpeer
(thepeer-group
initializer 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.
Beta Was this translation helpful? Give feedback.
All reactions