Tailwindcss: Support for additional state prefixes and customizing which utilities have state variants

[adamwathan]

Consolidating #27, #121, #125.

Right now we only support hover:{utility} state variants and only for the following modules:

• backgroundColors
• borderColors
• textColors
• fontWeights

It would be great to also add support for other states:

• active:
• focus:
• placeholder:, although this is a bit different
• disabled:
• valid:
• invalid:
• required:

(We may not add support for all of these, but listing ideas for reference.)

It would also be great to allow customizing which modules have these variants enabled, as enabling all of these for every utility would quickly bloat the outputted CSS.

We have plans for all of this, but this issue will serve as a single point of reference so we can keep duplicate issues under control.

[adamwathan]

Now that we have the ability to easily customize which states are available for which utility modules, I want to start thinking about what other states make sense to include and which ones we should say "you should make a component" for.

We currently have hover, focus, and group-hover as available states.

I'm thinking active and placeholder would be nice ones to add, but not sold on disabled or required since you need to add those tags to the element already, and if you are marking an element as disabled/required, you can also just apply the classes you want right there.

valid and invalid are more interesting, although I'm not convinced that enough people are using pure HTML5 form validation that they would be that helpful. I feel like most people are still using JS for this sort of thing because real world situations end up being more complex than the form validation API supports out of the box, and if you are controlling the valid/invalid state of something with JS, you can also control the class list.

That said, it's absolutely trivial to support all of these and we can keep them all disabled by default, so maybe it just doesn't matter at all?

[MichaelDeBoey]

I think it would be indeed a good idea to implement them, but disable the lesser common ones by default.

[idmytro]

what’s about before/after pseudo elements?

[TVke]

I get the thought process behind disabled and required, but I would use it because when I need to change the styling I don't like going to my JS file to do it.

[benface]

group-active and group-focus would be nice too!

[LasseRafn]

I really want to add this but seriously I have no idea how to do so. Never messed with postCSS and I can't figure where the hover and focus states are generated. Guess it's done by postCSS itself, with Hoverable.js?

[fedetibaldo]

active, valid and invalid are absolutely necessary IMO, as well as group-active.

[fedetibaldo]

@LasseRafn I've got an open pull request (#379) for the active state variant. Take a look at what file I changed to have an idea of what you have to do to implement it by yourself.

[trevorgehman]

I feel like active is certainly necessary, especially for elements like buttons.

[adamwathan]

Focus and active are now supported, with no concrete plans to support other states right now, so going to close this. Happy to discuss valid and invalid in a separate issue more specifically if someone is really passionate about including them and wants to make a good case for it.

[benface]

No plans to support group-active @adamwathan?

[adamwathan]

What's the compelling use-case? Not opposed to it but have never found myself needing it personally.

[benface]

Something like:

<a class="group block bg-blue">
    <div class="absolute pin bg-white opacity-0 group-hover:opacity-20 group-active:opacity-0"></div>
    <div class="absolute pin bg-black opacity-0 group-active:opacity-20"></div>
    Button
</a>

[adamwathan]

Cool, so I can't help but feel like that's ultimately better solved with additional colors instead of extra overlay elements vs. adding another complex-ish variant :/ Or even implementing these overlays as single color background gradients, so you can stack them as background images on top?

https://jsfiddle.net/wqha0kxf/3/

[illycz]

Any reactions to before and after pseudoelements? https://github.com/tailwindcss/tailwindcss/issues/136#issuecomment-353780568

[kimroen]

not sold on disabled or required since you need to add those tags to the element already, and if you are marking an element as disabled/required, you can also just apply the classes you want right there.

Just because I haven't seen it mentioned anywhere else, the reason I went looking for a disabled variant myself is that you can put disabled on a fieldset to disable all the inputs within it.

👇 All the inputs here are disabled and would have red text

<fieldset disabled>
  <input class="disabled:text-red" />
  <input class="disabled:text-red" />
  <button class="disabled:text-red" type="submit" />
</fieldset>

This is a much more convenient way to disable everything while the form is submitting than passing isSubmitting to each input individually for example.

[adamwathan]

@kimroen Great argument, didn't know about that! I'll add disabled as an option for v1 or shortly after.

[GoulvenC]

Hi guys, I just wanted to know if there was anything new about 'before' and 'after' pseudo elements ?
Two comments ( #136 (comment) #136 (comment) ) have already raised the question, without response. And it would be a feature that would interest me a lot :)

[bugproof]

+1 for group-active