5577 sujets

Sémantique web et HTML

Class="is-closed" VS. data-state="closed" ?

Bonjour à tous,

petite question de bonne pratique que je me pose ce matin...

CSS possède déjà toute une flopée de pseudo-classes (:hover, :nth-child, etc...).
Il manquerait cependant des pseudos-classes de type :open, :closed, :hidden qui seraient bien pratiques pour styler l'affichage/masquage de certains éléments du DOM.

On voit la plupart du temps ce type de choses gérées via javaScript avec l'ajout au clic d'une classe "is-open", "is-closed" ou "is-hidden" sur les éléments dont l'affichage doit être modifié.

Ma question est de savoir si l'utilisation de data-attributes (modification de la valeur "open/closed" d'un attribut "data-state" placé sur l'élément) plutôt que de classes CSS est une meilleure, une moins bonne ou une kif-kif pratique pour gérer l'apparition/disparition d'éléments au clic... et pourquoi ?

Par avance merci pour vos interventions Smiley smile
Modifié par FrankHTML (01 Feb 2017 - 08:14)
Administrateur
À mon humble avis c'est kif-kif au niveau de l'exploitation par JS ou CSS puisqu'il "suffît" d'écrire des sélecteurs différents : "." pour les classes comme d'habitude et attribut "[data-state]" pour les autres.

Ensuite sur le fond, je présume qu'il vaut mieux partir sur des classes pour des états qui peuvent avoir des impacts visuels (open/closed, hidden...) et la nomenclature .is- est assez parlante. En bonus non négligeable on peut les accompagner d'attributs ARIA comme aria-hidden="true" si l'élément se voit masqué.

Je réserverais plutôt les data- aux données pures qui ne peuvent être décrites par une classe CSS et d'une valeur totalement libre (ex : un nombre, un groupe de mots). Par exemple une durée d'animation, une référence à un autre élément sur la page...
Je pense aussi qu'au final cela revient au même mais utiliser des classes Css est beaucoup plus parlant pour les éventuelle retouches/maintenances.
Hello,

Pour répondre directement à ta question, les deux sont équivalents étant donné qu'un sélecteur d'attribut a la même spécificité qu'un sélecteur de classe.

Cependant la vraie bonne pratique serait de penser à l'accessibilité, et que l'élément masqué dispose d'un attribut 
aria-hidden="true"
Le JS se contente alors d'enlever ou ajouter cet attribut selon l'état — ce qui ne change pas grand chose au JS — et tu peux accrocher tes styles avec un sélecteur d'attribut :

[aria-hidden="true"] {
  display: none;
}


Cependant il faut implémenter les choses jusqu'au bout : l'élément qui déclenche l'apparition / disparition doit être équipé lui aussi d'attributs aria : aria-controls="ID du truc qui apparaît" et aria-expanded="true/false" selon si l'élément est masqué ou non.

Quelques exemples de cette interaction :
— Bootstrap 4
— van11y

Voilà, j'espère que ça t'aidera Smiley cligne
Moi aussi je réserve les classes pour le css. Je reserve les data-* pour le js et pour les données de contenus pouvants êtres gérées via le css. Pour un tableau responsive par exemple ou encore des donnees qui pourraient être appelees via content sur un imput radio stylisé (c'est mieux pour la traduction qu'une valeur en dur dans le css).
Modifié par Olivier C (01 Feb 2017 - 12:52)
Modérateur
Ten a écrit :

Cependant la vraie bonne pratique serait de penser à l'accessibilité, et que l'élément masqué dispose d'un attribut 
aria-hidden="true"
Le JS se contente alors d'enlever ou ajouter cet attribut selon l'état — ce qui ne change pas grand chose au JS — et tu peux accrocher tes styles avec un sélecteur d'attribut :

[aria-hidden="true"] {
  display: none;
}



