Главная » Статьи » Наконец-то, решение на чистом CSS для :hover на сенсорных экранах

Наконец-то, решение на чистом CSS для :hover на сенсорных экранах

Наконец-то, решение на чистом CSS для :hover на сенсорных экранах

От автора: с псевдоклассом :hover CSS возникали проблемы с тех пор, как на устройстве с сенсорным экраном был установлен первый веб-браузер. Конечно, появлялись определенные решения, но ни одно из них не было достаточным. С новыми Level 4 Media Queries эта проблема, кажется, решена навсегда.

«Хм… а в чем проблема?»

Допустим, вы просто добавили к элементу веб-страницы стиль :hover, поэтому он получает некоторый стиль, когда на него наводится курсор мыши. Просто.

Наконец-то, решение на чистом CSS для :hover на сенсорных экранах

Наведение на настольном компьютере. Источник: https://proper-hovering.glitch.me

Проблема возникает, когда пользователь взаимодействует с этим элементом на сенсорном экране: после того, как выполнено нажатие, эффект наведения для элемента закрепляется. Это также происходит, когда элемент даже не активируется касанием, например, если к нему прикоснулись во время прокрутки.

Если перетаскивание начинается на элементе, применяется эффект наведения, потому что технически объект указателя (это ваш палец, как правило) находится над элементом. Это проблема само по себе: на сенсорном устройстве это является нежелательным взаимодействием с пользователем.

Тем не менее, ситуация становится еще хуже: после прекращения перетаскивания эффект наведения остается активным!

Наконец-то, решение на чистом CSS для :hover на сенсорных экранах

Наведение на сенсорном экране (эмуляция). Источник: https://proper-hovering.glitch.me

Это определенно запутает некоторых из ваших пользователей, и это никогда не будет хорошо. Что-то должно быть сделано.

«Уже должно было появиться какое-то решение…»

Ну, есть некоторые, большинство из которых описаны в этой прекрасной статье. Лучшее из них включает в себя использование JavaScript для определения наличия сенсорных функций экрана, применение на основании этого класса для body, а затем явное указание на этот класс каждый раз, когда к любому элементу применяется эффект :hover.

body.nontouch nav a:hover { background: yellow;
}

Это метод изначально связан с рядом проблем:

Разработчик может создать сценарий обнаружения, который хорошо работает сегодня, но что будет через два месяца, когда появится какая-то новая технология? Ноутбуки с сенсорными экранами? Съемные сенсорные экраны? Apple Pencil? Я, скорее всего, не заботился бы об этом во время разработки.

Можно подумать, что у сообщества JS есть готовый пакет, предназначенный именно для этой проблемы, но это не так.

При использовании с инкапсулированными стилями, основанными на компонентах JS-фреймворка, это решение вносит просто огромный разлад. Каждый раз, когда используются эффекты наведения, стили этого компонента должны ссылаться на этот глобальный класс. Неудобно.

Не будет двух одинаковых проектов, использующих это решение. Может быть, один работает хорошо на определенном устройстве, а на другом — нет. Должен быть стандартизированный способ решить эту проблему.

Введение Level 4 Media Queries

Медиа-запросы великолепны. Они в одиночку создали адаптивный веб-дизайн и являются краеугольным камнем в современной мобильной веб-разработке. В качестве отличной инициативы W3C добавил Функции взаимодействия с медиа в качестве рекомендации для L4 Media Queries, и мы можем их использовать для распознавания устройств с сенсорным экраном.

Включены четыре медиа-запроса: hover, any-hover, pointer и any-pointer. Они предоставляют информацию о возможности наведения и типе пользовательских вводов. Информация может быть только о первичном вводе или о любом доступном вводе. Например, @media(hover: hover) будет true, если основной ввод может быть наведением (например, курсор мыши), а @media(any-pointer: coarse) будет true, если какой-либо ввод имеет ограниченную точность (например, сенсорный ввод). Эти медиа-функции предоставляют достаточно информации для правильной обработки :hover.

Одна из проблем заключается в том, что эти запросы на данный момент являются просто рекомендованными кандидатами, что означает, что они могут измениться или даже быть удалены в любое время. Помните об этом при работе с ними и решите, подходит ли это для вашего проекта. Это определенно на данный момент подходит для нас, и мы возлагаем большие надежды на эти спецификации. Тот факт, что все основные браузеры реализовали эти запросы (кроме, конечно, IE), заставляет нас еще более оптимистично смотреть в будущее.

«Так что же делать?»

С точки зрения разработчика, мы ищем решение, которое будет наиболее простым в использовании и обслуживании. С точки зрения UX, мы ищем решение, которое было бы наименее запутанным и наиболее подходящим для пользователя.

Это означает отсутствие эффектов наведения на чисто сенсорных устройствах, и использование их на всех остальных устройствах. Особый случай — это ноутбуки с сенсорными экранами, но мы можем ожидать, что мышь / тачпад используется большую часть времени. Даже если эффект наведения застревает, пользователь может легко использовать мышь / тачпад, чтобы проверить проблему и устранить ее. К счастью, ноутбуки со съемными сенсорными экранами переходят в режим планшета после отсоединения, что позволяет правильно обрабатывать медиа-запросом.

Вот тестовый сайт, с помощью которого вы можете протестировать свое собственное устройство, чтобы определить, какие из этих медиа-запросов применяются к нему, а также увидеть некоторые из наиболее популярных настроек устройств. Браузеры на Android имеют некоторые несоответствия, но другие устройства, кажется, работают нормально. Проверяя разные устройства, он показывает, что ноутбуки можно выбрать с помощью запроса @media(hover: hover) и (pointer: fine) {}.

@media(hover: hover) and (pointer: fine) { nav a:hover { background: yellow; }
}

Я что-то пропустил? Что вы обычно используете в этих случаях? Я очень доволен этим решением, но дайте мне знать, если есть что-то лучше!

Автор: Mezo Istvan

Источник: https://blog.usejournal.com

Редакция: Команда webformyself.