Alors que les debats houleux au sujet des Cascading Style Sheets et de la chasse aux tables sorcieres (52 references sur Google pour "tables are evil"), se poursuivent sur les jouebs francophones et maintenant anglophones, j'aimerais vous proposer ma solution pour se debarasser de ces encombrantes balises <table>, <tr> et <td> qui - il est vrai - ne devraient rien avoir a faire au milieu du contenu. Rassurez vous, c'est une idee tres simple. Mais elle n'en reste pas moins redoutablement efficace, et elle ne souffre d'aucun des problemes qui rendent l'adoption des CSS si laborieuse et incertaine.

Introduction

Les ardents defenseurs des CSS ont raison, les tables sont diaboliques. Pas par nature - les tables sont relativement innoffensives - mais parce qu'elles ont cette facheuse tendance a se retrouver au milieu du contenu (la structure ou la semantique, appelez ca comme vous voulez). Si vous creez une page web avec une recette de gateau au chocolat et une recette de creme anglaise, chacune soigneusement encadree, vous vous retrouverez avec ces fameuses balises <table>, <tr> et <td> entre les deux. Pas moyen de mettre de la creme anglaise sur son gateau au chocolat sans se prendre les pieds dans une table.

Les promoteurs des CSS s'ecrieront surement "C'est de la faute de ces satanes tables ! Il faut les enlever !". Au premier abord, cela peut paraitre etre une solution, mais du coup, on se retrouve a manger par terre, et c'est tres peu pratique. Certaines personnes semblent y arriver avec plus ou moins de succes apres un entrainement parfois tres intensif, mais ce n'est pas mon cas et bien d'autres en ont eu plein les fesses avant moi.

Ma solution consiste a rassembler toutes les tables au meme endroit, et ensuite a poser le gateau au chocolat et la creme anglaise dessus. Voila comment ca marche :

Presentation et syntaxe des macros

La majorite des sites web organisent leurs pages en placant des boites un peu partout. Souvent c'est un simple cadre, avec ou sans bordure, de temps en temps les boites a coins ronds sont a la mode, et parfois, c'est meme du delire.

Les cadres simples ne demandent qu'une poignee de balises <table>, <tr> et <td>, mais pour faire des coins ronds ou en forme de petits beurres, on arrive tres vite a des tables dans des tables, a des images d'un pixel par un pixel et autres plaisirs de la table. Et si l'on desire placer plusieurs boites sur sa page, la maitrise du copier/coller devient vite indispensable.

Les programmeurs n'aiment pas le copier/coller, parce que s'il faut ensuite modifier quelque chose (les coins petits beurres finissent par lasser), il faut modifier la meme chose a de multiples endroits differents. C'est long, c'est fastidieux, et c'est quelque chose qui pourrait etre tres bien fait par un ordinateur.

Quand un programmeur voit des bouts de code qui se ressemblent, il essaie de creer une fonction avec une seule fois le bout de code, qu'il pourra ensuite appeler aussi souvent qu'il le souhaite. Il existe une version simplifiee des fonctions : les macros. Les macros sont equivalents a la fonction "Rechercher/Remplacer" de votre editeur de texte prefere, en plus flexible : on peut leur passer des parametres.

Par exemple, on pourrait definir une macro "boit_du_whisky" comme cela : "[nom] boit du whisky !". [nom] est un parametre de la macro. Ensuite, lorsque l'on veut dire que quelqu'un boit du whisky, il suffit d'appeler la macro en lui donnant la valeur du parametre nom : boit_du_whisky(Stephane) aura comme resultat : "Stephane boit du whisky !".

Avec des macros, on peut tres facilement se debarasser des balises <table>, <tr> et <td> en les placant dans des macros.

Par exemple, on peut definir une macro "boite", avec un argument "contenu" :

<define_macro name="boite">
<table border="1" bgcolor="blue">
<tr>
<td>
<font color="orange">
<arg name="contenu">
</font>
</td>
</tr>
</table>
</define_macro>

On peut ensuite l'appeler autant de fois qu'on le souhaite :

<macro name="boite">
<arg name="contenu">Je suis une boite bleue.</arg>
</macro>

<macro name="boite">
<arg name="contenu">Je suis une autre boite bleue.</arg>
</macro>

Rien n'empeche egalement d'utiliser une macro precedemment definie dans la declaration d'une macro :

