Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Only apply hover on devices that support hover #14500

Merged
merged 6 commits into from
Sep 24, 2024

Conversation

adamwathan
Copy link
Member

This PR updates the hover variant to only apply when @media (hover: hover) matches.

  .hover\:bg-black {
    &:hover {
+     @media (hover: hover) {
        background: black;
+     }
    }
  }

This is technically a breaking change because you may have built your site in a way where some interactions depend on hover (like opening a dropdown menu), and were relying on the fact that tapping on mobile triggers hover.

To bring back the old hover behavior, users can override the hover variant in their CSS file back to the simpler implementation:

@import "tailwindcss";
@variant hover (&:hover);

I've opted to go with just @media (hover: hover) for this because it seems like the best trade-off between the available options. Using (any-hover: hover) would mean users would get sticky hover states when tapping on an iPad if they have a mouse or trackpad connected, which feels wrong to me because in those cases touch is still likely the primary method of interaction.

Sites built with this feature in mind will be treating hover styles as progressive enhancement, so it seems better to me that using an iPad with a mouse would not have hover styles, vs. having sticky hover styles in the same situation.

Of course users can always override this with whatever they want, so making this the default isn't locking anyone in to a particular choice.

Comment on lines +450 to +452
variants.static('hover', (r) => {
r.nodes = [rule('&:hover', [rule('@media (hover: hover)', r.nodes)])]
})
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only important change — dropped the loop because the signature of this one is different now and we never needed to store all this stuff in an array for any other reason anyways.

@RobinMalfait RobinMalfait force-pushed the feat/hover-only-when-supported branch from 4fd60ee to 080bf6e Compare September 24, 2024 10:31
This allows us to just change the data attribute when making a change
instead of relying on `hover:`. In this PR `hover:` will use `@media
(hover: hover)` which is not implemented in Firefox on Linux at the time
of writing this PR.
@RobinMalfait RobinMalfait force-pushed the feat/hover-only-when-supported branch from 080bf6e to f799577 Compare September 24, 2024 10:48
Copy link
Member

@RobinMalfait RobinMalfait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just missing a changelog entry. Since it's technically a breaking change, do you want to put it under Changed or still considered a fix since it solves sticky hover issues on mobile?

@adamwathan adamwathan force-pushed the feat/hover-only-when-supported branch from 1aa7dd1 to 64c1efd Compare September 24, 2024 15:43
@adamwathan adamwathan merged commit abde4c9 into next Sep 24, 2024
@adamwathan adamwathan deleted the feat/hover-only-when-supported branch September 24, 2024 15:44
@MichaelAllenWarner
Copy link
Contributor

@adamwathan Curious why you decided not to include the pointer: fine query here (which was included in the old future-flagged option).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants