Support for active state variant

[fedetibaldo]

This is just a small addition to the state variant family. active state can come in handy while defining how buttons should behave when clicked, and I guess in a lot of other situations.

The thing is: we already support hover and focus, right? Why not active?

This pull request includes basic support, documentation and ad-hoc tests. It only needs to get merged to be up and running.

A little sidenote: I changed the order in which state variants get generated, and their tests accordingly (now hover gets outputted before focus, and active sits between the two). That's to keep the same order throughout the codebase.

[fedetibaldo]

I've updated the pull request because I've realized that some precedences are into play when the output of the state variants takes place. Ups

[MichaelDeBoey]

You could leave this change out I think, otherwise it could become very bloated over time...

[fedetibaldo]

I guess you are right

[MichaelDeBoey]

Same here

[MichaelDeBoey]

Same here

[fedetibaldo]

I've updated as you suggested, @MichaelDeBoey.

[adamwathan]

Hey thanks for the PR! I'd like to merge this but I disagree with the priority order here; it should be:

• Focus
• Hover
• Active

...in lowest to highest precedence, IMO.

Imagine a button that is focused but not hovered. If I hover it, I expect to see the hover styles, not the focus styles, and if I press it, I expect to see the active styles, not the hover styles:

Here's how that same interaction looks using the precedence order that's currently in the PR:

The background color never changes after it's been focused, which isn't how I'd expect it to work personally.

Happy to merge after that tweak though, thanks!

EDIT: Here's a fiddle to test out what I mean, hopefully is convincing:

https://jsfiddle.net/adamwathan/pm9rxyk3/

[fedetibaldo]

Yeah. Makes sense. I was thinking more about text inputs rather than buttons when I decided the order. I asked many persons what colour were they expecting to see when hovering a focused text field, and they all agreed with the current version.

(Here is a fork of your fiddle to demonstrate what I mean: https://jsfiddle.net/fedeTibaldo/gzj151dm/ )

However, since inputs still look reasonably good with your desired behaviour whilst buttons do not look OK at all with the current one, I will be happy to update it!

[adamwathan]

Yeah that's an annoying problem actually :/ Sucks that we have to pick one way or the other in that case. I think the change I suggested is probably still an improvement since I suspect people are adding hover states to buttons more often than to form controls but it's still a bummer.

[fedetibaldo]

I suspect it too. Here is the updated version!

[chasegiunta]

Gonna give my unsolicited opinion - landed on this PR just now as I was wondering about the active state. Although initially seeing @adamwathan's GIF had me convinced, I believe after seeing @fedetibaldo's latest fiddle, in the effort of comprise he might have had it best (Current Behavior). Adam, your GIF example does make a bit more sense in the edge-case where someone might focus on a button before hover or clicking, but that case seems slim (I could be wrong, but I think either your predominately using the keyboard, or mouse, but typically not both for a single UI interaction like clicking a button).

I can still see customizing text input states as a common task, and clicking on the Desired Behavior text input in that latest fiddle & seeing it behave like a button is a pretty bad experience.

I definitely would love to see one way or another merged in soon, but get some more feedback if you guys can. https://jsfiddle.net/fedeTibaldo/gzj151dm/ seems like a solid test.

[adamwathan]

Yeah I'm still not fully convinced which behavior I think is better, but in the latest version of Tailwind hover already takes precedence over focus, so changing that would be a breaking change (which is fine) but because of that I think it probably makes sense to merge this PR first in a non-breaking way, and then consider that breaking change separately.

clicking on the Desired Behavior text input in that latest fiddle & seeing it behave like a button is a pretty bad experience.

I agree but in reality why would you add active:bg-whatever to an input? I didn't even know that an input could have active styles until today 😄 So I don't think that's as much of an issue; that behavior would only ever happen if wanted it to happen.

The other thing to consider is that I don't think it's super common to style the same property on both focus and hover; usually you would change a border or add an outline on focus, and change the background on hover, so maybe this isn't as big of a deal anyways (although I'd still like to get it as "right" as possible.)

It's probably most common to change background on both hover and focus on an input element, so maybe that is the right case to optimize for (although I still think active should always be last).

Going to do some research across other sites and see if I can be convinced one way or the other.

[fedetibaldo]

It seems like both approaches have their pros and cons. However, when updating the right properties, the so-called current behaviours is actually better. Why? Let's lay down some hypothesis:

• If I was designing a button, I would add borders to focus, lighten the colour on hover and darken it on active;

• If I was designing a text input, I would change the colour to a darker one on focus, change it to a lighter one on hover, and maybe add some border on active, just to give some feedback to the user (which is the only situation where I would actually use the active state on an input element).

Here is a fiddle: https://jsfiddle.net/fedeTibaldo/6rnbuk5p/

In this real-life scenario, the only visible difference between the two versions is the colour of the input when hovered while focused.

At this point, given the fact that all the people I asked to told me that they would feel as more natural if the colour of the input stayed darker when hovered on focus (as stated in one of my previous comments), the current behaviour wins.

[adamwathan]

Yep like I mentioned in my previous comment I think it's better to optimize for the input situation than for the button situation, if only because I literally can't find a single example on the entire internet of a site that uses different background colors on a button for focus and hover states; every single example I found where the background color changed on focus used the same color on hover.

That said I'm still going to merge this with the order it's in now, and then can change the order in the next breaking release.

Holding off merging right this second because our docs site uses the master branch, and I don't want the docs site to be showing features that aren't in a tagged release yet, so I need to update the site to deploy from the most recent tag instead of master before I merge this.

[adamwathan]

I'd like to include this in 0.5, feel like rebasing this there and deleting all the docs stuff (since the docs are now in a separate repo)? I can totally do it myself if not, just wanted to give you a chance to get credit for the PR.

0.5 changes the state order to be group-hover, hover, focus, so active would just need to be tacked on to the very end.

[adamwathan]

Fixed the conflicts and merged, thanks.