Mais probablement pas pour les raisons auxquelles vous pourriez penser de prime abord, je pense. Attention, ceci nʼest quʼune réflexion et sera peut-être truffée dʼerreurs, pleine de non sens et de raccourcis.
La séparation du fond et de la forme
Ce principe est assez clair. Parfois on lʼassocie également à un autre principe, celui de la répartition des responsabilités — en anglais, separation of concern — et on aboutit généralement à celui de la responsabilité unique — single responsibility, toujours chez nos amis anglophones.
Dans mes langages dʼaffection que sont le HTML et le CSS, ça se traduit actuellement par les CSS atomiques — dont jʼai déjà parlé, et sur lesquels je vous invite à vous renseigner.
En développement web et notamment sur le front-end, la conception MV* en est le digne représentant. Sommairement, chaque couche a une responsabilité précise :
- le modèle est celui des données (pures et dures) ;
- la vue est lʼinterface utilisateur ;
- et le reste sert à manipuler tout ça comme un marionnettiste — la plupart du temps, on parle de contrôleur.
Super, le tour du propriétaire est terminé. Vous voulez mon avis ? Cʼest nul et non applicable aux couches HTML et CSS.
Lʼimportance du HTML
Un rapide cours dʼhistoire est déjà fait dans lʼintroduction de lʼarticle. Le mauvais emploi de balises HTML à des fins de présentation a traumatisé pas mal de monde, il y a de ça 10 ou 15 ans. Les tableaux, les éléments — coucou font
, big
, blink
, center
, marquee
ou spacer
— et attributs dédiés en sont pour beaucoup.
Là encore, je souhaite nuancer : ce ne sont que des outils. Les ouvriers qui sʼen sont servis ont fait nʼimporte quoi avec. Cʼest ça, la véritable histoire. On sʼest donc mis en tête de récupérer un vieux principe de programmation et de lʼappliquer tant bien que mal sur HTML et CSS en disant :
HTML est le fond, CSS est la forme .[1]
Cʼétait un moyen simple et efficace dʼéjecter du versant HTML ce qui avait trait à la présentation. Et ça, c’était bien. En effet le HTML doit être employé pour sa sémantique, le sens quʼil apporte au contenu quʼil balise. Car cʼest tout ce quʼest censé faire ce langage : décrire le contenu sur le plan sémantique.
**
Utiliser des propriétés de style dans le HTML revient à corrompre la sémantique** : le contenu ne sera plus marqué correctement et pourra donc être mal interprété. Et ça, cʼest mal.
En quoi est-ce contradictoire avec la séparation fond/forme ?
Jʼai esquissé pourquoi il fallait éviter de mettre des informations de styles dans le HTML. Cʼétait pas trop compliqué.
Cependant aujourdʼhui, cet argumentaire ressurgit pour justifier lʼutilisation de classes partout, tout le temps, dans nos CSS. On nous recommande de ne pas utiliser de sélecteurs dʼéléments ou dʼattributs — voire même dʼimbrications comme ul > li
— car elles induisent un lien trop fort avec le HTML et enfreigne donc ce concept de séparation du fond et de la forme.
Précisons mon avis sur le sujet : ce principe ne vaut pas pour les CSS. Je poursuis sur ma lancée.
À quoi sert le style ?
Selon moi, il sert à hiérarchiser visuellement les éléments les uns des autres. Un « gros titre », les « petites lignes »… Ces expressions décrivent un contenu dʼaprès leur aspect visuel mais aussi et surtout, leur (relative) importance sémantique.
Pour résumer le fond de ma pensé : si un élément est important sémantiquement côté HTML, il devrait avoir une représentation visuelle qui reflète cette importance.
Pourquoi ?
Mais ma bonne dame, parce que sinon vous induirez une distinction entre diverses méthodes de lecture de votre contenu — entre les technologies qui lisent le code (les robots, les lecteurs d’écrans, les moteurs en tous genres) et celles qui regardent le style (les personnes bien voyantes, les captures dʼécran, et certains moteurs tels que les outils de test de régression visuelle). Et ça, cʼest pas terrible. Cʼest même plutôt pourri, à mon avis.
En fait jʼirais encore plus loin : si vous séparez trop votre forme de votre fond .[2]
Lʼaspect graphique devrait renforcer la structure de lʼinformation et la hiérarchisation des contenus, pas la gommer ni la falsifier.
Encore un peu dʼhistoire
Au fait, vous souvenez-vous que CSS est ce qu’on appelle un langage descriptif ? Dʼailleurs, les plus vieux dʼentre vous se rappelleront sans doute quʼà lʼorigine CSS nʼétait pas destiné aux styles visuels mais à la description de la présentation du contenu. Et non, ce nʼest pas pareil. Cela comprenait lʼaspect graphique, mais aussi dʼautres médias oubliés, de nos jours. Voyez plutôt.
- La vocalisation avec le média
speech
— on parlait de feuille de styles orales (en CSS1, le média se nommait dʼailleursaural
), qui comprenaient le contrôle du volume, de la vitesse, mais aussi du type de voix (masculine ou féminine, par exemple). Jetez un œil à lʼappendice à la spécification CSS2 (en anglais). Tout ceci nʼa jamais vraiment été implémenté, sauf par Opéra il y a fort longtemps. - Le braille, avec les médias
braille
etembossed
, qui permettaient de contrôler respectivement le rendu par une plage de lecture braille et par une imprimante braille. - Les projecteurs grâce au média
projection
, ainsi que les écrans de télévision avec le médiatv
. - Les téléscripteurs (ou prompteurs), terminaux et tous les systèmes avec des capacités dʼaffichage limitées aux fontes monospaces avec le média
tty
.
Dès la deuxième partie des années 90, les personnes travaillant sur la spécification CSS envisageaient cette multitude de façon dʼaccéder au contenu. Et aujourdʼhui on se gausse de faire un site qui sʼaffiche sur la plupart des écrans…
Morale de lʼhistoire
Simplifions.
CSS ne devrait pas être utilisé pour altérer lʼimportance sémantique d’un contenu. Et par extension, utiliser les sélecteurs dʼéléments ou dʼattributs semble une bonne idée. Je reformule au cas où : séparer le fond de la forme est une bonne idée, mais pas séparer la forme du fond. La forme dépend du fond, là où le fond ne dépend pas de la forme.
Pour ceux qui ont tenu jusque là, je vous invite à prendre le temps de lire la page Wikipédia dédiée à CSS. Cʼest fort intéressant .[3]
Toute ressemblance avec le slogan dʼune enseigne de sport est parfaitement fortuite. ↩︎
Notez lʼordre des termes fond/forme, forme/fond. ↩︎
Par exemple, on y apprend que le mécanisme de la cascade tant décrié de nos jours par lʼécosystème des développeurs JS est conçu pour permettre aux utilisateurs dʼappliquer leurs propres styles. Cʼest oublié, mais ça nʼen reste pas moins génial. ↩︎
> vous permettez à vos CSS de falsifier visuellement la hiérarchisation de vos contenus. Ceci nʼest, toujours à mon avis, pas souhaitable.
> Lʼaspect graphique devrait renforcer la structure de lʼinformation et la hiérarchisation des contenus, pas la gommer ni la falsifier.
Sur le principe, 100% d’accord. En pratique, la réalité fait qu’il y a toujours des entorses à ce principe, même si je reconnais que ça devient de plus en plus rare (j’ai déjà dû faire des sites délirants où la structure hx est complètement décorrélée des classes hx que j’y appliquais…). Heureusement que ça disparait petit à petit (enfin, de mon point de vue limité).
Rigolo d’ailleurs, quand on sait que l’attribut class était à l’origine pensé pour ajouter du sens (l’ancêtre des micro-datas), je crois que c’est Bert Bos qui avait expliqué ça à Sud Web 2012.
Tu devrais lire https://www.la-grange.net/2013/07/24/html de Karl, très intéressant.