Je suis en train de faire une simple couverture diapositive :hover
comme dans l’image, elle est supposée glisser dans un contrôle «article préféré», sur lequel l’utilisateur peut cliquer pour mettre cet article en favori.
Bien que cela fonctionne bien sur le bureau avec le survol de la souris et le clic, je ne suis pas sûr qu'il puisse être utilisé comme contrôle efficace sur un appareil mobile ou autre (par exemple, cliquez pour basculer, puis cliquez à nouveau sur l'élément préféré).
Si je comprends bien, du moins sur iOS (Safari) et Android (Chrome), le comportement par défaut du navigateur consiste à émuler le toucher en tant que hover
et click
. Mais est-ce un standard ? par exemple.
click
sera-t-il déclenché environ 300 ms après hover
, de sorte qu'il puisse y avoir un problème de clic fantôme?Je peux certainement lier un événement click/touch sur cet élément, me demandant simplement si css :hover
est suffisant de nos jours.
Pour clarifier : Je ne pose pas de question sur le support :hover
, qui n'a de sens que dans un environnement dirigé par un pointeur. Je demande si les appareils peuvent et doivent gérer les éléments mobiles en survol lorsque les utilisateurs cliquent/tapent (comme iOS/Android)
Votre question n'est pas tout à fait claire et je ne peux pas comprendre si vous demandez "Puis-je utiliser :hover
sur tous les appareils?" ou "Will :hover
se comportera-t-il de la même manière sur tous les appareils?" ou "Est-ce que :hover
est un élément standard sur le web?"
Cela dépend aussi beaucoup de votre concept de "tous les appareils", si vous avez à l'esprit les appareils les plus utilisés actuellement ou si vous prenez en compte les appareils moins connus et utilisés.
Je vais vous citer ce qui suit, mais je suis presque sûr que vous avez déjà lu cela:
Les agents utilisateurs interactifs modifient parfois le rendu en réponse à actions de l'utilisateur. CSS fournit trois pseudo-classes pour les cas courants:
La pseudo-classe: hover s'applique tant que l'utilisateur désigne un élément (avec certains dispositif de pointage), mais ne l’active pas. Par exemple, un L'agent utilisateur visuel peut appliquer cette pseudo-classe lorsque le curseur (souris pointeur) survole une zone générée par l'élément. Agents utilisateurs non supportant les médias interactifs ne doivent pas supporter cette pseudo-classe . Certains agents utilisateurs conformes prenant en charge les médias interactifs peuvent ne pas être capable de supporter cette pseudo-classe (par exemple, un stylo de stylo). Le: actif La pseudo-classe s'applique lorsqu'un élément est activé par l'utilisateur . Par exemple, entre les moments où l'utilisateur appuie sur le bouton de la souris et le libère.
CSS ne définit pas quels éléments peuvent se trouver dans les états ci-dessus, ni comment les états sont entrés et laissés. L'écriture de script peut changer si des éléments réagir aux événements de l'utilisateur ou non, et différents appareils et agents d'utilisateur peuvent avoir différentes façons de désigner ou d’activer des éléments.
5.11.3 Les pseudo-classes dynamiques:: hover,: active et: focus http://www.w3.org/TR/CSS2/selector.html#dynamic-pseudo-classes
Comme vous pouvez le constater dans la spécification W3C, il affirme que la pseudo-classe :hover
n'est pas requise pour les agents utilisateurs de médias non interactifs, ainsi que certains agents d'utilisateurs de médias interactifs . supposer que :hover
n'est pas toujours supporté.
Pour approfondir la question, relisez Safari Mobile avec la spécification suivante:
De plus, les utilisateurs de Safari sur iOS interagissent avec votre contenu Web directement avec leurs doigts, plutôt que d'utiliser une souris. Cela crée nouvelles opportunités pour les interfaces tactiles, mais ne fonctionne pas bien avec les états de survol. Par exemple, un pointeur de souris peut survoler un élément de page Web et déclencher un événement; un doigt sur un écran multi-touch ne peux pas. Pour cette raison, les événements mouse sont émulés dans Safari sur iOS . En conséquence, éléments qui reposent uniquement sur mousemove, mouseover, mouseout ou la pseudo-classe CSS: le survol peut ne pas toujours se comporter comme prévu sur un appareil à écran tactile tel que iPad ou iPhone.
Vous pouvez manipuler les contacts directement ou même détecter des gestes avancés dans Safari sur iOS, à l'aide des événements tactiles DOM Touch, TouchStart, Touchmove, touchend, et touchcancel. Contrairement aux événements de souris émulés, DOM Les événements tactiles sont spécifiquement conçus pour fonctionner avec des interfaces tactiles, leur comportement est donc fiable et attendu.
5. Préparer une interface tactile https://developer.Apple.com/library/content/technotes/tn2010/tn2262/_index.html
Apple indique clairement ici qu'ils ont tendance à émuler le pointeur avec les gestes tactiles, mais ils suggèrent clairement d'éviter d'utiliser la pseudo-classe :hover
car ils ne se comporteront pas de la même manière sur leur périphérique tactile.
Nous pourrions creuser plus profondément et récupérer chaque documentation pour chaque agent utilisateur existant sur la Terre, mais les deux précédentes sont suffisantes pour supposer ce qui suit:
:hover
:hover
:hover
:hover
, selon son interface.:hover
car il s'agit d'une aide visuelle pour l'utilisateur.Donc, pour répondre à toutes les questions que j'ai assumées ci-dessus:
"Est-ce que
:hover
est un élément standard sur le web?"
Hover est un W3C standard. En fait, il déclare que doit être déclenché par un événement de pointeur, mais n'est pas requis pour certaines interfaces.
"Puis-je utiliser
:hover
sur tous les appareils?"
Oui vous probablement pouvez. Les appareils qui ne prendront pas en charge: les appareils/utilisateurs qui ne sont probablement pas votre cible principale Mieux vaut vous demander "Qui sera l'utilisateur final de mon produit?" s'ils ne sont que des utilisateurs mobiles ou que des aveugles ou que les personnes qui aiment naviguer avec la Nintendo DS, n'utilisent pas les événements :hover
, sinon."Est-ce que :hover
se comportera de la même manière sur tous les appareils?".
Si vous envisagez une action utilisateur via un état de survol, ne le faites pas. C’est généralement une mauvaise pratique à éviter dans tous les cas, y compris les appareils de bureau. Survoler n'est pas un appel à l'action, cliquez est. Le survol ne doit pas être traité comme une "bascule" mais plutôt comme une aide visuelle pour l'utilisateur lui permettant de comprendre que cet élément déclenche une action en cas de clic.
Si j'ai bien compris votre application, le survol n'est pas fiable et, dans votre cas particulier, vous devriez repenser son fonctionnement . Utilisez une méthode plus fiable (et attendue de votre utilisateur).
If you plan to have an user action via a hover state don't do it. This is generally bad practice and it should avoided in any case, including desktop devices. Hover is not an call to action, click is. Hover should not be treated as a "toggle" but more like a visual helper for the user making him/her understand that element, if clicked, triggers an action.
If I understood your application then hover isn't reliable and in your specific case you should rethink on how it should work.Use a more reliable method (and expected from your user)
Survoler le curseur de la souris sur un élément de page Web est une action courante lorsque vous naviguez avec la souris et le clavier, mais il n’ya pas d’équivalent pour la navigation tactile. Cette rubrique explique comment utiliser la propriété DOM (Document Object Model) aria-haspopup
pour simuler le survol sur des périphériques tactiles avec Internet Explorer 10 sous Windows 8.
Ce comportement ne s'applique pas à Internet Explorer 10 sur Windows 7 (qui ne prend pas en charge la simulation de survol avec aria-haspopup) ni à Internet Explorer 11 sur Windows 8.1 (qui prend en charge le survol tactile intégré).
Dans les scénarios tactiles, le survol est appliqué à un élément lorsqu'il est touché. Cependant, taper sur un élément peut également activer un élément, comme la navigation sur un lien. Effectivement, un tap est à la fois un survol et une activation en une seule action. Cela rend le contenu interactif caché derrière le survol inaccessible aux utilisateurs tactiles. Le modèle d'interaction est complètement différent, et il n'y a pas d'analogique tactile pour survoler le curseur de la souris sur un élément de page.
La meilleure pratique consiste à ne pas utiliser le survol pour masquer le contenu qu'un utilisateur peut interagir avec. Au lieu de cela, envisagez d'utiliser l'événement onclick pour basculer le fichier visibilité.
Il me semble qu’une partie de cette question n’a pas encore été résolue, à savoir quel est le comportement réel des téléphones Windows en ce qui concerne le «survol». Clarifier:
Considérez une page Web écrite pour une utilisation bureau/souris dans laquelle il y a un balisage CSS afin que le survol change le style appliqué à un objet. Si l’on visualise cette page sur iPhone ou Android et appuie sur l’objet, le changement de style se produit. (c’est-à-dire qu’il se comporte comme si l’objet avait un gestionnaire d’événements onClick () pour changer le style). Est-ce que la même chose se produit sur un Windows Phone?
Je peux répondre à cette question, du moins pour le Nokia Lumia 630 sous Win 8.1:
Non. Lorsque vous appuyez avec votre doigt dans la première partie d'un tapotement, le style change, mais lorsque vous relâchez votre doigt à la fin du tapotement, le style revient à l'original. (Il s’agit sans doute d’une interprétation plus valable de «survol» pour le toucher, bien qu’il s’agisse d’un usage pratique ou non.)
J'ajouterais que l'interprétation iPhone/Safari du survol est également désactivée. Ceci est déclenché lorsque vous appuyez sur un autre objet.
Pour montrer cela et permettre les tests sur différents appareils/navigateurs, j'ai configuré une page de démonstration sur www.davidleader.net/mobiledemo.html . Ceci implémente onClick (), onMouseover () et: survolez pour changer l'opacité d'une image, en en révélant une différente en dessous. (Cela dépend donc de la prise en charge de l'opacité, mais cela existe depuis un moment.) Il existe également un "graphique stupide" sur lequel cliquer pour montrer la fin du survol sur l'iPhone.
Pour résumer, outre qu’il n’existe pas de normes de jure pour l’interprétation du survol sur des appareils mobiles, il n’existe pas non plus de règles de facto. Par conséquent, si vous ciblez les mobiles, évitez le "survol".
Aucun n’a pour le moment un bon support pour: l’état de survol dans le mobile
Voir question connexe à ce sujet
Je n'ai pas utilisé Modernzr.js pour mobile, mais il indique qu'il peut détecter si le navigateur prend en charge les événements tactiles. Il ajoute donc la classe ".touch" dans la balise HTML si l'utilisateur utilise un appareil mobile.
donc vous allez l'utiliser comme ça, par exemple
.touch a:active{ /*css code here */ }
espérons que cela aiderait en quelque sorte
En ce qui concerne les téléphones mobiles, je doute qu’il existe une norme. Oui, il est très courant qu'un périphérique tactile applique un état de survol pendant qu'il est touché, mais vous ne pouvez jamais savoir si un utilisateur peut utiliser un nombre quelconque de navigateurs pouvant interpréter différemment un état de survol.
Je dirais que votre meilleur pari serait de viser le plus petit dénominateur commun et de supposer que chaque appareil tactile ne peut que répondre à des actions tactiles.
La réponse à cette question est bien sûr d’écrire des requêtes multimédia et/ou javascript pour forcer les navigateurs à agir comme vous le souhaitez.
C'est juste ma philosophie personnelle, pour ce que cela vaut.