Оптимизация веб-сайта для сенсорных устройств

На сенсорном устройстве, таком как iPhone/iPad/Android, может быть трудно нажать маленькую кнопку пальцем. Существует не межсерверный способ обнаружения сенсорных устройств с помощью мультимедийных запросов CSS, о которых я знаю. Поэтому я проверяю, поддерживает ли браузер поддержку событий javascript touch. До сих пор другие браузеры не поддерживали их, но последний Google Chrome на dev-канале включал события касания (даже для не сенсорных устройств). И я подозреваю, что другие производители браузеров будут следовать, поскольку ноутбуки с сенсорными экранами отправляются. Обновление: это ошибка в Chrome, поэтому теперь обнаружение JavaScript работает снова.

Это тест, который я использую:

function isTouchDevice() {
    return "ontouchstart" in window;
}

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

Кто-нибудь знает о правильном [tm] способе предоставления сенсорным устройствам лучшего пользовательского опыта? Помимо обнюхивания пользовательского агента.

Mozilla имеет медиа-запрос для сенсорных устройств. Но я не видел ничего подобного в любом другом браузере: https://developer.mozilla.org/En/CSS/Media_queries#-moz-touch-enabled

Обновление. Я хочу избежать использования отдельной страницы/сайта для мобильных устройств/сенсорных устройств. Решение должно обнаруживать сенсорные устройства с обнаружением объектов или аналогичными с помощью JavaScript или включать пользовательский сенсорный CSS без взлома агента пользователя! Основная причина, по которой я спросил, заключалась в том, чтобы убедиться, что это невозможно сегодня, прежде чем я свяжусь с рабочей группой css3. Поэтому, пожалуйста, не отвечайте, если вы не можете выполнить требования в вопросе;)

Ответы

Ответ 1

Мне кажется, что вы хотите иметь удобный для сенсорного экрана вариант, чтобы охватить следующие сценарии:

  • iPhone-подобные устройства: маленький экран, только сенсорный
  • Маленькие экраны, без прикосновения (вы не упомянули об этом)
  • Большие экраны, без касания (т.е. обычные компьютеры)
  • Широкие экраны с сенсорным экраном, такие как iPad, ноутбуки/ПК с сенсорными экранами.

Для случая 1 и 2 вам, вероятно, понадобится отдельный сайт или файл CSS, который избавит вас от лишнего содержимого и сделает вещи более удобными для чтения и навигации. Если вам небезразличен случай №2, то до тех пор, пока ссылки/кнопки на странице управляются клавиатурой, то случаи 1 и 2 эквивалентны.

Для случая 3 у вас есть свой обычный сайт. Для случая 4 это звучит так, как будто вы хотите, чтобы кликабельные вещи были больше или легче касались. Если невозможно сделать все больше для всех пользователей, альтернативная таблица стилей может предоставить вам удобные изменения макета.

Проще всего сделать ссылку на сенсорную версию сайта где-то на странице. Для известных сенсорных устройств, таких как iPad, вы можете обнюхать пользовательский агент и установить таблицу стилей касания как значение по умолчанию. Однако я бы подумал сделать это дефолтом для всех; если ваш дизайн выглядит хорошо на iPad, он должен выглядеть приемлемо хорошо на любом ноутбуке. Ваши пользователи мыши с навыками нажатия менее чем на звездные будут рады найти более крупные цели кликов, особенно если вы добавите соответствующие эффекты :hover или mouseover, чтобы пользователи знали, что все можно щелкнуть.

Я знаю, что ты сказал, что не хочешь обнюхивать пользовательских агентов. Но я бы утверждал, что в это время состояние поддержки браузером в этом слишком много, чтобы беспокоиться о "правильном" способе сделать это. Браузеры в конечном итоге предоставят необходимую вам информацию, но вы, вероятно, обнаружите, что это будет за несколько лет до того, как эта информация будет вездесущей.

Ответ 2

Хорошие новости! В проекте редактора CSS4 Media Queries добавлена ​​новая функция мультимедиа pointer.

Типичными примерами "тонкой системы указания" являются мышь, дорожка или сенсорный экран на основе стилуса. Сенсорные экраны на основе пальцев будут квалифицироваться как "грубые".