<define_macro name="boite_avec_titre">
<macro name="boite">
<arg name="contenu">
  <h3><arg name="titre"></h3>
  <arg name="contenu">
</arg>
</macro>
</define_macro>

Ou meme d'utiliser le resultat d'une macro comme argument d'une autre :

<macro name="boite_avec_titre">
<arg name="titre">Cette boite contient une autre boite !</arg>
<arg name="contenu">
  <macro name="boite">
  <arg name="contenu">Je suis encore une boite bleue.</arg>
  </macro>
</arg>
</macro>

Avantages compares

Separation de la structure et de la presentation

Les macros reussissent aussi bien, et meme mieux, que les CSS a separer structure et presentation. Il en est effet tres aise de declarer des macros pour la presentation et de les instancier avec la structure semantique d'une page web. Par exemple, pour un joueb, apres avoir declare les macros, on peut tout simplement lister des instances comme celles ci :

<macro name="article">
  <arg name="titre">Les macros : une alternative simple
    aux CSS pour separer structure et presentation</arg>
  <arg name="auteur">Stephane Gigandet</arg>
  <arg name="date">02/16/02</arg>
  <arg name="categorie">Nouvelles</arg>
  <arg name="texte">...</arg>
   ...
</macro>

<macro name="article">
  ...
</macro>

Cet ensemble d'attributs peut ainsi aisement etre lu et traite par des machines. La forme de paire nom/valeur offre d'autres avantages par rapport aux CSS : il est possible de presenter les informations dans n'importe quel ordre, ce qui est quasi-impossible avec des CSS (les elements sont presentes les uns a la suite des autres, dans l'ordre dans lequel ils apparaissent dans le code de la page web ; il est possible d'extraire des elements du flux, mais la complexite devient vite inhumaine). Il est egalement possible de choisir de ne pas presenter certaines informations.

Il suffit ensuite de changer simplement une macro pour changer la presentation de tous les elements de la page.

Pas de barrieres a l'adoption

Depuis six ans, les CSS en tant qu'outil de separation de la structure et de la presentation ne reussissent pas a se faire adopter par une proportion consequente des auteurs de sites web. C'est la consequence logique de nombreuses barrieres a l'adoption dont elles sont affligees. Les macros en sont cependant exemptees, et pourraient donc, pourquoi pas, etre adoptees plus facilement.

1. Les macros sont simples.

Vous savez deja tout des macros. Vraiment. Je vous ai deja dit tout ce que je savais. Ce n'etait pas tres long, ni tres penible, ni dur a comprendre (si vous n'avez pas compris, c'est sans doute que j'ai mal explique).

1.1. Les macros sont simples, donc la courbe d'apprentissage est bien moindre que celle des CSS.

1.2. Les macros sont simples, donc elles sont faciles a implementer.

