< Faire du code XHTML valide avec SPIP >
Cette page explique comment faire du code XHTML valide avec SPIP, ce qui n’est pas évident au départ.
SPIP version 1.3.2
Je parle ici de SPIP 1.3.2, qui, par défaut, ne produit pas forcément un code XHTML-valide.
Peut-être que tous ces problèmes seront résolus dans la version 1.4.
Jeter les skelettes par défaut
Les skelettes par défaut sont hélas à jeter si on veut faire du XHTML valide. Je vous propose éventuellement de jeter un oeil sur mes skelettes : 
skelette de ma page d’accueil - valide ! skelette de ma page article skelette de ma page rubrique skelette de mon plan de site skelette de ma page de recherche
Libre à vous de vous en inspirer. L’intérêt de ces skelettes est d’être plus près de la validation XHTML que les skelettes originaux de SPIP. [1] Cependant, ces skelettes ne sont pas parfaits, et ne valident pas tous niveau XHTML.
On va en baver
SPIP est un outil formidablement simple pour mettre un site à jour. N’importe quel béotien peut, grace à SPIP, maintenir un site web vraiment évolué, bravo SPIP ! ! !
Par contre, lorsqu’il s’agit de créer son propre skelette, il est très difficile de se passer de bonnes notions d’(X)HTML et de CSS. On est bien d’accord sur ce point : on va en baver ;-)
Dans les prochains paragraphes : les astuces et modifications que j’ai du effectuer dans mes skelettes pour diminuer mon nombre d’erreurs via HTML-validator.
Ne pas utiliser #LOGO
Problème sur le code généré par SPIP par les balises #LOGO :
[(#LOGO_ARTICLE_RUBRIQUE|right|#URL_RUBRIQUE)]
produit le code suivant :
<a HREF='rubrique8.html'><img SRC='IMG/rubon8.png' ALIGN='right' NAME='image2' width='60' height='60' BORDER='0' ALT='[logo]' HSPACE=3 VSPACE=3 class='spip_logos'></a>
Ca génère une cascade d’insultes de la part du validateur du W3C, vu qu’en XHTML, les noms des attributs doivent être en minuscules et toutes les valeurs des attributs doivent être entre (doubles)quotes.
Pour corriger ces erreurs, on peut peut : modifier le code de SPIP pour en corriger le comportement (oh, merveille de l’open-source, toi qui nous permets de modifier à notre guise les logiciels qui nous sont gracieusement offerts). Mais alors on s’écarte du code de tout le monde, et on risque de générer des bugs si on commence à modifier le code spipien. adapter notre code dans les skelettes.
Si l’on choisit la deuxième solution, on devrait donc pouvoir écrire :
<a href="#URL_RUBRIQUE" title="aller à la rubrique <BOUCLE_nomrub(RUBRIQUES){id_rubrique}>#TITRE</BOUCLE_nomrub>">[<img src='/IMG/(#LOGO_ARTICLE_RUBRIQUE|fichier)' align='right' width='60' height='60' border='0' alt='logo' hspace='3' vspace='3' class='spip_logos'>]</a>
J’ai rajouté une boucle de type RUBRIQUES pour obtenir le nom de la rubrique correspondant au logo, et le mettre comme title dans mon lien.
SPIP version 1.5.1
Cet article devient un peu vieux maintenant. SPIP en est à la version 1.5.1 et ... ne produits toujours pas de code XHTML valide ;-). Mais les progrès sont ENNORMES. Le principal vient des skelettes : ceux livrés avec la version 1.5.1 de SPIP sont infiniement plus standards que les précédents, tout simplement parce qu’ils font un usage intensif des feuilles de style et des DIV pour la mise en page, plutot qu’avoir recours à la mauvaise vieille ruse des TABLE.
Donc, si vous êtes soucieux de la validité de vos pages, installez sans attendre la v 1.5.1.
[1] Notamment, ces skelette n’utilisent pas les TABLE pour faire de la mise en page. Les TABLE sont un outil pour marquer des données tabulées, telles de véritables tableaux de données, ou des calendriers, etc ... mais les TABLE ne doivent pas être utilisés à des fins de mise en page. Les CSS sont là pour ça.
11 commentaires
T’inquiète pas, la proposition a été faite à maintes reprises. Le problème de la non-validité du cote xhtml produit par spip est un des thèmes les plus réccurents de la liste spip-dev. Le problème est que, même si tout le monde est d’accord sur le bien fondé de la motivation, personne n’a encore pondu le code qui permette dans tous les cas de figure (et ils sont nombreux) de générer du code xhtml valide.
:-(
hello, nouveau sur spip 1.5.1, je me suis décidé à tester les normes du w3c sur le site que je compte faire... pour ne pas bruler les étapes, je commence humblement à suivre le pas à pas proposé sur le site uzine en lançant dreamweaver. je crée le fichier php3 puis le squelette xhtml, je lance easyphp pour tester le tout en local et j’ai ce beau message d’erreur : Parse error : parse error, unexpected T_STRING in c :\program files\easyphp\www\etc... on line 1. quel est le fichier php qui doit être modifié pour ne plus avoir ce message d’erreur ? merci !
Aucun t’as une erreur de syntaxe dans le code php de ta page c’est tout.
Et bien, j’ai trouvé d’ou vient l’erreur, c’est à cause du DTD xhtml... je l’ai remplacé par un DTD html transitionnal 4.01 et hop, plus d’erreur. Si SPIP bug dès la première ligne, le chemin promet d’être long !
qui est en cause c’est la première ligne du DTD sous easyphp, j’ai pas testé en distant mais à apparemment le fait de déclarer du xml easyphp n’aime pas
en fait c’est la ligne xml qui commence par < ?, il interpréte ca cà comme du PHP et ne comprend pas
j’ai résolu ce problème (parmis de nombreux autres) en écrivant ceci dans la première ligne :
< ?php echo "< ?xml version=\"1.0\" encoding=\"UTF-8\" ?> \n" ?>
ce qui génère :
< ?xml version="1.0" encoding="UTF-8" ?>
Mais il me reste d’autre pb comme ce message délivré par ie lorsque j’utilise SPIP et la dtd xhtml 1.1 (alors que avec la source récupérée depuis mozilla, ca passe sans problème sous ie) :
La page XML ne peut pas être affichée Impossible d’afficher l’entrée XML en utilisant la feuille de style . Corrigez l’erreur, puis cliquez sur le bouton Actualiser ou réessayez ultérieurement.
L’entité de paramètre doit être définie avant son utilisation. Erreur de traitement de la ressource http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd. Ligne 85, Position 2
%xhtml-prefw-redecl.mod ; ^
salut, en fait php est configuré pour executer tout ce qui est entre < ? ?> et < ?php ?> alors soit dans la config de php tu mets le short tag à off soit tu genere l’entete xhtml en php < ?php echo ’< ?xml version="1.0"...’ ; ?>
Salut, et bravo pour laperf. Seulement...
Seulement je toruve abérrant de devoir rajouter des boucles (et autant de requetes SQL) pour régler un problème pourtant hyper simple à régler. Car quoi qu’on en dise, générer une sortie compatible XHTML n’est pas sorcier (ex. Dotclear-, autre CMS, le fait très bien).
Que font-ils, les devs de SPIP, ils dorment ? Fermer les balises et mettre les tags en minuscules, c’est vraiment dur à ce point ?
Secouons-les avant que d’autres ne le fassent :(
Salut,
Pour afficher < ?xml version="1.0" encoding="ISO-8859-1" ?> çà.
J’ai utilisé ce code avec PHP < ?php echo ’< ?xml version=\"1.0\" encoding=\"ISO-8859-1\" ?> < ?php echo "\n" ; ?>
Spip 1.8.2 ( enfin cvs la 1.8.2 ne devrait pas tarder ) est dorenavant capable de produire du code XHTML/CSS valide 1.0 Strict.
Comme exemple CahierSpip .
Il est possible qu’il reste quelques détails que je n’ai pas vu mais . . .
Tu écris : Pour corriger ces erreurs, on peut peut : modifier le code de SPIP pour en corriger le comportement (oh, merveille de l’open-source, toi qui nous permets de modifier à notre guise les logiciels qui nous sont gracieusement offerts). Mais alors on s’écarte du code de tout le monde, et on risque de générer des bugs si on commence à modifier le code spipien.
J’aurais envie de répondre : proposer aux devs de spip les modifs qui rendront leur code un peu plus valide...