/* 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+) обнаруживают сенсорное оборудование при запуске приложения и выставляют события касания. К сожалению, если "указатель: грубый" возвращает false, нет способа узнать, не вызвано ли это тем, что запросы медиа-указателя не реализованы или потому что есть прекрасный указатель. WebKit не реализовал "указатель: отлично", но мы также не можем проверить это.

Обновление 26 сентября. 2012 Протестировано в Safari на iOS6 и Chrome на Android 4.1.1, и этого пока нет. "указатель" и "зависание" медиа-запросов приземлился в WebKit 30 мая. Согласно User-Agent, Safari с 25 апреля использует ветвь WebKit 536.26, а Chrome на Android использует и даже более старую (535.19). Неверно верить веткам WebKit из строк User-Agent, но моя тестовая страница не может также обнаруживать запросы указателя. реализация с мая реализует только медиа-запрос указателя для сенсорных устройств, поэтому указатель: тонкий не будет работать для устройств с помощью мыши.

Ответ 3

В Google Chrome есть переключатель командной строки для включения событий касания. Отключено по умолчанию. Поэтому, пока они не позволят им для всех снова (надеюсь, их не будет), можно обнаружить прикосновение с помощью javascript, как я описал в вопросе..

Обновление jun 3 2010: Это действительно попало в стабильную версию 25 мая 2010 года:( Не знаю, это была ошибка или нет.

Обсудили вопрос о списке рассылки w3c, но я сомневаюсь, что все произойдет очень скоро. http://lists.w3.org/Archives/Public/www-style/2010May/0411.html Они могут обсудить это во время TPAC в ноябре.

Обновление sep 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

Обновление может быть 16th 2011: W3C теперь работает над спецификацией Touch Events, но более или менее отказался, чтобы скрыть события касания для терминалов без сенсорного оборудования. Поэтому не ожидайте, что обнаружение сенсорного события будет работать долгое время.

Обновление 6 июня 2012. В спецификации W3C CSS4 Media Queries (Editors Draft) есть что-то очень интересное. См. Мой отдельный ответ об этом.

Ответ 4

Я не знаю, может ли стандартизованный медиа-запрос, такой как Mozilla, решить проблему сам по себе. Как сказал один из разработчиков Chromium в этом обсуждении, связанное с этим, присутствие поддержки сенсорных событий в браузере не означает, что события касания могут или будут срабатывать, или даже если они это сделают, что пользователь будет только хотеть взаимодействовать с помощью сенсорного ввода, Точно так же наличие поддержки сенсорного ввода в устройстве не означает, что пользователь будет использовать этот метод ввода - возможно, устройство поддерживает мыши, клавиатуру и сенсорный ввод, и пользователь предпочитает мышь или какую-то комбинацию из трех типов ввода.

Я согласен с разработчиком Chromium, что поддержка сенсорных событий не была ошибкой в ​​браузере. Хороший браузер должен поддерживать сенсорные события, потому что он может быть установлен на устройстве, поддерживающем сенсорный ввод. Это ошибка разработчика веб-сайта, что он принял поддержку мероприятия, так как пользователь будет взаимодействовать прикосновением.

Кажется, нам нужно знать две вещи: (1) Все поддерживаемые типы ввода на устройстве (2) Какие все поддерживаемые типы событий в браузере

Поскольку мы не знаем № 1 прямо сейчас, есть один подход, предложенный PPK quirksmode, который мне нравится. Он говорит об этом здесь: http://www.quirksmode.org/blog/archives/2010/02/do_we_need_touc.html#link4

В принципе, слушайте события касания и события мыши, и когда это произойдет, настройте интерфейс. Очевидно, что это ограничение для разработчика. Я не думаю, что это правильный подход к вашей проблеме с размером ссылки, потому что вы не хотите ждать взаимодействия для изменения пользовательского интерфейса. Все дело в том, чтобы представить другой пользовательский интерфейс (более крупную/меньшую ссылку) до того, как произойдет какое-либо взаимодействие.

Я надеюсь, что вы внесете свое предложение, и оно будет включено в CSS3. До тех пор, насколько мне больно это говорить, пользовательский нюхательный взгляд выглядит как лучший подход.

p.s. Надеюсь, надеюсь, что кто-то придет сюда и докажет, что я ошибаюсь.

Ответ 5

Нет, такого не бывает. CSS имеет параметр размера экрана, который позволит вам оптимизировать макет, но все. Существует также media="handheld", но это также не относится к вашим требованиям.

Обнаружение функции может работать с использованием javascript, однако есть проблемы с различными событиями для разных устройств. PPK (человек, стоящий за quirksmode.org) делает огромную работу, проверяя, какой javascript возможен для каждого мобильного/карманного устройства, и это доказывает, что ничто не кажется стандартным для этих устройств, и все же этот STILL не применяется к вашим требования к сенсорным портативным устройствам.
(честно говоря, я не знаю, почему вас беспокоит устройство, которое еще не вышло, быть прагматичным и беспокоиться об этом, когда оно здесь, и вы можете его протестировать)

Работа PPK в мобильных браузерах и событиях касания, сэкономит вам часы. Проверьте здесь

Ответ 7

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

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

Ответ 8

попробуйте использовать таблицы и сделайте полную ячейку ссылкой... Я работаю над этим на своем веб-сайте... пока это не работает. но вы можете найти способ... на этом пути нет необходимости перегружать ваш сайт с помощью javascript и обнаружения функций... вы можете придать ему относительный размер с фиксированным размером... и таким образом, ваш сайт можно просматривать на рабочем столе, как показано на iphone... подумайте об этой идее... любой sugestion оценивается...

Ответ 9

Смотрите http://crbug.com/136119 для поддержки добавления указателя: отлично в Chrome. На самом деле можно определить, поддерживается ли указатель: грубый (чтобы отличить unset from not supported) - просто создайте медиа-запрос самостоятельно и проверьте в javascript, правильно ли он разбирался.

Например, сегодня "@media (указатель: грубая)" в Chrome появляется:

> document.styleSheets[0].rules[5].media[0]
"(pointer: coarse)"

Но неподдерживаемые фиктивные значения, такие как "@media (pointer: other)", не имеют значения:

> document.styleSheets[0].rules[8].media[0]
"not all"

Ответ 10

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

Лучше всего создать мобильную версию сайта или альтернативную таблицу стилей, которая загружается при обнаружении мобильного устройства с Javascript.

Ответ 11

Если вы используете PHP, это хорошее решение:

http://chrisschuld.com/projects/browser-php-detecting-a-users-browser-from-php/

Вы можете определить, является ли браузер телефоном с сервера, обнюхивая детали запроса браузера, и если да, отобразите альтернативные/дополнительные таблицы стилей/js/html