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

Accordion hover state remains on touch devices #1143

Closed
dashouse opened this issue Jan 16, 2019 · 2 comments
Closed

Accordion hover state remains on touch devices #1143

dashouse opened this issue Jan 16, 2019 · 2 comments
Assignees
Labels
🐛 bug Something isn't working the way it should (including incorrect wording in documentation)

Comments

@dashouse
Copy link

The hover state is unintentionally applied to the active accordion section on touch devices (tested on iOS but I believe this will happen on Android also)

While that behaviour is ok, the hover state gets reapplied when you close an accordion section, so you may end up in this situation.

The last closed accordion section looks like it has an active state (actually the hover), the accordion that's open doesn't have a state.

img_2531

Is there still a trick to stop the hover state appearing on touch devices?

@dashouse dashouse added the 🐛 bug Something isn't working the way it should (including incorrect wording in documentation) label Jan 16, 2019
@NickColley
Copy link
Contributor

NickColley commented Jan 16, 2019

Potentially related alphagov/govuk_elements#570

@NickColley NickColley self-assigned this Jan 17, 2019
@NickColley
Copy link
Contributor

NickColley commented Jan 17, 2019

We probably have two options:

  1. Apply a class based on pointer events
  2. Use media query hover

Media query hover detection seems like the best bet.

Can I use gives support for this feature: https://caniuse.com/#feat=css-media-interaction

https://www.w3.org/TR/mediaqueries-4/#status

The following features are at-risk, and may be dropped during the CR period:

the hover, any-hover, pointer, and any-pointer media features
“At-risk” is a W3C Process term-of-art, and does not necessarily imply that the feature is in danger of being dropped or delayed. It means that the WG believes the feature may have difficulty being interoperably implemented in a timely manner, and marking it as such allows the WG to drop the feature if necessary when transitioning to the Proposed Rec stage, without having to publish a new Candidate Rec without the feature first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 bug Something isn't working the way it should (including incorrect wording in documentation)
Projects
Development

No branches or pull requests

2 participants