Комментарии 32
@media (min-width:0\0) {}
Прям как на десять лет назад перенёсся! Грязноватый, конечно, хак, но весьма полезный.
А как это сделать в JS, не грепая navigator.userAgent?
IE и Firefox являются браузерами для ПК — то в них и так не должен срабатывать данный медиа-запрос.
Откройте уже для себя 2-в-1 девайсы.
По мне должны работать и стили hover и стили для сенсорных устройств одновременно или же переключаться на лету через JS.
Формально в природе существуют мобильный IE (на старых виндофонах) и мобильный Огнехвост (в принципе, везде, кроме iOS), и как я понимаю, для них предложенное решение даст «ложноположительный» результат. Конечно, их так мало, что этим можно пренебречь, но всё же..:)
Насколько я понимаю, не дать :hover тем, кому он технически доступен — меньшее зло, чем наоборот, заставить полагаться на него тех, у кого его в принципе нет. Конечно, задачи разные бывают, но в общем случае, наверное, важнее отловить отсутствие мышки, чем наличие тача.
Вариант с hover+костыли более правильный, устройства 2-в-1 на любых обозревателях будут работать нормально.
А вот pointer:coarse сломает сенсорную часть на IE и Firefox:
caniuse.com/#feat=css-media-interaction
Эти правила просто не выполнятся.
Конечно ещё есть мобильный ие и мобильная лиса, они будут обрабатываться как 2-в-1 даже если у них нет hover.
Вот я лежу на диване со своим виндовым планшетом (Surface, Yoga, etc.) и серфлю инет с помощью тача, потому что так удобнее. Сайт автора определит, что у меня работает ховер, и я со своим тачскрином обламаюсь в нормальном использовании сайта.
Моя мысль в том, что hover должен быть не основным инструментом, а дополнительным: подсказывать шорткаты, комментарии и прочие тултипы. Может быть оптимизировать работу с мышкой, но не скрывать функционал за ховерами. Тогда задачи определения того, что ховеры поддерживаются вообще не будет.
Сайт автора определит, что у меня работает ховер, и я со своим тачскрином обламаюсь в нормальном использовании сайта.Сильно зависит от того как стили используются. Я хотел про это написать да вылетело из головы.
Если стили hover перекрывают стили под тач и ломают сенсорную работу то это само собой не нормально.
Моя мысль в том, что hover должен быть не основным инструментом, а дополнительнымЕсли уйти за рамки статьи то тут двоякая ситуация. Двоякость в том что интерфейс можно строить двумя способами:
1. заточенный сугубо под тот или иной вид взаимодействия (довольно сильно отличается от другого). Тут hover в одном случае будет как основной инструмент, в другом он вовсе будет отсутствовать. Но на деле различий будет сильно больше (те же разные размеры кнопок, наличие или отсутствие свайпов и т. д.)
2. компромиссный, где в среднем угождают всем, мудрят с адаптивностью и есть вспомогательные элементы разметки для focus событий (пример ссылки с всплывающей подсказкой, где под сенсорные устройства есть отдельный значок-кнопка т.к. по ссылке происходит переход). Тут грубо говоря и hover и focus рядом соседствуют и всё как-то усреднено.
В первом случае приоритет даётся основному назначению устройства, но в случае с 2-в-1 это не всегда возможно определить. Поэтому обычно всегда есть возможность переключиться в другой режим.
Во втором никакого приоритета не существует всё и так работает всегда.
Можно ещё скрестить эти два подхода и сделать морфирующийся интерфейс (плавное переключение на лету от поведения пользователя), но он всё равно не до конца решит проблему — в начале пользователь видит определённый вид интерфейса и думает что раз нет больших кнопок то надо тянуться к мышке (заветного тач события не происходит). То есть всё равно придётся в начале предлагать ему переключение чтобы он понял что интерфейс это вообще умеет.
Если стили hover перекрывают стили под тач и ломают сенсорную работу то это само собой не нормально.ну статья подразумевает, что или hover или тач.
Я не хочу больших кнопок. Даже мои не самые тонкие пальцы прекрасно попадают по всем кнопкам на десктопном хабре (кроме стрелочек у кнопки обновить комментарии, там сложно).
Я хочу не трогая мышку навигироваться по сайту, не отлавливая всплывающие меню. Я не против всплывающих меню, но пусть клик на полоске меню все равно перенесет меня в раздел, где я смогу перейти на подпункты
но т.к. IE и Firefox являются браузерами для ПК — то в них и так не должен срабатывать данный медиа-запрос.
т.е. ноутбуки-перевертыши с тачем пролетают мимо?
@media(max-width:1023px){
Без ховеров
}
@media(min-width:1024px){
Можно писать ховеры
}
В исключение только нетбуки попадут, но и это не так уж и критично. На тачах ховеры (описаны они кодом или нет) просто не проявятся (хотя вроде где-то проявляются как focus, но и это можно ресетнуть) — не вижу смысла усложнять.
Определяет даже телевизоры — это лучше, чем предлагаемое спецификациями. Но это вопрос времени =)
Есть немало планшетов с экраном в 1280px, а то и больше. Давать им интерфейс, сильно завязанный на ховеры — так себе вариант. Давать большие активные элементы «под палец» маленьким десктопам — меньшее зло, но тоже далеко не идеал. Не всегда, увы, размер имеет решающее значение:)
@media (min--moz-device-pixel-ratio:0) {}
Хочу предостеречь по поводу browserhacks.com — ресурс это очень старый, его создатель давно перестал уделять ему время, поэтому информация оттуда может быть весьма устаревшей и желательно ее перепроверять. Например, селектор :not(*:root) там преподносится как «хак для вебкитов», но это валидный селектор 4 уровня, и любой другой браузер запросто может в любой момент добавить его поддержку. Особенно в свете недавней активизации работы над селекторами в W3C.
@media (hover: hover) {
}
@media (hover: none) {
}developer.mozilla.org/en-US/docs/Web/CSS/@media/hover
Ищем поддержку hover на css