La séparation de la structure, de la présentation, et du comportement n’est pas morte

Cette semaine, Bertrand Keller a traduit un article de Kevin Dees publié chez ThinkVitamin sobrement intitulé « La séparation de la structure, de la présentation et du comportement est morte« .

Prenons l’exemple d’un lien avec un effet visuel lors du survol de la souris. Vous avez le choix entre passer par la CSS pour un effet :hover et/ou utiliser une petite pincée de JavaScript pour la gestion d’un comportement plus complexe.

Avec un changement de couleur géré en CSS et un effet (une opacité par exemple) en JavaScript, le comportement du lien est spécifié dans deux couches différentes : c’est ce qu’on appelle la « divergence ». Ce lieu de gestion subtile de l’effet de survol par deux couches différentes.

L’intégration n’est pas la collage grossier de différentes couches mais plutôt l’emboîtement subtile de plusieurs technologies (ce qui définit, à mon avis, le principe de l’artisanat).

Je suis totalement d’accord sur les subtilités de l’intégration et de ces différents langages. Cependant, je pense sincèrement que la séparation de la structure, de la présentation et du comportement sur le web est tout sauf morte. Au contraire, je dirais qu’avec HTML5 et CSS3, elle vient juste de naître.

Prenez par exemple un tutoriel pour faire un joli menu publié chez WebDesignerWall en 2007. Le code HTML est pour l’époque particulièrement propre, mais il mélange cependant la structure et la présentation.
<ul id="menu">
<li><a href="#" class="home">Home <span></span></a></li>
<li><a href="#" class="about">About <span></span></a></li>
<li><a href="#" class="rss">RSS <span></span></a></li>
</ul>

Vous voyez ces <span> vides ? Dégoûtants, hein ? Mais avant CSS3, on était obligé d’ajouter du contenu supplémentaire (souvent vide de contenu et vide de sens) pour parvenir à reproduire une charte graphique avec un code un minimum propre. Si vous vouliez réutiliser du code de présentation, vous étiez obligé d’en reproduire la structure.

Maintenant, faisons un saut juste 2 ans plus tard, avec ce tutoriel pour faire des boutons super géniaux en CSS3 publié chez Zurb en 2009. Ce tutoriel ne contient plus que du code CSS. Plus besoin d’une structure imposée. Reprenez les styles de boutons créés, et appliquez les sur n’importe quel contenu, n’importe quelle balise, n’importe quelle structure.

Les nouveaux langages du web nous donnent donc plus de pouvoir pour plus facilement distinguer HTML, CSS et Javascript. Mais comme le disait Spider-Man (ou Voltaire, au choix) : « De grands pouvoirs impliquent de grandes responsabilités ».

On peut utiliser CSS et la pseudo classe :hover pour gérer l’affichage d’un sous-menu. Mais est-ce vraiment la bonne méthode ? Ne s’agit-il pas plutôt là d’un comportement ? Comme je le disais il y a 2 semaines : « Juste parce que vous pouvez le faire ne signifie par que vous devez le faire« . C’est notre responsabilité d’auteur du web de faire bon usage des nouvelles fonctionnalités du web. A moins que ce ne soit Halloween, la séparation de la structure, présentation et du comportement devrait être de plus en plus nette.

  1. François "cahnory" Germain, le

    Tiens, ça me rappel une réflexion que j’avais eu au début de l’apparition des transitions CSS.
    Je pensais qu’à l’avenir il faudrait éviter les animations javascripts, liées à la présentation au profit de celles en css. Javascript ne servant qu’à faire le changement d’état (modification de classe).

    Un autre truc qui m’a turlupiné lors de la lecture de la traduction, c’est la liaison entre :before/:after et la structure. Oui il s’agit de structure, mais la structure de la présentation, non du document.
    En ce sens, je trouverai très utile un mécanisme permettant de « wrapper » plusieurs éléments ensembles à l’aide de css. Une sorte d’élement virtuel que l’on pourrait styliser. Inutile à la structure du document on ne trouverai pas cet élément dans le html mais il serait « créé » côté css et stylisé. Combien de seraient évités ?
    Ce n’est qu’un exemple mais agir « virtuellement » sur la structure fait parti selon moi de la présentation. Permettre à css d’agir sur celle-ci, permet à la structure d’être plus proche du contenu et justement, moins liée à la présentation.

  2. al.jes, le

    Pas besoin de CSS 3 pour faire le « joli menu » de WDW. Je pouvais déjà le faire en xHTML 1.0 + CSS 2, et je le ferai maintenant en xHTML 1.1 et CSS 3 si seulement elle me plaisait. À mes yeux, les gros apports de CSS 3 sont les améliorations dans les *media queries* et dans la gestion de la typographie.

    Cela dit, HTML 5 effectue un réel retour en arrière quant à la séparation entre présentation et contenu (cf. « i », « small » ou encore « font » — « font » quand même ! *What the hell is in their head!?*). C’est (entre autres) pour ça que j’en reste à xHTML 1.1 (et que je suis très mécontent de l’abandon du xHTML 2.0).

  3. Calvein, le

    @al.jes: Tout d’abord, n’est pas revenu. Ensuite quel est le problème avec et ? Ils ne sont pas là pour dire que le texte est italic ou gras, ce ne sont que des s sans importance (au contraire de et donc), et ce n’est pas comme si il s’agissait de ou . Je ne voit pas l’intérêt de continuer à faire du xHTML quand on peu écrire totalement la même chose en se souvenant par cœur du doctype.

  4. Kaelig, le

    Ce qui compte, c’est que le code vous aide à résoudre des problèmes. Si vous parvenez à tout faire sans aucune peine en séparant totalement les 3 couches (forme, fond, comportement…) alors ne changez rien.

    Pour ma part, voici comment je vois les choses :

    – Fond : HTML (avec Microdata + Aria)
    – Forme : CSS + HTML (OOCSS)
    – Comportement : Javascript + CSS

    Si j’ai recours à ce type de chevauchement des rôles, c’est parce que ça marche pour moi : j’ai besoin d’une CSS qui soit la plus DRY possible et d’un HTML prévisible & facile à remodeler (principes OOCSS).

    Je le répète : il n’y a pas UNE bonne manière de coder. Chacun a ses habitudes, qui répondent à ses besoins quotidiens.