Pas celui de JavaScript, mais l’autre de l’excellente bibliothèque YUI, qui vise le HTML (même s’il n’a pas l’air d’avoir survécu au passage à la version 3).
En une phrase :
HTML rencontre AOP.
Le problème :
- Le graphisme est (encore) sujet à variation, par exemple du fait :
- d’une logique de personnalisation poussée,
- plus simplement parce qu’il n’est pas encore prêt.
- Par contre le contenu est déjà suffisement structuré pour qu’on puisse créer le HTML, et respecter la structure de titrage
Comment s’y prendre :
- Quand vous avez un « bloc » qui se tient bien tout seul, pour l’exemple :
<div id=”contenuPrincipal”>
Lorem ipsum [...]
</div> - Donnez-lui au moins un div avant, une étape après, et un autour. Pour notre exemple :
<div id=”contenuPrincipal”>
<div class=”module-before”></div>
<div class=”module-content”>
Lorem ipsum [...]
</div>
<div class=”module-after”></div>
</div>
(Les noms de classes sont longs pour l’exemple, préférez quelque chose comme « mb », « mc», « ma ») - Profitez des nouveaux points pour votre feuille de style !
#contenuPrincipal {}
#contenuPrincipal .module-before {}
#contenuPrincipal .module-content {}
#contenuPrincipal .module-after {} - « Points bonus » (ou « comment aller trop loin dans bien des cas ») :
- Utiliser la version « inline » : mettez des <span> aux balises de type « bloc », et aux liens. Par exemple :
<p>Lorem ipsum [...]</p>
devient
<p><span>Lorem ipsum [...]</span></p> - Soyez clair sur l’utilisation du pattern :
<div id=”contenuPrincipal”>
devient
<div id=”contenuPrincipal” class=”module”> - Poussez le vice jusqu’à intégrer la notion « d’autour » de l’AOP, par exemple ainsi :
<div id=”contenuPrincipal”>
<div class=”module-around”>
<div class=”module-before”></div>
<div class=”module-content”>
Lorem ipsum [...]
</div>
<div class=”module-after”></div>
</div>
</div>
- Utiliser la version « inline » : mettez des <span> aux balises de type « bloc », et aux liens. Par exemple :
Force « contre » :
- Il est (vraiment !) plus difficile de rentrer dans le code de la page (d’où la nécéssité parfois d’être explicite sur l’utilisation de ce module) si on ne l’a pas créer soi-même
- Le code de la page est plus lourd
Forces « pour » :
- Très grande souplesse introduite en terme de mise en page
- A fait ses preuves
- Accessible
- Permet même de s’affranchir du workflow traditionnel, permettant dans certaines circonstances un meilleur Time-to-Market
À l’avenir :
Avec (surtout) la venue de CSS3 et (quand même moins) d’HTML 5, le besoin de cette souplesse sera probablement moindre (enfin, une fois qu’Internet Explorer 6 ne sera plus un problème).
Qui plus est, on peut probablement s’attendre à des conflits avec la balise <h>, sensible à son contexte (au niveau de profondeur) …
;
)