Avec une plus grande prolifération d’appareils que jamais auparavant, nous, les développeurs, ne pouvons plus compter sur la taille de la fenêtre d’affichage comme facteur déterminant les styles que nous proposons aux utilisateurs de notre site Web. Jusqu’à assez récemment, nous nous sommes peut-être surpris à faire des hypothèses en fonction de la taille d’un appareil : que les appareils mobiles s’appuieraient sur la saisie tactile, par exemple, tandis que pour les écrans plus grands, nous pourrions supposer que la majorité des utilisateurs interagiraient avec notre page Web en utilisant une souris. Nous pouvons proposer différentes expériences avec une requête multimédia :
.some-component {
/* Styles for touch devices */
}
@media screen and (min-width: 1024px) {
.some-component {
/* Styles for hover-able devices */
}
}Cela ne nous aide pas vraiment aujourd’hui. Un iPad décent a une résolution d’écran plus élevée qu’un ordinateur portable bas de gamme. Ou quelqu’un pourrait utiliser sa tablette comme moniteur secondaire – l’utiliser de cette façon avec une souris signifierait qu’il serait pouvoir utiliser leur pointeur pour survoler les éléments. Mais la requête multimédia ci-dessus ne nous dit rien sur leur méthode de saisie.
De nos jours, nous devons être plus sophistiqués sur la façon dont nous détectons la façon dont un utilisateur navigue sur notre site. Heureusement, certaines requêtes médiatiques plus récentes servent précisément cet objectif.
Requêtes média de niveau 5
La spécification CSS Level 5 Media Queries nous apporte toutes sortes de nouvelles requêtes multimédias au-delà des requêtes habituelles pour la taille de la fenêtre d’affichage. L’un d’eux est la fonction de survol. Cela détermine si le périphérique de pointage principal de l’utilisateur est capable de survoler la page. Les valeurs possibles sont hover (ce qui serait vrai pour un appareil avec une souris, par exemple) ou none (ce qui serait vrai pour une tablette utilisée avec une entrée tactile). Nous pouvons utiliser la requête multimédia comme ceci :
.some-component {
/* Styles for touch devices */
}
@media (hover: hover) {
.some-component {
/* Styles for hover-able devices */
}
}Voir la requête média Pen Hover par Michelle Barker (@michellebarker) sur CodePen.
Cela fonctionne bien dans la plupart des navigateurs, mais certaines versions d’Android ont une fonctionnalité où un appui long émule le survol, de sorte que la requête multimédia est évaluée comme vraie. Si nous voulons servir les mêmes styles à ces utilisateurs que ceux des autres appareils tactiles, nous devons interroger une deuxième fonctionnalité multimédia.
Aiguille
Le pointer La fonctionnalité teste si le périphérique dispose d’un pointeur et la précision du périphérique de pointage. Les valeurs possibles sont coarse (pour un pointeur tel qu’un doigt utilisé sur un écran tactile), fine (une souris, par exemple) ou none (un appareil sans pointeur).
L’ajout de ceci à notre requête multimédia détecte avec succès la saisie tactile sur les appareils Android :
.some-component {
/* Styles for touch devices, including Android */
}
@media (hover: hover) and (pointer: fine) {
.some-component {
/* Styles for hover-able devices */
}
}Voir la requête média Pen Hover par Michelle Barker (@michellebarker) sur CodePen.
any-hover et any-pointer
Si cela ne suffit pas, le any-hover et any-pointer les fonctionnalités multimédias nous permettent de tester les capacités de n’importe quel d’un périphérique périphériques d’entrée – pas seulement le principal. Donc, si vous avez un appareil qui répond à la fois à une souris et saisie tactile any-hover: hover serait vrai.
Je n’ai pas encore eu besoin d’utiliser ces fonctionnalités, mais la spécification comprend plusieurs exemples d’utilisation, avec des considérations différentes (et plus complexes).
Exemple Javascript
J’ai récemment créé une page Web où le survol de l’un des liens d’images identiques faisait apparaître le nom du lien, un peu comme une info-bulle. Mais les utilisateurs d’appareils tactiles ne verraient pas cette info-bulle. Au lieu de cela, cliquer sur l’image amènerait l’utilisateur directement à l’URL du lien, ce qui pourrait être une expérience choquante car il ne saurait pas quelle page il visite. Au lieu de cela, pour les appareils tactiles, j’ai décidé d’interrompre le clic et d’afficher un bouton sur lequel l’utilisateur pourrait ensuite appuyer pour accéder à l’URL appropriée. Nous pouvons utiliser la même requête multimédia pour détecter la saisie tactile dans JS, en utilisant matchMedia:
const list = document.querySelector('[data-list]')
const isHoverableDevice = window.matchMedia(
'(hover: hover) and (pointer: fine)'
)
/* Hide the block link initially */
blockLink.hidden = true
list.addEventListener('click', (e) => {
/* Do nothing if target is not a link, or device is hover-capable */
if (!e.target.dataset.link || isHoverableDevice.matches) return
/* If touch device, show the block link */
e.preventDefault()
blockLink.hidden = false
blockLink.innerText = `Visit ${e.target.dataset.link}’s page`
blockLink.setAttribute('href', e.target.href)
})Une démo rapide :
Voir l’info-bulle Pen Touch/hover de Michelle Barker (@michellebarker) sur CodePen.
Accessibilité
En fonction de l’interface utilisateur, nous pourrions vouloir aider les technologies d’assistance ici, en utilisant les attributs ARIA pour annoncer le bouton lorsque le changement se produit, ou en déplaçant le focus de l’utilisateur sur le bouton. Cet exemple de MDN comprend une démonstration de l’utilisation des régions en direct ARIA pour annoncer des modifications dynamiques d’un élément.
Prise en charge du navigateur
La bonne nouvelle est que vous pouvez utiliser ces requêtes multimédias dès maintenant, car elles sont prises en charge par tous les navigateurs modernes. Vous pouvez désormais offrir de meilleures expériences aux utilisateurs de tous dispositifs!