Les id sont nos amis

Nicolas Hoffmann ~ 3 minutes

Commentaires (18)

De nombreux conseils sur CSS indiquent de se passer des id pour cibler les éléments dans la feuille de style. CSS Lint, OOCSS, et plein de gens nous expliquent, avec force arguments, qu’il faut à tout prix cibler par des classes chaque élément, et donc laisser tomber les id.

Je ne vais pas m’amuser à revenir sur le sujet, toutefois, je veux lancer un appel, que dis-je, un cri d’alarme : les id sont en voie d’extinction ! Et c’est terrible pour la diversité… non pas de nos sélecteurs CSS (et encore, des gens comme Jeffrey Zeldman se posent des questions), mais de nos structures HTML.

Hé oui, comme toujours quand une mode, ou dirons-nous un courant de pensée apporte quelque chose d’intéressant, on a tendance à le suivre aveuglément, ou pire, à l’appliquer de manière jusqu’au-bout-iste en dépit du bon sens. Donc – générique avec une musique forte –, j’affirme haut et fort qu’il faut sauver le soldat id.

Il faut sauver le soldat id

Les id sont indispensables, en voici quelques exemples.

Dans le cas des formulaires, il est capital de lier les champs avec leur label, et cela se fait par l’id. Par exemple :

<label for="id_nom">Nom (obligatoire) : </label> <input type="text" name="nom" required="required" aria-required="true" id="id_nom" size="30" maxlength="250" value="" />

Dans le cas des tableaux complexes de données, le lien entre cellules et entêtes se fait aussi via les id quand les attributs scope=« row » et cols ne suffisent plus. Voici un exemple très simple (pour d’évidentes raisons de longueur).

<table>
 <caption>Ici la description du tableau</caption>
 <thead>
  <tr>
   <th id="titrelien">Liens</th>
   <th id="images">Images</th>
  </tr>
 </thead>
 <tfoot>
  <tr>
   <th>Titres et liens</th>
   <th>Images</th>
  </tr>
 </tfoot>
 <tbody>
  <tr>
   <td headers="titrelien">
    Ici le lien et le titre 
   </td>
   <td headers="images">
    ici l'image
   </td>
  </tr>
 </tbody>
</table>

Autre point, il est important de proposer des ancres internes, et cela se fait également par les id. Cela sert notamment aux liens d’évitement, à un lien de retour vers le haut de page, à un sommaire pour une longue page.

<a href="#menu">Aller au menu</a>

Vous me direz, l’air un peu goguenard : ce ne sont que des points d’accessibilité. Je vous répondrai que l’accessibilité c’est bien, et que vous êtes <mettez un juron pour dire que l’accessibilité n’est pas une option>, mais si ce n’est pas votre dada, alors surtout… pensez à vos versions smartphones. Les ancres internes permettent de réellement améliorer le confort de navigation. Supposons un design classique à trois colonnes. Supposons que ce design soit linéarisé en version smartphone. Imaginons un petit formulaire dans la dernière colonne, celle donc qui sera le plus en bas quand le contenu sera linéarisé.

Si vous avez un lien qui doit pointer vers ce formulaire, vos visiteurs seront très contents d’arriver directement au bon endroit, ou au pire, en haut de la – désormais linéarisée – colonne concernée. Notons qu’il sera aussi très agréable, une fois ce formulaire soumis, d’arriver pile à l’endroit où le message de confirmation de ce formulaire apparaîtra. Au lieu d’aller chercher des solutions en JavaScript ou en Jquery, autant utiliser des choses simples et élégantes : les ancres internes et donc les id.

Donc, si je n’ai pas à critiquer la forte diminution des id dans les CSS, je m’insurge violemment contre des lectures trop extrêmes de règles CSS et leur raréfaction dans les structures HTML.

Qu’on se le dise : utiliser les id avec classe est indispensable !

Nicolas Hoffmann

À propos de Nicolas Hoffmann

