brandonmcconnell/tailwindcss-signals

Signals for Tailwind CSS simplifies styling based on ancestor state via style queries. Its declarative API for signaling states eliminates complex selectors, resulting in cleaner, more maintainable code.

Hi there, I'm Brandon

This is just one of several places where I tinker with ideas, burn the midnight oil, fix bugs and inadvertently end up creating more of them in the end, but alas… c'est la vie d'un développeur.

 

👔	I’m currently employed at Carevoyance at Definitive Healthcare.
📚	I’m currently learning Svelte, SvelteKit, D3, LayerCake, PostGreSQL.
👯	I’m looking to collaborate on a new idea surrounding git versioning.
🤝	I’m looking for help maintaining and growing TypedCSS.
👨‍💻	Explore some of my tinkering on CodePen.
💬	Ask me about CSS, SCSS, Tailwind, JavaScript, React, or Svelte.
📫	You can reach me on Twitter or via email.
📄	Learn more about my professional experience on LinkedIn or download my resume.
⚡	When I'm not flushing out lines of code faster than Eminem raps (or occasionally staring at my screen blankly), I enjoy traveling 🏔, photography 📸, playing sports 🏓, hiking 🥾, and spending time with friends and family 👨‍👩‍👧‍👦.

My latest StackOverflow activity

• Answer by Brandon McConnell for Performance of Array.flat() vs spread operator to flatten multiple arrays into one
• Answer by Brandon McConnell for JavaScript map & find at the same time: findMap?
• Boolean truthiness narrowing not working in Typescript
• Answer by Brandon McConnell for Adding tabindex dynamically
• Prevent merging of branch conditionally based on label

My latest tweets

• @branmcconnell: What’s stopping you from coding like this? ✈️🤘🏼
• @Zeko369: Brandon is on a roll with tailwind plugins... IDK how but every one seams even more useful than the last one
• @branmcconnell: Members for Tailwind CSS ✨👥 Descendant-driven styles. tailwindcss-members simplifies styling an ancestor element based on the state of its descendants. — Check it out on GitHub 👇🏼
• @branmcconnell: JSR is starting to look REALLY appealing, especially with these quirks at top-of-mind. @lcasdev How difficult is it to migrate existing NPM packages to JSR? Any official guide on that? @jsr_io #jsr #npm #esm #cjs #javascript #typescript
• @branmcconnell: The new @unkeydev site is gorgeous. @guilherme_rodz did you have something to do with this? 👀🤩

Connect with me

Languages and Tools

Support me

GitHub Profile Stats

   
☝🏼 Click to expand/collapse detailed stats
 

tailwindcss-signals's Issues

Build in specificity-based sorting mechanism

Currently, the priority of conflicting signal-triggered styles relies solely on the order in which they are processed and appear in the output stylesheet. This lack of proper prioritization results in variable results when working with conflicting styles and makes using them for the same style unreliable.

It's an edge case, and even Tailwind CSS core doesn't support built-in prioritization beyond the ! symbol for importance, but they don't need to for this case because Tailwind CSS leverages the built-in specificity algorithm for style prioritization.

Tailwind CSS does, however, deal with something similar with their media query sorting internally. A similar convention could work here. I see a couple of options here:

1. A more straightforward solution could be to order the signals based on the number of variants used to trigger them. In the example below, the container query for each signal would be ordered based on the specificity of the condition used when declaring it.

   <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/macewindu:!bg-purple signal/obiwan:bg-blue signal/vader:bg-red signal/yoda:bg-green">or hover here</div>
   </div>

   One issue with this approach that is core to the principle of Signals for Tailwind CSS is that signals must be trigger-able in multiple ways and places, so it might be unclear which usage is the most specific in certain instances. Even with that approach, certain signals might require different specificities in different places.

   This option would be the closest to how a natural CSS solution would work, similar to how group works, and this should maintain a 1:1 complementary relationship to that as much as possible.

   One last missing step that may ultimately solve this issue is to create a new media query not only per name but also per declaration, allowing each declaration to be uniquely sorted based on its specificity.

2. Another option could be to use the modifier syntax as a manual prioritization system instead, so someone could use any of these:

   • signal:vader (specificity defaults to 0)
   • hover:signal/1:obiwan
   • peer-checked:signal/2:yoda
   • peer-checked:hover:signal/3:macewindu

   With this solution, I would expose signals as BOTH a variant and a utility, but both would have the same functionality of setting up the signal. Then, to consume a signal, you would use a different accompanying utility, perhaps effect as suggested by @AlexVipond in #1. This would solve the issue, but I don't love this solution to the problem and how it places the full burden of manual specification into the hands of the users. (I might still rename the variant to effect though to better align with the prior art behind signals in JS)

3. I could ideate on some way to leverage CSS custom property inheritance here, but that idea is half-developed, and I don't think it would apply here since I'm working primarily with container queries and not variable values.

4. Lastly, I do nothing and suggest that users implement an approach for handling conflicting utility classes, such as tailwind-merge (or similar)

Action items

For now, with this all at front of mind, I think the ideal solution would be Option 1, specifically the idea to set up a new container query per usage/unique selector sorted based on that selector's specificity.

• Investigate this to ensure the idea is sound
• Implement and test it
  • consider alternatives for determining specificity based on the number of variants. Some may be more or less naturally specific than others. Case in point, :where zeroes out the specificity of a given selector, and that should be reflected here as well. Maybe I can get the final selector back from Tailwind's engine and use a 3rd party lib to determine specificity.
• Deploy the fix as a patch