c'est bien là qu'est le problème si on encourage l'utilisateur à y
aller de son propre code html dans ses articles...
On n'encourage pas l'utilisateur à utiliser le HTML, mais on ne peut pas
l'en empêcher. Si un rédacteur veut planter un <h2> au beau milieu de son
texte, rien ne l'en empêche. Alors aussi bien contrôler ça.
Ça permet de faire 2 coups d'une pierre.
Plutôt que de leur enseigner de nouvelles combinaisons et imbrigations de {
et } - qui risque de venir mélanger les affaires plutôt que de les
éclaircir, on leur enseigne que le nouveau raccourci pour les intertitres de
premier niveau dans le texte, c'est <h1>...</h1>, etc... Il y a bien déjà le
merveilleux raccourci SPIP <CADRE> et </CADRE> et quelques autres
pseudo-balises SPIP du même genre. Donc rien de nouveau. Et ô quel hasard
notre raccourci SPIP <h1> est le même que celui du HTML. Bonheur total.
On contrôle ensuite la présentation ou la mise en forme de <h1> par feuille
de style dans le contexte de la division contenant le texte.
Exemple:
#entete h1 { attributs CSS pour le titre du site }
.titre h1 { attributs CSS pour le titre de l'article ou de la rubrique }
#texte h1 { attributs CSS pour les h1 dans le texte }
#texte h2 { attributs CSS pour les h2 dans le texte }
#texte h3 {...}
Et voilà, ainsi, on est blindé de partout et on exerce un contrôle vraiment
supérieur de la mise en forme et sans rien ajouter à SPIP, juste une petite
doc maison à l'intention des rédacteurs et la définition de quelques
sélecteurs dans la feuille de style.
André Vincent