`hoverOnlyWhenSupported` doesn’t work with iPad trackpad

[patrikholcak]

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]

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

[Haydenpayne]

I also have the same issue. MyKFCExperience

[joeypohie]

Potential related Issues / PRs:

• Only apply hover styles when supported (future): This pull request introduces the hoverOnlyWhenSupported future flag, which changes how the hover variant works. It ensures that hover styles are only applied on devices that properly support hover. This can help resolve the issue of sticky hovers on touch devices. The pull request provides detailed information on how to use the future flag and opt-in to the new hover strategy.
• group-hover:opacity-100 not working on Safari: This issue discusses the problem of group-hover:opacity-100 not working on Safari. Although it is not directly related to the issue you're facing, it provides insights into potential compatibility issues with different browsers. Understanding the limitations and known issues with certain variants can help troubleshoot and find workarounds for similar problems.
• Custom css gradients no longer work with hover: or dark:: This issue highlights the problem of custom gradients not working with hover: or dark: variants. While the issue is not identical to yours, it demonstrates how certain variants can affect specific CSS properties. Understanding the behavior of variants in different scenarios can provide insights into potential conflicts and help find solutions.

This message was generated by AI from www.triagetickets.com

[adamwathan]

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]

@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.