javascript - eventos - touchstart
Optimizar el sitio web para dispositivos táctiles (11)
¡Buenas noticias! El borrador del editor de Consultas de medios CSS4 ha incluido una nueva característica de medios '' puntero ''.
Los ejemplos típicos de un sistema de puntero "fino" son un mouse, un track-pad o una pantalla táctil basada en stylus. Las pantallas táctiles basadas en dedo calificarían como ''gruesas''.
/* 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;
}
}
También es posible probar la consulta de medios desde JavaScript:
var isCoarsePointer = (window.matchMedia &&
matchMedia("(pointer: coarse)").matches);
Actualizado el 11 de febrero. 2013 En Windows 8, las versiones recientes de Chrome (versión 24+) detectan el hardware táctil al iniciar la aplicación y exponer eventos táctiles. Desafortunadamente, si "puntero: basto" devuelve falso, no hay manera de saber si se debe a que las consultas de medios de puntero no están implementadas o porque hay un puntero fino. WebKit aún no ha implementado "puntero: bien", por lo que tampoco podemos verificarlo.
Actualización 26 de septiembre. 2012 Probado en Safari en iOS6 y Chrome en Android 4.1.1 y aún no está allí. las consultas de medios ''puntero'' y ''hover'' aterrizaron en WebKit el 30 de mayo. Según el User-Agent, Safari usa la rama 536.26 de WebKit desde el 25 de abril, y utiliza Chrome en Android, e incluso uno más antiguo (535.19). No estoy seguro de que las ramas de WebKit de las cadenas de User-Agent sean fiables, pero mi página de prueba tampoco puede detectar las consultas de medios de puntero. La implementación de mayo solo implementa la consulta de medios de puntero para dispositivos táctiles, por lo que puntero: fino no funcionará para dispositivos con un mouse.
En un dispositivo táctil como iPhone / iPad / Android, puede ser difícil presionar un botón pequeño con el dedo. No hay una forma de navegación cruzada para detectar dispositivos táctiles con consultas de medios CSS que yo sepa. Así que verifico si el navegador tiene soporte para eventos táctiles de JavaScript. Hasta ahora, otros navegadores no los han admitido, pero los últimos eventos táctiles habilitados para el canal de desarrollo de Google Chrome (incluso para dispositivos no táctiles). Y sospecho que otros fabricantes de navegadores seguirán, ya que las computadoras portátiles con pantallas táctiles están llegando . Actualización: era un error en Chrome, por lo que ahora la detección de JavaScript funciona nuevamente .
Esta es la prueba que uso:
function isTouchDevice() {
return "ontouchstart" in window;
}
El problema es que esto solo prueba si el navegador tiene soporte para eventos táctiles, no el dispositivo.
¿Alguien sabe de la forma Correcta [tm] de dar a los dispositivos táctiles una mejor experiencia de usuario? Aparte de oler al agente de usuario.
Mozilla tiene una consulta de medios para dispositivos táctiles. Pero no he visto nada igual en ningún otro navegador: https://developer.mozilla.org/En/CSS/Media_queries#-moz-touch-enabled
Actualización: quiero evitar el uso de una página / sitio separado para dispositivos móviles / táctiles. La solución debe detectar dispositivos táctiles con detección de objetos o similar de JavaScript, o incluir un toque de CSS personalizado sin el agente de usuario husmeando. La razón principal por la que pregunté fue para asegurarme de que no sea posible hoy, antes de contactar al grupo de trabajo css3 . Por lo tanto, no responda si no puede cumplir con los requisitos de la pregunta;)
Apple tiene TouchEvents definidos solo para iPhone OS FWIW
Google Chrome tiene un interruptor de línea de comando para habilitar eventos táctiles . Desactivado por defecto. Entonces, hasta que se vuelvan a habilitar para todos (con suerte no lo harán), es posible detectar el tacto con la ayuda de javascript como describí en la pregunta. .
Actualización el 3 de junio de 2010 : Esto realmente entró en la versión estable el 25 de mayo de 2010 :( No lo sé, fue un error o no.
He discutido el tema en la lista de correo de w3c, pero dudo que algo ocurra muy pronto. http://lists.w3.org/Archives/Public/www-style/2010May/0411.html Podrían discutir esto durante TPAC en noviembre.
Actualización del 30 de septiembre de 2010 : Supuestamente corregido en Chrome 6. No ha tenido tiempo de cambiar a una versión estable para verificarlo. Dado que Chrome se actualiza automáticamente, este problema ya debería haber desaparecido :)
Lea esto si está considerando usar consultas de medios: http://www.cloudfour.com/css-media-query-for-mobile-is-fools-gold/ y http://www.quirksmode.org/blog/archives/2010/09/more_about_medi.html
Actualización 16 de mayo de 2011 : W3C ahora está trabajando en una especificación de Touch Events , pero más o menos se negó a ocultar eventos táctiles para terminales sin hardware táctil. Por lo tanto, no espere que la detección de eventos táctiles funcione por mucho tiempo.
Actualización del 6 de junio de 2012 : Las especificaciones de W3C CSS4 Media Queries (Editors Draft) tienen algo muy interesante. Ver mi respuesta por separado acerca de esto.
Me parece que desea tener una opción de pantalla táctil amigable, para cubrir los siguientes escenarios:
- Dispositivos tipo iPhone: pantalla pequeña, toque solo
- Pantallas pequeñas, sin tocar (no mencionaron esta)
- Pantallas grandes, sin tocar (es decir, computadoras convencionales)
- Pantallas de gran tamaño con pantallas táctiles como iPad, notebooks / pcs con pantallas táctiles.
Para los casos 1 y 2 probablemente necesite un sitio separado o un archivo CSS que elimine gran cantidad de contenido innecesario y haga que las cosas sean más grandes y fáciles de leer / navegar. Si le importa el caso n. ° 2, siempre que los enlaces / botones de la página sean navegables por el teclado, los casos 1 y 2 son equivalentes.
Para el caso 3 tienes tu sitio web normal. En el caso 4, parece que desea que las cosas en las que se puede hacer clic sean más grandes o más fáciles de tocar. Si no es posible hacer que todo sea más grande para todos los usuarios, una hoja de estilo alternativa puede proporcionarle los cambios de diseño fáciles de usar.
Lo más fácil es proporcionar un enlace a la versión de pantalla táctil del sitio en algún lugar de la página. Para dispositivos táctiles conocidos, como iPad, puede oler el agente de usuario y establecer la hoja de estilos táctil como predeterminada. Sin embargo, consideraría hacer que esto sea el predeterminado para todos; si su diseño se ve bien en el iPad debería verse aceptablemente bueno en cualquier computadora portátil. Los usuarios de mouse con habilidades de clics menos que estelares estarán encantados de encontrar objetivos de clics más grandes, especialmente si agrega los siguientes :hover
efectos de mouseover
o mouseover
sobre el mouseover
para que los usuarios sepan que se puede hacer clic en ellos.
Sé que dijiste que no querías oler agentes de usuario. Pero yo diría que en este momento el estado del soporte del navegador para esto es demasiado fluctuante como para preocuparse por la forma "Correcta" de hacerlo. Los navegadores eventualmente proporcionarán la información que necesita, pero probablemente descubra que pasarán años antes de que esta información sea omnipresente.
No es una solución completa, pero es posible que desee simplemente evitar cualquier pequeño botón. Si bien los botones pequeños son más un problema de usabilidad en los dispositivos táctiles, siempre son difíciles de usar, incluso con una pantalla grande y un mouse.
Si solo presta atención al uso de botones adecuadamente grandes con suficiente espacio entre ellos, todos se beneficiarán. Además, te obligará a no saturar tu interfaz con demasiados botones pequeños :-).
No sé si una consulta de medios estandarizada como la de Mozilla resolverá el problema por sí misma. Al igual que uno de los desarrolladores de Chromium, dijo en la discusión que vinculó, la presencia de compatibilidad con eventos táctiles en el navegador no significa que los eventos táctiles pueden o se dispararán, o incluso si lo hacen, que el usuario solo querrá interactuar a través de entrada táctil . Del mismo modo, la presencia de compatibilidad con entrada táctil en el dispositivo no significa que el usuario use ese método de entrada; quizás el dispositivo admita mouse, teclado y entrada táctil y el usuario prefiera el mouse o alguna combinación de los tres tipos de entrada.
Estoy de acuerdo con el desarrollador de Chromium en que los eventos táctiles de apoyo no eran un error en el navegador. Un buen navegador debería admitir eventos táctiles porque podría estar instalado en un dispositivo compatible con la entrada táctil. Es culpa del desarrollador del sitio web que haya considerado el soporte del evento como el que el usuario estaría interactuando a través del tacto.
Parece que necesitamos saber dos cosas: (1) ¿Cuáles son todos los tipos de entrada admitidos en el dispositivo? (2) ¿Cuáles son todos los tipos de eventos admitidos en el navegador?
Como no conocemos el número 1 en este momento, hay un enfoque propuesto por PPK del modo peculiar que me gusta. Él lo menciona aquí: http://www.quirksmode.org/blog/archives/2010/02/do_we_need_touc.html#link4
Básicamente, escuche los eventos táctiles y los eventos del mouse, y cuando ocurran, configure la IU según corresponda. Obviamente eso es una limitación para el desarrollador. No creo que sea un enfoque válido para su problema con el tamaño del enlace porque no quiere esperar a que la interacción altere la interfaz de usuario. El objetivo es presentar una UI diferente (un enlace más grande / más pequeño) antes de que ocurra cualquier interacción.
Espero que hagas tu propuesta y se incluye en CSS3. Hasta entonces, por mucho que me duela decirlo, el rastreo de agente de usuario parece el mejor enfoque.
ps Espero que espero que alguien venga aquí y me demuestre que estoy equivocado
No tendrá ningún control sobre la detección de toques, e incluso si realizó los pasos lógicos para descubrir qué es exactamente lo que el usuario está tratando de tocar es complejo y lo maneja mejor el dispositivo en sí.
Su mejor opción es crear una versión móvil del sitio o una hoja de estilo alternativa que se cargue cuando detecte un dispositivo móvil con Javascript.
No, no hay tal cosa. CSS tiene la opción de tamaño de pantalla, que le permitirá optimizar el diseño, pero eso es todo. También hay media="handheld"
pero eso tampoco se aplica a sus requisitos.
La detección de características podría funcionar usando JavaScript, sin embargo, existen problemas con diferentes eventos para diferentes dispositivos. PPK (el hombre detrás de quirksmode.org) está haciendo una gran cantidad de trabajo comprobando qué JavaScript es posible para cada dispositivo móvil / de mano, y está demostrando que nada parece ser estándar con estos dispositivos y aún así, TODAVÍA no se aplica a su requisito para dispositivos portátiles con pantalla táctil.
(Honestamente, no sé por qué te preocupa un dispositivo que aún no está apagado, sé pragmático y preocúpate por él una vez que esté aquí y puedes probarlo)
El trabajo de PPK en el navegador móvil y los eventos táctiles le ahorrará horas. Compruébalo here
Si está utilizando PHP, esta es una buena solución:
http://chrisschuld.com/projects/browser-php-detecting-a-users-browser-from-php/
Puede detectar si el navegador es un teléfono desde el servidor al olfatear los detalles de la solicitud del navegador, y si es así, mostrar hojas de estilo alternativas / extra / js / html
Trate de usar tablas y haga que una celda completa sea un enlace ... estoy trabajando en eso en mi sitio web ... hasta ahora no está funcionando bien ... pero podría encontrar una manera ... de esta manera, no necesita sobrecargar su sitio web con javascript y detección de funcionalidad ... puede darle un tamaño relativo de tamaño fijo ... y de esta manera, su sitio web se puede ver en un escritorio como se ve en un iphone ... piensa en esta idea ... cualquier sugerencia es apreciada ...
Vea http://crbug.com/136119 para soporte para agregar puntero: bien en Chrome. De hecho, es posible detectar si puntero: grueso es compatible (para distinguir unset de no compatible): simplemente cree la consulta de medios usted mismo y pruebe en javascript si se analizó correctamente.
Por ejemplo, hoy aparece "@media (pointer: grueso)" en Chrome:
> document.styleSheets[0].rules[5].media[0]
"(pointer: coarse)"
Pero los valores falsos no admitidos como "@media (puntero: otro)" no:
> document.styleSheets[0].rules[8].media[0]
"not all"