Re: [csswg-drafts] [selectors] Proposal for a :hover-only pseudo class (#7544)

Thanks @devongovett for starting this issue. I was thinking and complaining about the same issue recently and have my own write up explaining the problem and possible solutions.

Some of it may be a bit repetitive, but I want to share it here so we can discuss some of the details before one us can start a more formal proposal to get this problem solved.

---

## Problem

Due to legacy reasons, `:hover` on touchscreens works in a way that the only way to achieve "hover effects" on the web is to use Javascript. 

The specific problem is that on modern touchscreen OSs, hover interactions **"stick"**. I.e, After touching and letting on an element with `:hover` styles applied, the effect persists until the user touches a different element on the screen.

Further, the existing `@media` queries can't be used to conditionally apply styles for devices that may have touchscreens *and* mouse pointers such as iPads, Android Tablets and many Windows Laptops.

Adobe has a detailed blog post explaining the problem and how they had to resort to using Javascript to solve it.

## Desired Outcome

There are two possible desired outcomes:
1. A way to *ignore* all hover styles on touch interactions. Developers can instead use `:active` to apply visual styles for touch interactions. Touch screens usually don't have "hover" interactions and so this would be a reasonable solution.
2. A `:hover` that is only active while the touch interaction is active. This is likely the solution that most developers expect. In fact, iOS *used to* work like this in the past. However, the behaviour was changed to the way it works today so that older websites that show menus and other interactive elements on `:hover` can be usable on touchscreens.

## Proposals

There are at least two possible ways to solve this problem:

### 1. A new `:visual-hover` or `:hover-only` pseudo-class

This is the first solution that comes to mind when thinking about this problem. It is unfortunate that `:hover` has to remain sticky for legacy reasons. So we can add a new `:visual-hover` that can be used for applying visual effects that work with all input methods as expected. (Choosing from one of the two desired outcomes above.)

### 2. A way to "turn-off" persistent hover on touchscreens

When solving other similar problems, such as the 300ms tap-delay on links and buttons, the solution was to apply `touch-action: manipulation`. Perhaps, any element with `touch-action: manipulation` should also be opted out of persistent hover styles?


---

## My personal preference

I've been thinking about this a lot recently, and I think the ideal solution would be a way to opt out of the persistent hover behaviour when `touch-action: manipulation` is applied.

The introduces no new APIs which has many advantages:
1. It doesn't create a confusion about to different hover pseudo classes
2. It can be implemented as Progressive Enhancement as older browsers will get the current behaviour.
3. It follows the pattern of how the tap delay was fixed.


-- 
GitHub Notification of comment by nmn
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7544#issuecomment-2071685959 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 23 April 2024 08:09:46 UTC