Pas de risque de se retrouver avec 3 ou 4 implementation incompletes et incompatibles (pas de IE5/WIN kludge ou de "be nice to opera" rule. Cela m'a pris a peu pres une heure cette apres-midi pour implementer les macros sur Niutopia.

Si vraiment vous ne voyez pas comment faire, voici le source (open source - libre, licence MIT).

2. Les macros permettent de faire tout ce qui est possible de faire avec l'HTML, les CSS etc.

Les macros peuvent generer n'importe quel source HTML avec ou sans CSS. Elles peuvent egalement etre utilisees pour generer du WML ou n'importe quel autre format textuel.

Il est donc tres facile de partir d'une page web existante et de la transformer pour qu'elle utilise les macros. Et le resultat final sera identique a l'original ! Vous pourrez ainsi vous epargner les frustrations et echecs associees au remplacement des tables par le positionnement avec les CSS.

3. Les macros n'ont pas le probleme de l'oeuf et de la poule.

Une des raisons les plus souvent citees par les auteurs de sites web pour justifier leur non-adoption des CSS est le mauvais support par les navigateurs actuels. Les implementations des CSS sont incompletes et incompatibles entre elles. D'un autre cote, les editeurs de navigateurs ne sont pas presses pour ajouter ce support, puisque de toutes facons les sites qui utilisent le positionnement par CSS constituent une infime partie du web. On se retrouve avec le fameux probleme de l'oeuf et de la poule : pas moyen d'avoir un oeuf sans poule, et pas moyen d'avoir une poule sans oeuf.

Les macros quand a elles n'ont pas ce probleme pour deux raisons :

3.1. Les macros sont compatibles avec l'existant.

Vous pouvez utiliser les macros aujourd'hui, tout de suite, sans attendre un eventuel support par les navigateurs. Comme les macros generent de l'HTML, il suffit d'instancier les macros juste avant d'envoyer une reponse au navigateur. Pour cela, il faut que les pages soient generees dynamiquement, mais c'est deja le cas pour beaucoup de sites. Si vous programmez votre site vous meme et que vos pages sont dynamiques, vous pouvez donc facilement implementer les macros. Si vous ne programmez pas, vous pouvez utiliser un systeme qui utilise les macros (comme Niutopia des a present), ou demander aux auteurs de votre systeme d'ajouter ce support.

3.2. Les macros apportent une recompense immediate.

Les macros sont utiles des aujourd'hui. Il n'est pas necessaire d'attendre qu'une masse critique d'utilisateurs se forme pour en obtenir les fruits. Meme si Niutopia reste le seul systeme a implementer les macros, les avantages qu'elles apportent aux utilisateurs sont largement suffisants pour justifier a mes yeux leur implementation.

4. Les macros peuvent avancer pas a pas.

Les CSS sont de la haute technologie. Pour les faire avancer, il faudrait reussir a synthetiser une poule ou un oeuf a partir de rien. Pas si simple.

Les macros sont comme un immeuble : on peut construire facilement la base et construire les etages superieurs les uns apres les autres. Des le debut, on peut habiter les etages inferieurs, tout en sachant qu'au fur et a mesure que chaque etage se construit, la vue devient de plus en plus saisissante.

Voici comment on pourrait developper les macros :

4.1. Support dans les systemes qui generent des pages dynamiques

Les systemes dynamiques peuvent utiliser des themes/skins/templates pour generer du code contenant des macros, avec separation de la structure et de la presentation. Juste avant d'envoyer la page au navigateur, le systeme transforme les macros en code normal.

Cependant, ces systemes sont capables d'envoyer les pages avec les macros non-transformees aux navigateurs ou outils qui le souhaitent. Pour cela, on utilise le header Accept-Encoding du protocole HTTP.

Essayez la requete suivante a la main :

telnet joueb.com 80 GET http://joueb.com/api/ HTTP/1.1 Host: joueb.com Accept-Encoding: macros

et vous recevrez la page avec les macros non-transformees.

Je suis pret a aider tous ceux qui le souhaitent a implementer les macros dans leur systeme. D'autre part, il suffirait d'une bonne implementation en PHP pour rendre le support des macros possibles dans de nombreux systemes open-source : daCode, PostNuke, b2 et bien d'autres.

4.2. Support dans les outils d'aggregation, moteurs de recherche etc.

Grace au header "Accept-Encoding: macros", les outils d'aggregation, les moteurs de recherche (comme Daypop, Blogdex etc.) peuvent acceder directement a la structure semantique des pages web et offrir ainsi de nouveaux services.

4.3. Support natif dans les navigateurs

Si Mozilla (open-source : meme raisonnement que les systemes dynamiques, on peut le faire nous meme) et donc Netscape supportent les macros, MSIE ne devrait pas tarder.

4.4. Utilisation par les proxys

Meme raisonnement, on pourrait transformer Squid pour qu'il envoit une requete avec "Accept-Encoding: macros" aux serveurs web meme si le client ne le supporte pas. Squid se chargerait alors de la transformation avant (ou plutot en meme temps) d'envoyer la reponse au client. Et eventuellement pour qu'il essaie de generer des macros automatiquement si le serveur web ne le supporte pas, mais c'est deja beaucoup moins evident.

4.5. C'est fini.

Mais on ne s'en apercoit meme pas : pas d'abandon des anciennes pages, pas d'abandon des anciens navigateurs. Meme si 95% des utilisateurs ont des navigateurs qui supportent les macros et si 95% des sites web utilisent les macros, les 5% restant continuent a fonctionner comme si de rien n'etait.

Commentaires ?

Il est tard, les macros ont un jour. J'ai surement oublie de penser a plein de choses. J'ai surement ete injuste par moment avec les CSS. J'ai surement ete beaucoup trop megalo dans ce paragraphe 4. Vous avez surement des tas de choses a dire. Allez y.

Tim Toady