javascript - tag - window title js




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

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

На сенсорном устройстве, таком как 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 . Поэтому, пожалуйста, не отвечайте, если вы не можете выполнить требования в вопросе;)


В 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

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

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


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

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

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

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

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

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


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

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


См. 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"

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

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


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

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

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

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

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

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

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


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







touch