Optimiser le site Web pour les appareils tactiles
Sur un appareil tactile comme iPhone/iPad/Android, il peut être difficile d'appuyer sur un petit bouton avec votre doigt. Il n'y a pas de moyen multi-navigateur pour détecter les appareils tactiles avec des requêtes multimédia CSS que je connaisse. Je vérifie donc si le navigateur prend en charge les événements tactiles javascript. Jusqu'à présent, les autres navigateurs ne les prenaient pas en charge, mais la dernière version de Google Chrome sur le canal de développement événements tactiles activés (même pour les appareils non tactiles). Et je soupçonne que d'autres les fabricants de navigateurs suivront, car les ordinateurs portables avec écrans tactiles arrivent. Mise à jour: C'était un bug dans Chrome, donc maintenant la détection JavaScript fonctionne à nouveau .
Voici le test que j'utilise:
function isTouchDevice() {
return "ontouchstart" in window;
}
Le problème est que cela ne teste que si le navigateur prend en charge les événements tactiles, pas l'appareil.
Quelqu'un connaît-il la manière correcte de donner aux appareils tactiles une meilleure expérience utilisateur? Autre que renifler l'agent utilisateur.
Mozilla a une requête multimédia pour les appareils tactiles. Mais je n'ai rien vu de tel dans aucun autre navigateur: https://developer.mozilla.org/En/CSS/Media_queries#-moz-touch-enabled
Mise à jour: je veux éviter d'utiliser une page/un site séparé pour les appareils mobiles/tactiles. La solution doit détecter les appareils tactiles avec détection d'objet ou similaire à partir de JavaScript, ou inclure un CSS tactile personnalisé sans renifler d'agent utilisateur! La principale raison pour laquelle j'ai demandé était de m'assurer que ce n'était pas possible aujourd'hui, avant de contacter le groupe de travail css3 . Veuillez donc ne pas répondre si vous ne pouvez pas suivre les exigences de la question;)
Il me semble que vous souhaitez avoir une option compatible avec les écrans tactiles, pour couvrir les scénarios suivants:
- appareils de type iPhone: petit écran, tactile uniquement
- Petits écrans, pas de contact (vous n'avez pas mentionné celui-ci)
- Grands écrans, sans contact (c.-à-d. Ordinateurs conventionnels)
- Grands écrans à écran tactile tels que iPad, ordinateurs portables/PC avec écrans tactiles.
Pour les cas 1 et 2, vous aurez probablement besoin d'un site séparé ou d'un fichier CSS qui élimine beaucoup de contenu inutile et rend les choses plus grandes et plus faciles à lire/naviguer. Si vous vous souciez du cas n ° 2, tant que les liens/boutons de la page sont navigables au clavier, les cas 1 et 2 sont équivalents.
Pour le cas 3, vous avez votre site Web normal. Pour le cas 4, il semble que vous souhaitiez que les objets cliquables soient plus gros ou plus faciles à toucher. S'il n'est pas possible de tout simplement agrandir pour tous les utilisateurs, une autre feuille de style peut vous fournir les modifications de mise en page conviviales.
La chose la plus simple à faire est de fournir un lien vers la version à écran tactile du site quelque part sur la page. Pour les appareils tactiles bien connus tels que l'iPad, vous pouvez flairer l'agent utilisateur et définir la feuille de style tactile par défaut. Cependant, j'envisagerais d'en faire la valeur par défaut pour tout le monde; si votre design semble bon sur l'iPad, il devrait être acceptable sur n'importe quel ordinateur portable. Vos utilisateurs de souris avec des compétences de clics moins que stellaires seront ravis de trouver des cibles de clics plus grandes, surtout si vous ajoutez des :hover ou mouseover effets pour faire savoir aux utilisateurs que les choses sont cliquables.
Je sais que vous avez dit que vous ne vouliez pas renifler les agents utilisateurs. Mais je dirais qu'à l'heure actuelle, l'état de la prise en charge du navigateur est trop fluctuant pour s'inquiéter de la manière "correcte" de le faire. Les navigateurs fourniront éventuellement les informations dont vous avez besoin, mais vous constaterez probablement qu'il faudra des années avant que ces informations soient omniprésentes.
Bonnes nouvelles! Le brouillon de l'éditeur de CSS4 Media Queries a inclus une nouvelle fonctionnalité multimédia ' pointer '.
Des exemples typiques d'un système de pointage "fin" sont une souris, un trackpad ou un écran tactile basé sur un stylet. Les écrans tactiles au doigt seraient qualifiés de "grossiers".
/* 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;
}
}
Il est également possible de tester la requête média à partir de JavaScript:
var isCoarsePointer = (window.matchMedia &&
matchMedia("(pointer: coarse)").matches);
Mis à jour le 11 février. 2013 Sur Windows 8, les versions récentes de Chrome (version 24+) détectent le matériel tactile lors du lancement de l'application et exposent les événements tactiles. Malheureusement, si "pointeur: grossier "renvoie false, il n'y a aucun moyen de savoir si c'est parce que les requêtes de média de pointeur ne sont pas implémentées ou parce qu'il y a un pointeur fin. WebKit non implémenté " pointeur: fin "pour que nous puissions ' t vérifier cela non plus.
Mise à jour du 26 septembre. 2012 Testé dans Safari sur iOS6 et Chrome sur Android 4.1.1 et il n'est pas encore là. 'Pointeur' et 'hover' media-queries atterri dans WebKit 30 mai. Selon l'agent utilisateur, Safari utilise la branche WebKit 536.26 à partir du 25 avril et Chrome on Android utilise et même plus ancien (535.19). Je ne suis pas sûr que les branches WebKit des chaînes User-Agent soient fiables, mais mon page de test ne l'est pas La détection implémentation à partir de mai implémente uniquement la requête de média de pointeur pour les appareils tactiles, donc pointer: fine ne fonctionnera pas pour les appareils avec une souris.
Je ne sais pas si une requête média standardisée comme celle de Mozilla résoudra le problème par elle-même. Comme l'un des développeurs de Chromium l'a dit dans la discussion que vous avez liée, la présence de la prise en charge des événements tactiles dans le navigateur ne signifie pas que les événements tactiles peuvent ou vont se déclencher, ou même s'ils le font, que l'utilisateur ne voudra interagir que via une entrée tactile. . De même, la présence de la prise en charge de la saisie tactile dans l'appareil ne signifie pas que l'utilisateur utilisera cette méthode de saisie - peut-être que l'appareil prend en charge la souris, le clavier et la saisie tactile et l'utilisateur préfère la souris ou une combinaison des trois types d'entrée.
Je suis d'accord avec le développeur Chromium que la prise en charge des événements tactiles n'était pas un bug dans le navigateur. Un bon navigateur doit prendre en charge les événements tactiles, car il peut être installé sur un appareil prenant en charge la saisie tactile. C'est la faute du développeur du site Web s'il a pris le support de l'événement pour signifier que l'utilisateur interagirait via le toucher.
Il semble que nous devons savoir deux choses: (1) Quels sont tous les types d'entrée pris en charge sur l'appareil (2) Quels sont tous les types d'événements pris en charge dans le navigateur
Puisque nous ne connaissons pas # 1 en ce moment, il y a une approche proposée par PPK de quirksmode que j'aime. Il en parle ici: http://www.quirksmode.org/blog/archives/2010/02/do_we_need_touc.html#link4
Fondamentalement, écoutez les événements tactiles et les événements de souris et, lorsqu'ils se produisent, configurez l'interface utilisateur en conséquence. Évidemment, cela limite le développeur. Je ne pense pas que ce soit une approche valable pour votre problème de taille de lien car vous ne voulez pas attendre une interaction pour modifier l'interface utilisateur. Le tout est de présenter une interface utilisateur différente (un lien plus grand/plus petit) avant toute interaction.
J'espère que vous ferez votre proposition et qu'elle sera incluse dans CSS3. Jusque-là, même si cela me fait mal de le dire, le reniflement d'agent utilisateur semble être la meilleure approche.
p.s. J'espère que j'espère que quelqu'un vient ici et me prouve le contraire
Google Chrome a un commutateur de ligne de commande pour activer les événements tactiles . Désactivé par défaut. Donc, jusqu'à ce qu'ils les réactivent pour tout le monde (j'espère qu'ils ne le feront pas), il est possible de détecter le toucher à l'aide de javascript comme je l'ai décrit dans la question..
Mise à jour du 3 juin 2010 : Cela est entré dans la version stable le 25 mai 2010 :( Je ne sais pas si c'était une erreur ou non.
J'ai discuté du problème sur la liste de diffusion w3c, mais je doute que quelque chose se produise très bientôt. http://lists.w3.org/Archives/Public/www-style/2010May/0411.html Ils pourraient en discuter lors du TPAC en novembre.
Mise à jour 30 septembre 2010 : soi-disant corrigé dans Chrome 6. Nous n'avons pas encore eu le temps de rétrograder vers stable pour vérifier . Depuis Chrome upgrade automatiquement ce problème devrait déjà avoir disparu :)
Lisez ceci si vous envisagez d'utiliser des requêtes multimédias: http://www.cloudfour.com/css-media-query-for-mobile-is-fools-gold/ et http : //www.quirksmode.org/blog/archives/2010/09/more_about_medi.html
Mise à jour du 16 mai 2011 : le W3C travaille maintenant sur un spécification des événements tactiles , mais plus ou moins refusé pour masquer les événements tactiles pour les terminaux sans matériel tactile. Ne vous attendez donc pas à ce que la détection des événements tactiles fonctionne longtemps.
Mise à jour du 6 juin 2012 : La spécification W3C CSS4 Media Queries (Editors Draft) a quelque chose de très intéressant. Voir mon réponse séparée à ce sujet.
Non, il n'y a rien de tel. CSS a l'option de taille d'écran, qui vous permettra d'optimiser la mise en page, mais c'est tout. Il y a aussi media="handheld" mais cela ne s'applique pas non plus à vos besoins.
La détection des fonctionnalités peut fonctionner en utilisant javascript, cependant, il existe des problèmes avec différents événements pour différents appareils. PPK (l'homme derrière quirksmode.org) effectue une énorme quantité de travail pour vérifier quel javascript est possible pour chaque appareil mobile/portable, et cela prouve que rien ne semble être standard avec ces appareils et pourtant cela ne s'applique toujours pas à votre exigence pour les appareils portables tactiles.
(Honnêtement, je ne sais pas pourquoi vous êtes préoccupé par un appareil qui n'est pas encore sorti, soyez pragmatique et préoccupez-vous une fois qu'il est ici et vous pouvez le tester)
Le travail de PPK sur le navigateur mobile et les événements tactiles vous fera gagner des heures. Vérifiez-le ici
essayez d'utiliser des tableaux et de créer une cellule complète pour être un lien ... je travaille là-dessus dans mon site Web ... cela ne fonctionne pas bien jusqu'à présent ... mais vous pourriez trouver un moyen ... de cette façon, non besoin de surcharger votre site web avec javascript et détection de fonctionnalité ... vous pouvez lui donner une taille relative instread d'une taille fixe ... et de cette façon, votre site web peut être visualisé sur un bureau comme sur un iphone ... pensez à cette idée ... toute suggestion est appréciée ...
Apple a TouchEvents défini uniquement pour iPhone OS FWIW
Ce n'est pas une solution complète, mais vous voudrez peut-être simplement éviter tout petit bouton. Bien que les petits boutons soient davantage un problème de convivialité sur les appareils tactiles, ils sont toujours difficiles à utiliser, même avec un grand écran et une souris.
Si vous faites juste attention à utiliser des boutons suffisamment gros avec suffisamment d'espace entre eux, tout le monde en bénéficiera. De plus, cela vous obligera à ne pas encombrer votre interface avec trop de petits boutons :-).
Voir http://crbug.com/136119 pour la prise en charge de l'ajout de pointeur: très bien dans Chrome. Il est en fait possible de détecter si pointeur: grossier est pris en charge (pour distinguer non défini de non pris en charge) - il suffit de créer vous-même la requête multimédia et de tester en javascript si elle a été correctement analysée.
Par exemple, aujourd'hui "@media (pointeur: grossier)" dans Chrome apparaît:
> document.styleSheets[0].rules[5].media[0]
"(pointer: coarse)"
Mais les valeurs fausses non prises en charge comme "@media (pointeur: autre)" ne le font pas:
> document.styleSheets[0].rules[8].media[0]
"not all"