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

hoverOnlyWhenSupported doesn’t work with iPad trackpad #11109

Closed
patrikholcak opened this issue Apr 27, 2023 · 5 comments
Closed

hoverOnlyWhenSupported doesn’t work with iPad trackpad #11109

patrikholcak opened this issue Apr 27, 2023 · 5 comments
Assignees

Comments

@patrikholcak
Copy link

What version of Tailwind CSS are you using?

v3.2.1. I checked the code and there have been no changes (master)

What build tool (or framework if it abstracts the build tool) are you using?

Tailwind play

What version of Node.js are you using?

What browser are you using?

Safari 16.4

What operating system are you using?

iOS 16.4

Reproduction URL

https://play.tailwindcss.com/p2MO5uc3gD

Describe your issue

#8394 introduced a new future flag hoverOnlyWhenSupported, which uses hover and pointer media to get rid of sticky hovers on touch devices. Both pointer and hover only test for the primary input. This means a touch device with trackpad connected (eg. iPad with Magic Keyboard) doesn’t show any hovers when using the trackpad when this flag is enabled.

Using any-hover and any-pointer should solve that issue, however simply changing the value might not be the best option, as some people could want the current behaviour. There also might be some edge cases I’m not seeing right now — likely some hybrid device which does some weird stuff in tablet vs laptop mode, etc. which could result in sticky hovers even with the flag enabled…

A viable option might be to have control over which property is used, eg.

future: {
  hoverOnlyWhenSupported: "primary" | "any" | false,
}

Anyway, this is reproducible in XCode Simulator (click the "Capture pointer" button in top right) using the play link above. Here’s also a great page which shows the difference between the selectors and shows you what media your device currently matches:
https://patrickhlauke.github.io/touch/pointer-hover-any-pointer-any-hover/


I tried to solve this locally by first disabling the hover core plugin and wasn’t able to:

corePlugins: {
  hover: false,
},

Looks like it’s not even specified in CorePluginList type. But then I tried simply adding a new custom hover variant and it allows me to override the core plugin, css output looks 👌 too — https://play.tailwindcss.com/TT1IC2V7xN

Seems like this could be a viable short term solution for me, but it just doesn’t feel right…

plugins: [
  function ({ addVariant }) {
    addVariant('hover', '@media (any-hover: hover) and (any-pointer: fine) { &:hover }')
  }
]
@Santas
Copy link

Santas commented Apr 27, 2023

The same issue happens on a desktop using Firefox and Wacom tablet. iPad Pro M2 hovering with Pencil is also affected.

@RobinMalfait RobinMalfait self-assigned this Apr 28, 2023
@Haydenpayne

This comment was marked as spam.

@joeypohie

This comment was marked as spam.

@adamwathan
Copy link
Member

Hey! Yeah this is currently by design, there's no way to detect if the input mechanism that is currently being used supports hover without JavaScript so you have to pick one side of the trade-off. Either you lose hover styles on devices that technically support them when using certain connected hardware because the primary device doesn't support hover, or you get sticky hover states on devices like iPads when using your finger as soon as you've connected a trackpad.

We decided to pick the first trade-off and treat hover styles as unnecessary progressive enhancement which I still agree with — it should always be safe to not trigger them because you need to support many devices that can't support hover anyways.

This whole feature is pretty experimental still and will probably change before it lands as stable anywhere. We spent a week trying to work towards making it the default but are second-guessing the whole thing at this point and instead will probably just add new variants you can stack with the hover variant, like can-hover:hover:bg-red-500, any-hover:hover:bg-red-500, and pointer-fine:hover:bg-red-500.

For now though this is working as designed and no plans to change to any-hover because I don't like the compromises that introduces personally. Again it's more likely that we just totally kill this feature and implement these CSS features differently I'm afraid. Thanks for the opening discussion regardless!

@patrikholcak
Copy link
Author

@adamwathan Thanks for the reply! I think the variant stacking will help, but is there any chance to allow disabling all corePlugins, including hover or dark so I can provide my own variants? I'm fine with that as long as I can make sure they won't get overwritten.

My use case is allowing me and my teammates to only use our hover variant so that none of us forget to also add hovers for mobile. And it'd be easier to always write hover than any-hover:hover. I can make a new issue for that request.

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

No branches or pull requests

6 participants