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

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

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

Apple имеет TouchEvents, определенные только для iPhone OS FWIW

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

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

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

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

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

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

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

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

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

Обновление jun 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) есть кое-что очень интересное. См. мой отдельный ответ об этом.

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

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

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

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

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

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

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