Nicolas est un soldat monté au front (-end) depuis un peu plus de 10 ans. Auteur du micro-framework CSS Röcssti, féru d'accessibilité et co-directeur du collectif Openweb, son côté obsessionnel de la qualité lui occasionne parfois le doux surnom de « suisse-allemand de la qualité Web ». Le pire, c'est qu'il en est plutôt fier. Parce que « c'est fini le rigole quand on fait la checklist » (à dire avec un accent allemand, ça fait son effet dans l'agence web).

18 commentaires sur cet article

  1. Clement Herreman, le jeudi 6 décembre 2012 à 00:20

    Bonne piqure de rappel sur la vrai utilisation des ID, en terme d’accessibilité et de fonctionnalités propre au navigateur, et non pas uniquement pour $(”#carousel”).carousel()

  2. mlb, le jeudi 6 décembre 2012 à 00:27

    Dans la mesure où, souvent, le label peut contenir l’input auquel il est rattaché, on peut ‑dans la plupart des cas- se passer de l’attribut id.
    L’argument principal à mon sens est la vitesse des queries JavaScript qui peut s’en voir doublée sur un DOM assez conséquent. (cf http://jsperf.com/document-getelementbyid-vs-other-selectors)

  3. Damien, le jeudi 6 décembre 2012 à 09:04

    Bien sûr que les ID sont importants. Par contre, dans le CSS ils posent plein de problèmes. Je vous invite à lire cet article, fort pertinent et contre les ID’s (sans en interdire l’utilisation dans le HTML) : http://csswizardry.com/2012/11/code-smells-in-css/

  4. Sebastien, le jeudi 6 décembre 2012 à 09:15

    Bonjour et merci pour cet article.

    Une chose me chiffonne cependant : la comparaison « style/comportement ».

    Ces temps ci on conseille bien de ne plus utiliser d’id pour cibler des éléments à styler dans nos CSS (à cause notamment de leur spécificité), et c’est tout.

    Les ancres (et autres) quant à eux ne servent qu’à des comportements (voire à l’accessibilité) dans la page. Ainsi, le conseil à propos des id ne s’applique évidemment pas dans leur cas.

    Voilà, je tenais à faire cette distinction m’apparaissant un peu trop implicite dans l’article (il s’agit bien de ne pas suivre les modes aveuglément, encore faudrait-il parfaitement pouvoir comprendre pourquoi).

  5. Victor Brito, le jeudi 6 décembre 2012 à 09:41

    @mlb Un élément label implicite peut ne pas être identifié comme tel par les lecteurs d’écran. Par conséquent, l’utilisation conjointe des attributs id et for demeure indispensable.

  6. Thibault, le jeudi 6 décembre 2012 à 10:27

    Un rappel plein… de classe !

    –> []

  7. piouPiouM, le jeudi 6 décembre 2012 à 14:06

    Je suis triste de lire des billets comme celui-ci. Non pas parce que leur contenu est mauvais — loin de là — mais parce qu’il est aujourd’hui nécessaire de rappeler la base des bases.

    Intégrateurs, votre cœur de métier ne se limite pas à pisser du CSS au kilomètre. Vos compétences et le savoir que vous avez acquis à la sueur de vos erreurs (vive l’apprentissage par l’échec, la meilleure école de l’intégrateur/développeur Web) ont de la valeur. Alors, s’il vous plaît, ne les rejetez pas sous prétexte qu’un personnage influent clame tout haut une opinion personnelle, mais qui se répand comme une traînée de poudre de part son statut de « gourou ».

    Conservez votre esprit critique qui vous aidera à séparer le bon grain de l’ivraie. Dans le cas présent, lire que les id sont à éviter dans vos feuilles de styles n’implique pas qu’ils doivent disparaître de vos sources HTML…

  8. Etienne, le jeudi 6 décembre 2012 à 14:29

    Bonjour à tous,

    Je suis intégrateur débutant si je puis dire, et cet article me fait me remettre en question quant à mon utilisation des ID, j’espère trouver une réponse ici.

    Le plus important pour moi est d’avoir une méthode de travail qui est toujours la même pour que ce soit plus rapide et plus simple. J’ai tendance à conseiller les ID pour ce qui appartient à la structure du HTML (si c’est du XHTML par exemple) avec les ID qui serviront à la structure, header, footer, content, etc. Et l’utilisation des class pour la mise en forme.

    Est-ce une bonne méthode à votre avis ?

  9. -HR-, le jeudi 6 décembre 2012 à 15:06

    Bonjour,

    > Débat intéressant mais je dois dire que je penche du côté : ID.

    Un ID étant unique l’utiliser sur un container unique est, me semble t‑il,
    des plus naturel plus sémantique. …et plus souple sur les CSS et, ceci,
    sans parler de l’usage des Dom…

    Vaste sujet… ;)

    Cordialement,

    [ps1] : http://blog.goetter.fr/post/36419679266/si-zeldman-le-dit
    [ps2] : …ceci n’est pas un Troll, merci de ne pas le considérer ainsi.

  10. tzi, le jeudi 6 décembre 2012 à 18:31

    Je suis confus devant cet article : CSSLint et OOCSS nous demande de se passer des ids dans nos CSS.
    C’est ce que j’applique personnellement, et je vois que, sur le long terme, le bénéfices sont palpables.

    Néanmoins, dans l’HTML les ids sont très bien.
    Mais je ne les utilise que pour la logique JavaScript ou comme tu dis pour les liens ancres et l’accessibilité.

    Donc ce que je me demande, c’est est-ce que tu utilises ou pas des ids dans tes CSS ?
    Par exemple, j’ai remplacé #header et #footer depuis un petit moment par des classes.
    Qu’est-ce que tu en penses ?

    Merci pour cet article :)

  11. Kévin, le jeudi 6 décembre 2012 à 21:00

    @tzi Je pense vraiment que ça n’a de bénéfice uniquement si tu n’as pas anticipé une évolution *potentielle* en choisissant un ID plutôt qu’une classe.

    Si :

    1) Il n’y aura jamais (aujourd’hui ou dans le futur) 2 éléments x dans une page.
    2) L’élément x ne peut en aucun cas être utiliser dans un autre contexte.

    Alors j’utilise un ID – le header et le footer en sont un bon exemple –, mais si j’ai le moindre doute, j’utilise une classe. Utiliser les classes par défaut n’est certes pas une erreur mais sémantiquement incorrect.

    Et je ne suis pas d’accord avec ceux qui disent (ailleurs) que la forte spécificité de l’ID par rapport à la classe (genre 1 ID = 255 classes) est un problème. Il faut juste savoir l’utiliser à bon escient, aucune méthodologie ne remplacera la maîtrise d’un langage.

    Sinon ça fait plaisir de voir un article sur le sujet pas blindé d’idées subjectives, merci.

  12. tzi, le jeudi 6 décembre 2012 à 22:56

    @Kévin « si j’ai le moindre doute, j’utilise une classe »
    Alors pourquoi ne pas le faire par défaut ?

    « Et je ne suis pas d’accord avec ceux qui disent (ailleurs) que la forte spécificité de l’ID par rapport à la classe »
    J’en fait partie.
    L’intérêt ne se voit pas forcément sur la plupart des projets.
    Par contre, sur ceux où tu travailles à plusieurs ou dont le projet dure sur plusieurs années, la différence est visible selon moi.

    Et en effet, ça fait plaisir de voir un article sur le sujet qui ne sort pas des règles absolues :)

  13. karl, le vendredi 7 décembre 2012 à 03:14

    Un attribut « class » permet de définir une **classe** d’éléments (pas pour les feuilles de style). Par exemple, <span class=« auteur »>Jules Verne</span>. C’est à dire des éléments qui partagent la même sémantique .

    Question à se poser lors de la structuration du gabarit : Quels sont les éléments que j’aimerais extraire à travers tous mes documents et dont la sémantique n’est pas déjà définie dans HTML ?

    Un attribut « id » permet de définir un point d’attache dans le document (pas pour les feuilles de styles). Par exemple, <dfn id=« definition »>Nicolas Hoffmann</dfn> est un homme généreux.

    Question à se poser lors de la structuration du gabarit : Quels sont les éléments que je veux lier et/ou que je veux permettre aux autres de lier dans ce document ?

    Une fois cela fait, la feuille de style utilise les éléments de structuration et d’identification pour ajouter du style. :) Bien sûr, il y a des cas particuliers et il faut garder de la flexibilité. Mais avoir ces deux questions en tâche de fond aident beaucoup à éviter les horreurs.

  14. Nico, le vendredi 7 décembre 2012 à 11:10

    Bon, plusieurs réactions, déjà Karl mentionne un point intelligent. Donc lisez le commentaire ci-dessus, et gardez à l’esprit que poser des classes et des id va plus loin que le bout de la CSS, ce que j’ai essayé d’expliquer ici.

    Tzi, Kevin : en fait, je vais vous révéler un secret pour cette histoire d’id et de class dans les CSS : on s’en fout de ce que je pense et de ce que je fais.

    Déjà, parce que ma parole n’a pas valeur d’évangile et encore moins de vérité absolue, et surtout, piouPiouM a tout résumé dans son commentaire : « Conservez votre esprit critique qui vous aidera à séparer le bon grain de l’ivraie ».

    Et puis… et bien ça dépend (haha !), et ça évolue dans le temps dans mon expérience. Donc je décline toute responsabilité dans le futur sur mes propres propos :)

    Selon le projet, il m’arrive de totalement changer mes postulats qui vont me faire décider d’utiliser un id ou une classe pour cibler un élément en CSS. Cela dépend du type de projet, du degré de volatilité de la maquette et du client, de sa taille, etc.

    Ceci dit, l’important n’est pas le postulat en lui-même, l’important est de se poser des postulats, bref de faire des choix. Et vous en ferez des bons, et d’autres moins.

    Par contre, effectivement, je constate qu’utiliser trop d’id hors de la structure globale pose des problèmes dans la CSS, et effectivement à cet instant, je deviens beaucoup plus méfiant quand à leur utilisation, une zone supposée unique dans une maquette a un potentiel d’ubiquité jamais négligeable.

    La seule certitude que j’ai, c’est qu’appliquer bêtement et à fond une règle, fut-elle aussi bonne et intelligente, mène à un mur.

  15. tzi, le vendredi 7 décembre 2012 à 14:52

    Merci Nico pour ta réponse !

    En effet, ton avis n’est pas parole d’évangile, mais c’était pour éclaircir, pour moi, le point de vue exposé dans l’article.

    Donc finalement, je rejoins ton avis très volontiers ;)

  16. Fredo, le lundi 10 décembre 2012 à 13:42

    Je n’ai pas lu la totalité des commentaires, mais aujourd’hui une question se pose c’est l’importance de l’optimisation. Si nous n’utilisons plus d’id pour cibler les éléments alors nous créer un ciblage avec plusieurs noeuds. Au delà de 2 descendants, des sanctions sont émise sur les gspeed and co pour des raisons de rapidité car les navigateurs prennent quelques micro secondes de plus pour interpréter le code css, c’est pourquoi un id est plus vite cibler pour le navigateur.
    Alors oui « l’optimisation à fond de ballon » peut paraître futile, mais quand on sait que Google influe énormément sur le consortium W3C et que l’optimisation et le temps de chargement font partie de leur recommandations ça fait réfléchir, non ?
    source : http://www.abondance.com/actualites/20100412–10314-google-prend-officiellement-en-compte-le-temps-de-chargement-des-pages-comme-critere-de-pertinence.html

  17. Nico, le mardi 11 décembre 2012 à 10:04

    @Fredo : attention à ne pas optimiser à tort et à travers, pour en être au point où on cherche à optimiser pour qq micro-secondes en CSS, il faut déjà être allé très loin dans l’optimisation sur pleins d’autres postes. D’ailleurs, on appelle ça de la micro-optimisation, ce n’est pas pour rien : économiser une requête HTTP apportera par exemple beaucoup plus de bénéfices que d’aller chercher 2 microsecondes sur un sélecteur CSS.

    C’est comme quand Page Speed t’annonce qu’en minifiant ton HTML, tu peux gagner 763 octets (!)… bon ok, c’est bien, mais pour aller gagner moins d’un ko, il y a peut-être plus important à faire avant d’aller chercher de si petits gains ! :)

  18. Nico, le jeudi 23 mai 2013 à 11:56

    Encore un autre exemple : si vous utilisez des microdatas et avez besoin de itemref=« logo », ça pointe vers l’id logo. Exemple : http://html5doctor.com/microdata/