C'est la rentrée, et comme toute rentrée, nous avons des splendides marronniers qui fleurissent. Précisons qu'un marronnier est un sujet de faible importance meublant une période creuse en journalisme.
En toute honnêteté, j'ignore si c'est un sujet de faible importance, toutefois, je me retrouve à en parler. De quoi ? Des classes sémantiques en HTML bien sûr !
Les classes, c'est ment… hic.
Les questions qui se posent sont les suivantes. Je les résume rapidement :
- Doit-on aller à fond vers une approche « classes réutilisables intégralement posées sur la structure HTML façon OOCSS » ? En gros
<p class="right w20 aligncenter"pour un bloc de 20% de large, flottant à droite et dont le texte est centré. - Doit-on garder uniquement des classes dites « sémantiques » ? Autrement dit
<p class="le_nom_de_la_classe_qui_décrit_ce_qu_il_contient", par exemple<p class="auteur".
Ce genre de débat me fait sourire, car il est non-sensique et tourne à la querelle de chapelles. Revenons à la base. Je vous invite à déjà aller lire un excellent billet de Karl Dubost qui explique ce que sont les classes sémantiques à la base dans Un HTML avec class et des id, je cite (la mise en gras est de mon fait).
Le phénomène est simple et révèle le sens des priorités d'affaires. Le codeur de front a très rarement à réaliser un document sémantiquement communiquant.
J'irais même plus loin, LA question à se poser est la suivante : est-ce que l'objet contenu dans ma balise HTML doit être manipulé par une tierce personne (par exemple un collègue via du JavaScript) ou via une autre manière (une API qui extrait des données par exemple) ? (je généralise un peu la notion de communiquant)
Si votre réponse est oui, alors il faut attacher une classe sémantique à votre balise, et ce même si des classes non-sémantiques y sont déjà attachées. Juste pour dire « youhou, ce truc que j'ai positionné ainsi, je le référence comme étant tel-truc pour qu'on puisse l'atteindre et le manipuler ».
Revenons à nos deux questions plus haut. On met tout sur la structure HTML ou tout sur la CSS ? Hé bien, ça dépend du cas de figure et de votre approche bien sûr. Je le dis de suite, ce ne sont que des exemples de ma vision personnelle, ça dépend vraiment du contexte.
Des exemples
Si je reprends OOCSS, l'idée est de séparer les propriétés de positionnement d'un bloc de celles de mise en forme du même bloc. C'est pour cela que si une maquette me demande de positionner en flottant à droite avec des marges, etc. un bouton, je vais utiliser ceci avec RÖCSSTI :
<button class="right button-reload ml1"…
Dans ce cas, les classes non-sémantiques right et ml1 de RÖCSSTI suffisent à positionner le bouton, et la classe button-reload va s'occuper de styler le look du bouton proprement dit. C'est de l'OOCSS vite fait bien fait.
Si on me dit « sur la page qui affiche tel produit, il me faut un lien de retour à la liste positionné à droite », je vois pas l'intérêt d'y accrocher une classe sémantique, ce lien n'a que peu de valeur et n'a à priori pas de besoin d'être manipulé par une API extérieure ou via du JavaScript. Donc, là je le dis très clairement, je me brosse d'utiliser une classe sémantique dans ce cas.
<a class="right ml1">retour à la liste</a>
Si je tombe sur un cas où les classes non-sémantiques ne suffisent vraiment pas à couper la moutarde comme diraient les anglophones, évidemment je vais créer une classe spécifique et tant qu'à faire lui donner un poil de sens.
Autre cas, supposons qu'on me dise : « attention, la structure ne devra pas bouger, mais on aura des styles alternatifs ». Là évidemment, je vais éviter les classes non-sémantiques, car dans ce cas, elles vont inscrire dans le marbre le positionnement de mes contenus. Cela m'est déjà arrivé – et pas uniquement sur mon site personnel –, même si c'est rare. Un client dont je tairais le nom m'a imposé un redesign sur un délai quasi-intenable. Fort heureusement, la structure n'utilisait pas de classes non-sémantiques, j'ai donc retouché au minimum la structure, et j'ai tout basé le redesign sur la CSS, ce qui m'a permis de réaliser l'impossible.
Supposons que je sois dans la situation suivante : j'ai deux contributeurs peu rompus au CSS et je suis surchargé de travail. Typiquement, je vais aller vers des classes autant réutilisables que possible, pour la simple raison que mon temps sera le point le plus critique et qu'il sera plus difficile de me monopoliser, et au passage, ils comprendront mieux des classes non-sémantiques.
Etc. Les cas de figures sont tellement nombreux et interdépendants que ces choix peuvent varier. Bien sûr, ces points de vue sont purement pragmatiques. Le CMS, l'équipe, le client, vos connaissances, la taille du projet, sa complexité, etc. tout cela, ce sont des paramètres qui peuvent influer.
Et vous ferez comme moi, vous vous planterez. De votre faute ou non, mais vous vous planterez, tout simplement parce qu'un postulat de base aura changé ou était faux. Ce n'est pas un drame.
Pré-processeurs
Les pré-processeurs permettent des choses qui seraient beaucoup plus laborieuses sans, typiquement, si je reprends le premier exemple du bouton, le code pourra ressembler à cela :
<button class="button-reload"…
et dans la CSS version Sass :
.button-reload {
@extend .right; // ce qui donnera .button-reload, .right { float: right; }
@extend .ml1; // idem
}Le pré-processeur CSS peut offrir dans certains cas la possibilité de reporter la complexité de la gestion des classes sur la CSS et non plus sur la structure HTML. Encore une fois, il n'y a pas de vérité absolue, selon les cas, cela peut rendre de grands services, et dans d'autres cas, cela peut être pénible.
Pour conclure
Comme vous pouvez le voir, selon l'approche, les choix peuvent varier. Ceci dit, ces débats incessants sont un peu stériles, car même en ayant une approche bourrin sur les classes en structure HTML, cela n'empêche de toute manière pas d'en rajouter une avec une valeur sémantique.
Quand le sage désigne la lune, l'idiot regarde le doigt.
Bref.
Tandis que l'idiot alimente des querelles de chapelles, le sage pratique CSS.
Ite missa est.