Ce n'est pas terrible de mélanger aria-hidden et display: none (ils ne servent pas à la même chose, tu peux avoir besoin de l'un sans l'autre), si le but est de cacher complètement un élément à tout le monde, la recommandation actuelle est plutôt d'utiliser l'attribut hidden doublé de display: none pour compatibilité.
C'est un exemple Smiley smile

Dans le cas d'un élément qui s'ouvre et se ferme, aria-hidden est nécessaire pour respecter le motif de conception ARIA — d'où ma recommandation.

Mettre display: none; directement sur [aria-hidden="true"] est effectivement risqué, on peut se servir de cet attribut pour d'autres éléments qui ne seraient pas masqués visuellement…
Administrateur
Bonjour,

FrankHTML a écrit :
CSS possède déjà toute une flopée de pseudo-classes (:hover, :nth-child, etc...).
Il manquerait cependant des pseudos-classes de type :open, :closed, :hidden qui seraient bien pratiques pour styler l'affichage/masquage de certains éléments du DOM.

On voit la plupart du temps ce type de choses gérées via javaScript avec l'ajout au clic d'une classe "is-open", "is-closed" ou "is-hidden" sur les éléments dont l'affichage doit être modifié.

CSS a pour but de styler des éléments du DOM tandis que JS est le le langage de script des navigateurs web qui permet de "dynamiser" l'ensemble.
La frontière est devenue plus floue avec les possibilités offertes par :target, :checked, etc, possibilités dont il est régulièrement bien abusé (et CSS in JS est la réponse ultime à tous les problèmes de CSS Smiley troll ) mais ce n'est pas souhaitable pour autant.
Les limitations de CSS sont nombreuses :
- ça se désactive (ou ne se charge pas, shit happens)
- pas de sélecteur parent
- pas de sélecteur "frère précédent" fiable / robuste (:nth-last-child() atteint vite ses limites même si c'est fascinant). Indispensable si l'on veut non seulement modifier l'état d'un élément mais en même temps modifier l'état de tous ses frères ou (avec le parent) modifier un élément à l'autre bout du DOM
- la couche (l'API) d'accessibilité des navigateurs et donc les lecteurs d'écran ne vont pas restituer d'autre état que "affiché"ou rien, coché / pas coché alors que le DOM est d'une grande richesse. Refaire en CSS tout ce qu'on peut modifier en JS... y aurait du boulot.
- pas de gestion du focus : suffit pas que ça s'affiche correctement ; il faut aussi que ça fonctionne au touch, au clavier, avec un zoom navigateur (graphique ou texte) ou système (Win 10 sur un 13,3" full HD) voire en mode de contraste élevé (Windows)

C'est pas fait pour ça. Smiley smile
Modifié par Felipe (01 Feb 2017 - 17:22)
Bonsoir,

J'approuve totalement cette pratique de raisonner directement avec ARIA si c'est pertinent.
Typiquement pour les états ouvert/fermé, coché/décoché, affiché/masqué, ça l'est. C'est une bonne chose parce que ça force à penser juste, sémantique de l'interface utilisateur.
J'essaye d'imposer ou de proposer ça où je peux.

Par contre pour aria-hidden, c'est une mauvaise idée. Il faut bien vous rappeler que display:none est une des rares propriétés CSS prise en comtpe par les lecteurs d'écran.
Donc non seulement c'est de la redondance inutile, mais ça vous empêchera d'utiliser aria-hidden dans le cas où il pourrait réellement être pertinent.

ARia-hidden a pour but de masquer aux lecteurs d'écran des choses qui doivent rester affichées pour les autres. Par exemple, des icônes ASCII, ou de l'ASCII-art... Les premiers sont moyennement utiles car la plupart du temps mal étiquetés (malheureusement), et le second est carrément gênant.
Les numéros de ligne dans un code source peuvent eux aussi être gênants.

La propriété CSS display de son côté s'applique universellement et en dépit de son nom, à tous les moyens de restitution quels qu'ils soient: écran, synthèse vocale, braille...
C'est important de bien faire le distinguo.
Sujet clos
Aller à