Оптимизировать сайт для сенсорных устройств
На сенсорном устройстве, таком как iPhone/iPad/Android, может быть трудно нажать маленькую кнопку пальцем. Я не знаю кросс-браузерного способа обнаружения сенсорных устройств с помощью медиа-запросов CSS. Поэтому я проверяю, поддерживает ли браузер сенсорные события javascript. До сих пор другие браузеры не поддерживали их, но последние версии Google Chrome на dev-канале включали сенсорные события (даже для не сенсорных устройств). И я подозреваю, что другие производители браузеров будут следовать, так как ноутбуки с сенсорными экранами идут. Обновление: это была ошибка в Chrome, поэтому теперь обнаружение JavaScript снова работает.
Это тест, который я использую:
function isTouchDevice() {
return "ontouchstart" in window;
}
Проблема заключается в том, что это проверяет только то, поддерживает ли браузер сенсорные события, а не устройство.
Кто-нибудь знает, как правильно использовать сенсорные устройства для удобства пользователей? Кроме сниффинга пользовательского агента.
У Mozilla есть медиа-запрос для сенсорных устройств. Но я не видел ничего подобного в других браузерах: https://developer.mozilla.org/En/CSS/Media_queries
Обновление: я хочу избежать использования отдельной страницы / сайта для мобильных / сенсорных устройств. Решение должно обнаруживать сенсорные устройства с обнаружением объектов или аналогичными из JavaScript, или включать пользовательский сенсорный CSS без использования пользовательского агента! Основная причина, по которой я спросил, состояла в том, чтобы убедиться, что сегодня это невозможно, прежде чем я свяжусь с рабочей группой css3. Поэтому, пожалуйста, не отвечайте, если вы не можете следовать требованиям в вопросе;)
11 ответов
Для меня это звучит так, будто вы хотите использовать сенсорный экран для следующих сценариев:
- iPhone-подобные устройства: маленький экран, только сенсорный
- Маленькие экраны, без прикосновения (вы не упомянули этот)
- Большие экраны, без прикосновения (т.е. обычные компьютеры)
- Большие экраны с сенсорным экраном, такие как iPad, ноутбуки / ПК с сенсорными экранами.
Для случаев 1 и 2 вам, вероятно, понадобится отдельный сайт или файл CSS, который устраняет большое количество ненужного контента и делает вещи более простыми для чтения и навигации. Если вам небезразличен случай № 2, тогда, пока ссылки / кнопки на странице ориентированы на клавиатуру, тогда варианты 1 и 2 эквивалентны.
Для случая 3 у вас есть обычный веб-сайт. В случае 4 это звучит так, как будто вы хотите, чтобы кликабельные объекты были больше или легче на ощупь Если невозможно просто сделать все больше для всех пользователей, альтернативная таблица стилей может предоставить вам изменения макета с поддержкой сенсорного ввода.
Самое простое, что можно сделать - это предоставить ссылку на версию сайта с сенсорным экраном где-то на странице. Для известных сенсорных устройств, таких как iPad, вы можете прослушать пользовательский агент и установить таблицу стилей сенсорного экрана по умолчанию. Однако я хотел бы сделать это по умолчанию для всех; если ваш дизайн выглядит хорошо на iPad, он должен выглядеть приемлемо на любом ноутбуке. Пользователи вашей мыши, обладающие менее чем звездными навыками нажатия, будут рады найти более крупные цели, особенно если вы добавите соответствующие :hover или же mouseover эффекты, чтобы пользователи знали, что вещи кликабельны.
Я знаю, что вы сказали, что не хотите нюхать пользовательских агентов. Но я бы сказал, что в настоящее время состояние поддержки браузера слишком велико, чтобы беспокоиться о "правильном" способе сделать это. Браузеры в конечном итоге предоставят необходимую вам информацию, но вы, вероятно, обнаружите, что пройдут годы, прежде чем эта информация станет повсеместной.
Хорошие новости! Черновик редактора CSS4 Media Queries включает новую медиа-функцию " указатель ".
Типичными примерами "точной" системы наведения являются мышь, трекпад или сенсорный экран на основе стилуса. Сенсорные экраны на пальцах будут квалифицироваться как "грубые".
/* Make radio buttons and check boxes larger if we
have an inaccurate pointing device */
@media (pointer:coarse) {
input[type="checkbox"], input[type="radio"] {
min-width:30px;
min-height:40px;
background:transparent;
}
}
Также возможно протестировать медиазапрос из JavaScript:
var isCoarsePointer = (window.matchMedia &&
matchMedia("(pointer: coarse)").matches);
Обновлено 11 февраля. 2013 В Windows 8 последние версии Chrome (версия 24+) определяют сенсорное оборудование при запуске приложения и отображают сенсорные события. К сожалению, если "pointer: coarse" возвращает false, нет никакого способа узнать, происходит ли это из-за того, что медиа-запросы указателя не реализованы или потому что имеется точный указатель. WebKit еще не реализовал "указатель: хорошо", поэтому мы не можем это проверить.
Обновление 26 сентября. 2012 год Испытано в Safari на iOS6 и Chrome на Android 4.1.1, но его пока нет. Медиа-запросы 'pointer' и 'hover' приземлились в WebKit 30 мая. Согласно User-Agent, Safari использует ветку WebKit 536.26 с 25 апреля, а Chrome на Android использует и даже более старый (535.19). Не уверен, что ветки WebKit из строк User-Agent заслуживают доверия, но моя тестовая страница также не может обнаружить медиазапросы указателя. Реализация с мая реализует только медиа-запрос указателя для сенсорных устройств, поэтому pointer:fine не будет работать для устройств с мышью.
Я не знаю, решат ли проблему стандартизированные медиа-запросы, такие как Mozilla. Как сказал один из разработчиков Chromium в своем обсуждении, наличие поддержки сенсорных событий в браузере не означает, что сенсорные события могут или будут срабатывать, или даже если они это сделают, то пользователь захочет взаимодействовать только через сенсорный ввод., Аналогично, наличие поддержки сенсорного ввода в устройстве не означает, что пользователь будет использовать этот метод ввода - возможно, устройство поддерживает мышь, клавиатуру и сенсорный ввод, а пользователь предпочитает мышь или некоторую комбинацию из трех типов ввода.
Я согласен с разработчиком Chromium, что поддержка сенсорных событий не была ошибкой в браузере. Хороший браузер должен поддерживать сенсорные события, потому что он может быть установлен на устройстве, которое поддерживает сенсорный ввод. По вине разработчика веб-сайта он понял, что поддержка событий означает, что пользователь будет взаимодействовать через касание.
Кажется, нам нужно знать две вещи: (1) Каковы все поддерживаемые типы ввода на устройстве (2) Каковы все поддерживаемые типы событий в браузере?
Поскольку мы не знаем #1 сейчас, есть один подход, предложенный PPK, который мне нравится. Об этом он говорит здесь: http://www.quirksmode.org/blog/archives/2010/02/do_we_need_touc.html
В основном, слушайте сенсорные события и события мыши, и когда они происходят, настройте пользовательский интерфейс соответствующим образом. Очевидно, что это ограничивает разработчика. Я не думаю, что это правильный подход к вашей проблеме с размером ссылки, потому что вы не хотите ждать взаимодействия, чтобы изменить пользовательский интерфейс. Весь смысл в том, чтобы представить другой пользовательский интерфейс (большую / меньшую ссылку), прежде чем произойдет какое-либо взаимодействие.
Я надеюсь, что вы сделаете свое предложение, и оно будет включено в CSS3. До тех пор, насколько мне больно это говорить, нюхание агента пользователя выглядит лучшим подходом.
PS Надеюсь, надеюсь, надеюсь, кто-то приходит сюда и доказывает, что я неправ
В Google Chrome есть переключатель командной строки для включения сенсорных событий. По умолчанию отключено. Поэтому до тех пор, пока они снова не включат их для всех (надеюсь, что они этого не сделают), можно обнаружить прикосновение с помощью javascript, как я описал в этом вопросе.,
Обновление от 3 июня 2010: 25 мая 2010 года эта версия стала стабильной:(Не знаю, ошиблась она или нет.
Обсудили проблему в списке рассылки w3c, но я сомневаюсь, что что-то случится очень скоро. http://lists.w3.org/Archives/Public/www-style/2010May/0411.html Они могут обсудить это во время TPAC в ноябре.
Обновление 30 сентября 2010: предположительно исправлено в Chrome 6. У нас еще не было времени перейти на стабильную версию для проверки. Поскольку обновление Chrome происходит автоматически, эта проблема уже исчезла:)
Прочтите это, если вы планируете использовать медиа-запросы: http://www.cloudfour.com/css-media-query-for-mobile-is-fools-gold/ и http://www.quirksmode.org/blog/archives/2010/09/more_about_medi.html
Обновление от 16 мая 2011 года: W3C сейчас работает над спецификацией Touch Events, но более или менее отказался скрывать сенсорные события для терминалов без сенсорного оборудования. Поэтому не ожидайте, что обнаружение сенсорного события будет работать долго.
Обновление 6 июня 2012: в спецификации W3C CSS4 Media Queries (Editors Draft) есть кое-что очень интересное. Смотрите мой отдельный ответ об этом.
Нет, такого нет. У CSS есть опция размера экрана, которая позволит вам оптимизировать макет, но это все. Существует также media="handheld" но это также не относится к вашим требованиям.
Обнаружение функций может работать с использованием JavaScript, однако существуют проблемы с различными событиями для разных устройств. PPK (человек, стоящий за quirksmode.org) проделывает огромную работу, проверяя, какой javascript возможен для каждого мобильного / портативного устройства, и доказывает, что ничто не кажется стандартным для этих устройств, и, тем не менее, этот STILL не применяется к вашему требование для сенсорных ноутбуков.
(честно говоря, я не знаю, почему вас беспокоит устройство, которое еще не вышло, будьте прагматичны и переживайте по этому поводу, как только оно появится здесь, и вы сможете проверить его)
Работа ППК над мобильным браузером и сенсорными событиями сэкономит вам часы. Проверьте это здесь
Не полное решение, но вы можете просто избегать маленьких кнопок. В то время как маленькие кнопки представляют большую проблему для удобства использования на сенсорных устройствах, ими всегда сложно пользоваться, даже с большим экраном и мышью.
Если вы просто обратите внимание на использование достаточно больших кнопок с достаточным пространством между ними, все выиграют. Плюс, это заставит вас не загромождать ваш интерфейс слишком большим количеством маленьких кнопок:-).
Попробуйте использовать таблицы и сделать полную ячейку для ссылки... я работаю над этим на моем веб-сайте... это пока не работает хорошо... но вы могли бы найти способ... на этом пути, нет необходимо перегрузить ваш веб-сайт определением javascript и функциональности... вы можете присвоить ему относительный размер instread фиксированного размера... и таким образом ваш веб-сайт можно будет просматривать на рабочем столе так же, как на iphone... Подумайте об этой идее... Любое предложение оценивается...
См. http://crbug.com/136119 для поддержки добавления указателя: отлично в Chrome. На самом деле можно определить, поддерживается ли указатель: грубый (чтобы отличить unset от не поддерживаемого) - просто создайте медиазапрос самостоятельно и проверьте в javascript, правильно ли он был проанализирован.
Например, сегодня "@media (указатель: грубый)" в Chrome обнаруживается:
> document.styleSheets[0].rules[5].media[0]
"(pointer: coarse)"
Но неподдерживаемые фиктивные значения, такие как "@media (pointer:other)", не делают:
> document.styleSheets[0].rules[8].media[0]
"not all"
Вы не будете иметь никакого контроля над обнаружением касаний, и даже если вы сделали логические шаги, чтобы выяснить, что именно пользователь пытается коснуться, это сложно и лучше всего обрабатывается самим устройством.
Лучше всего создать мобильную версию сайта или альтернативную таблицу стилей, которая загружается при обнаружении мобильного устройства с помощью Javascript.
Если вы используете PHP, это хорошее решение:
http://chrisschuld.com/projects/browser-php-detecting-a-users-browser-from-php/
Вы можете определить, является ли браузер телефоном со стороны сервера, проанализировав детали запроса браузера и, если это так, отобразить альтернативные / дополнительные таблицы стилей /js/html.