Changez-vous la vie avec XHTML
Le XHTML est un langage de balisage standard pour les documents web, et le successeur du HTML 4. Mélange de classique (HTML) et d'avant-garde (XML), ce langage hybride ressemble au HTML et fonctionne de la même manière, tout en étant basé sur XML, le "super" langage de balisage du web. Il apporte donc aux pages web de nombreux avantages du XML, comme ceux énumérés dans le Guide de Style en Ligne des Filiales de la Bibliothèque Publique de New York.
Si vous voulez que votre site fonctionne correctement dans les navigateurs et les outils non-traditionnels d'aujourd'hui, et qu'il continue à bien fonctionner dans ceux de demain, ça ne serait peut-être pas une mauvaise idée de créer vos nouveaux sites en XHTML, et de convertir les anciens quand votre planning vous le permet.
Et comme de plus le W3C vous facilite la tâche, vous pouvez apprendre les règles du XHTML en moins de temps qu'il n'en faut à Pizza Hut pour livrer une 4 saisons. Ces quelques règles simples illustrent l'aspect pratique des règles du W3C, car elles apportent une cohérence et une syntaxe XML correcte au web sans obliger designers et développeurs surchargés à apprendre entièrement de nouvelles méthodes de balisage.
Toutefois comme pour toute transition, vous obtiendrez les meilleurs résultats et les plus prévisibles avec un peu de préparation. Cet article va vous y aider, en examinant les outils qui peuvent vous aider à convertir vos pages en XHTML et à vérifier que vous l'avez fait correctement. Il traitera aussi des différences dans la manière dont certains navigateurs affichent les pages XHTML, différences qui pourraient vous étonner si vous ne vous y attendez pas, ainsi que des méthodes utilisées pour les contourner si besoin.
Un homme averti en vaut deux
Si vous ne l'avez pas déjà fait, lisez le Guide de Style en Ligne des Filiales de la Bibliothèque Publique de New York avant de continuer cet article.
Ce Guide de Style fait la lumière sur le XHTML sans vous obliger à fouiller dans la littérature souvent hermétique du W3C. Il inclut des informations utiles sur les CSS (y compris des feuilles de style que vous pouvez récupérer et utiliser sur vos propres sites). Il explique comment travailler avec les validateurs du W3C, et offre des astuces pour les utilisateurs de Dreamweaver.
L'auteur de ces lignes a aidé la Bibliothèque Publique de New York à créer le guide, et il est reconnaissant à la Bibliothèque et à son coordinateur web (et co-créateur du Guide de Style) Carrie Bickner d'avoir choisi de mettre ce guide à la disposition de la communauté. Le Guide de Style est fréquemment mis à jour pour corriger des erreurs et fournir de nouvelles informations.
Tidy
La méthode la plus facile pour créer des pages XHTML valides est encore de les coder en partant de zéro. Mais l'essentiel du design web est en fait du redesign web, et vous aurez souvent à mettre à jour d'anciennes pages. Ce qui constitue la meilleure opportunité pour migrer vers le XHTML.
HTML Tidy est un outil gratuit qui peut convertir votre HTML en XHTML. Nous l'avons récemment utilisé à cet effet sur le Daily Report de zeldman.com. Nous avons également utilisé Tidy pour la conversion du site A List Apart en CSS/XHTML l'année dernière, et nous l'avons employé avec succès sur plusieurs sites de nos clients.
Tidy, créé par le brillant Dave Ragett, est aujourd'hui maintenu en Open-Source par la communauté web sur le site Source Forge, même si certaines versions sont maintenues par les initiatives individuelles de véritables amoureux de ce logiciel.
Pour notre conversion, nous avons utilisé MacTidy 1.0b13, la version de Tidy la plus récente pour Mac OS, développée par Terry Teague (le site de Terry pourrait être temporairement inaccessible quand vous suivrez ce lien, son hébergeur lui permettant de transférer seulement une quantité de données limitée toutes les heures. Si vous rencontrez des problèmes, réessayez plus tard.)
Il existe des versions en ligne de Tidy, comme des versions téléchargeables pour Windows, UNIX, différentes distributions de LINUX, Mac OS, et différentes plateformes, chacune d'entre elles possèdant des capacités différentes et donc sa propre documentation.
Lisez le manuel
Comme beaucoup de personnes occupées, nous avons tendance à éviter de lire les manuels, mais dans le cas de Tidy nous vous conjurons d'en lire le moindre mot. Même si certaines versions de Tidy semblent rudimentaires et que ses capacités semblent évidentes, Tidy est un outil puissant. Vous devez donc vous familiariser avec ses préférences et ses réglages pour vous assurer du résultat désiré.
Pour notre conversion du Daily Report, nous nous sommes rafraîchi la mémoire avec un bref coup d'oeil à la documentation de MacTidy, et cela s'est avéré être une erreur.
Au premier passage, en utilisant des paramètres que nous n'avions jamais testés auparavant, Tidy a converti nos entités de caractères encodées en caractères non-encodés et spécifiques à la plateforme. Il a tranformé des entités Unicode fonctionnant dans tous les navigateurs en entités nommées qui devraient fonctionner dans tous les navigateurs mais ne le font pas. Enfin il a changé les <
des commentaires <!--
en caractères encodés, déclenchant ainsi des erreurs dans une fonction JavaScript.
Le pouvoir était celui de Tidy, la faute était la nôtre. Une utilisation incorrecte de Photoshop, d'Illustrator ou de Flash peut avoir les même conséquences, et Tidy ne pouvait être rendu responsable des erreurs de ses utilisateurs. Alors rendez-vous trois services :
- lisez le manuel ;
- gardez une copie de sauvegarde de votre document ;
- lisez le manuel.
Ceux qui partagent notre problème de rapport au manuel voudront savoir quel était le réglage de préférence correct. Malheureusement, il n'y a pas de réglage "correct". Le réglage varie suivant le type d'encodage de caractères que vous désirez spécifier dans votre header, le type d'encodage que vous avez spécifé dans votre éditeur HTML (habituellement latin1
), et d'autres variables. Cependant, si vous voulez générer du XHTML, suivez ce conseil et assurez-vous de choisir la préférence Convert HTML to XML (car rappelez-vous que le XHTML n'est en réalité que du XML).
Se préparer à valider
Le Guide de Style explique comment travailler avec les validateurs (X)HTML et CSS du W3C. La validation prend juste quelques instants. Si vous évitez cette étape et si votre XHTML ou vos CSS contiennent des erreurs, votre site pourrait ne pas fonctionner correctement. Il pourrait aussi s'afficher fort différemment de ce que vous souhaitiez.
Avec un balisage et des CSS valides, les navigateurs conformes aux standards afficheront votre site de la manière attendue, avec des exceptions que nous traiterons plus bas. Avec du XHTML ou des CSS invalides, on rentre dans le domaine de l'imprévisible, et vous ne pourrez en blâmer les navigateurs (bon allez, vous pouvez, mais c'est injuste et ça ne vous avancera à rien).
Si vous écrivez votre code à la main, à moins d'être parfait, il y a des chances pour que vous fassiez des erreurs de temps en temps. Si vous utilisez Macromedia Dreamweaver ou Adobe GoLive avec leurs réglages par défaut, votre site contient sûrement des erreurs que les validateurs peuvent vous aider à corriger.
Nous avons pleine confiance dans le fait que les versions à venir de Dreamweaver ou de GoLive vous aideront à créer du code plus valide, mais ces versions ne sont pas encore sur le marché, et même lorsqu'elles le seront, vous pourrez encore avoir besoin de bricoler votre code à la main (en attendant, les utilisateurs de Dreamweaver devraient consulter les astuces du Guide de Style, mises à jour le 15 février 2002 pour coincider avec le présent article).
Quelle que soit la manière dont vous générez votre code, travailler avec les validateurs s'avère payant. Ils sont comme des consultants XHTML et CSS neutres qui vous montreront vos problèmes sans penser aucun mal de vous.
Problèmes de navigateurs
Même les meilleurs consultants donnent parfois de mauvais conseils. Ils peuvent manger trop d'ail à midi, ou utiliser votre fax plus que vous ne le souhaiteriez. Les consultants robotiques que l'on trouve aux adresses validator.w3.org et jigsaw.w3.org/css-validator peuvent également vous créer des problèmes inattendus.
Principalement, cela est dû au langage que les validateurs utilisent pour rapporter les erreurs. Ecrits par et pour des techniciens des standards, les validateurs offrent parfois une "aide" qui peut confondre ou égarer les utilisateurs moyens. Bien sûr ce n'est pas le travail du W3C de nous pré-mâcher les standards web, mais nous aimerions parfois que les navigateurs nous indiquent, "Hé, idiot, tu as oublié de fermer ta balise <p>
" au lieu des commentaires cryptiques qu'ils nous sortent occasionnellement.
Pourquoi ce cryptage, camarade ?
Pour être honnête, les messages cryptiques des validateurs découlent souvent des limitations du logiciel. Le validateur n'est pas HAL dans 2001 l'Odyssée de l'Espace. Si vous oubliez de fermer une balise, le validateur ne peut pas savoir que vous aviez l'intention de la fermer, et peut alors indiquer une erreur plus bas dans la page, au lieu de désigner le problème réel. Le validateur peut pointer vers une balise mal imbriquée qui est, en fait, bien imbriquée -- alors qu'une balise précédente ne l'est pas, ce qui suffit à hébéter le validateur.
En tant que créateur, vous êtes responsable de vos propres erreurs, qu'elles soient générées par un outil (peut-être mal utilisé) ou tapées à la main. Savoir que les validateurs XHTML ont tendance à signaler les erreurs d'imbrication en dessous de l'endroit où elles ont en fait eu lieu peut vous aider à déjouer les pièges des rapports d'erreur et à vous remettre en selle rapidement.
Autres problèmes courants
Beaucoup d'éditeurs HTML courants génèrent des DOCTYPEs avec des URI relatives, du genre...
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/XHTML1-strict.dtd">
Ces URIs génèrent invariablement des erreurs de validation CSS quasiment impossibles à déchiffrer par un simple mortel. Nous nous sommes tapés la tête contre les murs jusqu'au sang à cause de messages du genre de celui-ci :
org.xml.sax.SAXException: Please, fix your system identifier (URI) in the DOCTYPE
La méconnue FAQ du validateur CSS traduit ces balbutiements de savant fou dans un anglais courant, et explique comment corriger les problèmes. Dans l'exemple donné ci-dessus, la solution est d'utiliser un DOCTYPE avec une adresse absolue, comme :
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/XHTML1/DTD/XHTML1-transitional.dtd">
Nous partagerons des astuces importantes sur les DOCTYPEs plus tard dans cet article.
Un autre problème courant qui ne dérange pas les validateurs -- mais répand le chaos dans les vieux navigateurs et même dans certains des plus récents comme IE 6 -- concerne le prologue XML optionnel qui précède le DOCTYPE et les déclarations d'espaces de noms. Encore une fois, veuillez vous rapporter au guide XHMTL du NYPL Style Guide pour plus de détails, ainsi que pour la solution.
D'autres problèmes de validation courants (et leurs solutions) sont couverts dans l'article d'Eric Meyer Liberté ! Égalité ! Validité ! paru sur Netscape DevEdge.
Bugs de validateurs
Les validateurs sont également des produits de fabrication humaine, et donc, comme tout logiciel, ils contiennent quelques bugs. Vous devriez signaler ces bugs lorsque vous les rencontrerez (nous vous dirons comment plus loin), mais vous pourriez hésiter à le faire, plus porté à mettre en doute votre propre balisage qu'un puissant ordinateur programmé par des experts des standards. Sachez pourtant, qu'exceptionnellement, il arrive de constater que le validateur comporte aussi des bugs.
Lors de notre précédente rencontre avec Tidy, en utilisant des mauvais réglages, nous avons obtenu une page web qui n'était pas tout à fait correcte, que nous avons décidé de corriger à la main, sans réaliser, que nous avions laissé passé une erreur.
Obéissant à notre réglage approximatif, Tidy a converti nos symboles copyright encodés ©
en symboles copyright du clavier Macintosh. Ce caractère clavier ne pose pas de problème pour un transfert de fichiers de Macintosh à Macintosh, mais il est à déconseiller sur le web. Nous avons passé la page dans le validateur du W3C et elle s'en est sortie haut la main.
Nous avons ensuite essayé de valider notre feuille de style, mais le validateur CSS du W3C nous a informé qu'il ne pouvait pas le faire à cause d'une erreur dans notre XHTML : “An invalid XML character (Unicode: 0xa9) was found in the element content of the document.”
Situation inextricable
Malheureusement, nous ne pouvions rechercher et remplacer "0xa9" puisque 0xa9 n'est pas une chaîne de charactères existant dans notre document (0xa9 correspond au symbole copyright en Unicode, mais à moins d'avoir la table de ces caractères en tête, le message du validateur ne sert pas à grand chose).
Le validateur CSS nous a fourni les références de ligne et de colonne pour chaque erreur, et celles-ci auraient pu nous être utiles pour repérer le problème si elles se rapportaient à quelque chose. Mais les références restaient muettes puisque le validateur CSS n'affiche pas le balisage.
Le validateur du W3C affiche quant à lui le code complet avec les références de lignes, mais seulement s'il le croit défectueux. Et comme nous l'avons dit, ce validateur considérait notre balisage comme étant tout ce qu'il y a de plus kasher.
Nous nous sommes alors retrouvés dans une situation inextricable avec un validateur qui disait que notre page était correcte tandis que l'autre plantait et nous fournissait des messages d'erreurs inutilisables.
Momentanément déconcertés, nous avons malgré tout mis cette page en ligne, et dans l'heure, les lecteurs du Daily Report, avec entre autres Mark Howells, Zeke Runyon, et Dylan Foley, avaient pris sur eux-même de relire notre code source et de trouver l'erreur. Nous les en avons remerciés, nous avons corrigé notre erreur, et nous sommes repartis de plus belle.
Si nous avions travaillé sur le projet d'un client au lieu d'un site personnel, nous n'aurions pas mis la page en ligne avant d'avoir trouvé et corrigé l'erreur. Dans la plupart des cas, il est bon de fermer votre éditeur HTML, d'aller faire un tour, et de revenir plus tard, avec l'esprit plus clair.
Signaler les bugs de validateurs
De tels problèmes sont assez rares (et dans notre cas, ils auraient pu être évités par la lecture du manuel), mais ils surgissent parfois. Un de nos amis, qui a été appelé "le plus grand web designer vivant" tape pourtant fréquemment des caractères clavier Windows dans son code source. Aussi sachez que les erreurs de balisage peuvent se produire et que les erreurs de validation arrivent elles aussi (assez rarement toutefois).
Si vous pensez que le validateur du W3C est dans l'erreur, visitez la page des feedbacks utilisateurs. Pour rapporter les erreurs possibles du validateur CSS, écrivez à www-validator-css@w3.org (l'adresse email présente sur la page ReadMe du validateur CSS ne fontionne pas car elle est incomplète). Si le validateur est effectivement fautif -- ou si vous avez de fortes présomptions sur le sujet -- soyez sympas et signalez l'erreur.
Les validateurs du W3C sont des ressources gratuites maintenues avec amour par des gens compétents. Se montrer rude dans votre correspondance, même si ça vous tente, soit offensera ces travailleurs acharnés, soit (plus vraisemblablement) leur fera se demander pourquoi vous êtes si frustres et les aménera à transférer immédiatement votre message dans leur corbeille.
XHTML et les navigateurs
Alors vous avez maintenant une page XHTML valide. A-t-elle toujours la même apparence ? Dans quelques navigateurs récents et conformes aux standards, il est possible que non -- mais vous pouvez corriger cela rapidement.
Après avoir converti le Daily Report de HTML 4.01 Transitional à XHTML 1.0 Transitional, notre page était en tout point identique à la page originale, sauf pour le changement de DOCTYPE et des règles de balisage.
Mais IE6 et Mozilla/Netscape 6 ont décidé que la page devait avoir l'air différente. Voici ce que IE6/windows a fait à notre barre de menu :
Et voici les sentiments de Netscape 6.2/Mac sur le sujet :
Boucher les trous
Pour corriger ces "bugs" (à notre avis) sous MSIE6 et Mozilla/Netscape 6, nous avons ajouté deux règles dans une feuille de styles incluse dans le header de la page :
.img {display: block;}
.inline {display: inline;}
La première règle a "réparé" la barre de menu, la seconde a corrigé les problèmes d'affichage causés par la première règle. Là où nous voulions que les images s'affichent inline (NdT : display:inline
affiche les éléments sur la même ligne, display:block
affiche chaque élément comme un bloc), nous avons ajouté une class="inline"
à la balise img
. Problème résolu.
Si le balisage (la structure) et l'affichage (le design) sont deux animaux différents dans les esprits du W3C, pourquoi ces navigateurs changent-ils notre affichage, et comment en sommes-nous arrivés à corriger ce problème avec deux déclarations CSS ?
Interprétation stricte et bizarreries aléatoires
Comme noté dans le Daily Report (26 janvier 2002), les experts ne sont pas d'accord sur la manière dont un standard comme les CSS devrait être interprété. En particulier, ils ne sont pas d'accord sur les styles qui devraient s'appliquer par défaut aux images n'ayant pas été stylées par le designer.
L'article Tables, Images, and Mysterious Gaps d'Eric Meyer, explique comment les experts CSS du projet Mozilla interprètent les balises images non stylées, en relation avec la grille sous-jacente de chaque page, et fournit des astuces pour ceux qui ne veulent pas d'espaces supplémentaires dans leurs pages web. Ce problème touche surtout les mises en page "combinées", qui utilisent un mélange d'ancien (tableaux) et de nouveau (CSS).
Strict vs. Strict
L'article d'Eric Meyer stipule que Mozilla et son héritier Netscape 6 n'ajoutent des espaces qu'aux documents (X)HTML ayant un DOCTYPE strict, mais cela peut porter à confusion, car il semble suggérer que les espaces supplémentaires apparaissent seulement sur les images d'une page HTML Strict ou XHTML Strict. Un coup d'oeil à plusieurs mailing-lists sur le web design vous montrera que c'est l'interprétation populaire du mot "strict" dans ce contexte.
En fait, ce que Meyer et ses collègues veulent dire par "strict DOCTYPE" est simplement qu'on a affaire à un DOCTYPE complet ou bien valide, c'est à dire à n'importe quel document -- y compris HTML 4.01 Transitional -- incluant une URI complète (Meyer n'utilise pas le terme strict à contre-emploi, c'est juste que le même mot possède différents sens suivant le contexte).
En pratique, nous avons découvert que Netscape 6.x applique son interprétation stricte (celle des experts des CSS) à certains documents HTML 4.01 transitional avec un DOCTYPE complet, et pas à d'autres. Cela vient peut-être du fait que Mozilla est toujours en version Beta, et donc que Netscape 6.x n'est pas achevé. A moins que cela ne recouvre un principe sous-jacent que nous n'avons pas encore réussi à discerner.
Pour revenir à ce qui nous concerne, Mozilla/NN6 applique toujours cette interprétation des CSS -- et donc ces espaces supplémentaires -- aux pages XHTML (Strict ou Transitional). De sorte que lorsque vous convertirez vos pages en XHTML, les images contenues dans les cellules d'un tableau feront à votre mise en page ce que l'Allemagne fit naguère à la Pologne.
DOCTYPEs et affichage
La plupart des navigateurs reconnaissant correctement les CSS utilisent la présence ou l'absence de DOCTYPE complet pour passer en mode "standard-compliant" (NdT: conforme aux standards) ou en mode "backward-compatible" aussi appelé "quirk mode" (NdT: mode "traditionnel" non conforme aux standards), une pratique suggérée en premier (pour autant que l'on sache) par Todd Fahrner en 1998, et implémentée pour la première fois par IE5/Mac en Mars 2000.
Mozilla/NN6 suit cette voie, comme IE6/Win. IE6 inclut également une propriété DOM qui indique si le mode "standard-compliant" est déclenché pour un document donné.
Lorsqu'il se trouve en mode "standards", un navigateur assume que vous savez ce que vous faites, et affiche votre page en suivant les spécifications du W3C. En mode "Quirks", le navigateur considère que vous avez créé une page "à l'ancienne", probablement invalide, et l'affiche comme un vieux navigateur le ferait. Vous contrôlez la voie utilisée par votre navigateur en incluant ou en excluant un DOCTYPE (X)HTML complet.
Référez-vous à Fixing Your Site With the Right DOCTYPE pour savoir quel DOCTYPE vous devriez utiliser pour votre projet web.
(Il y a une exception à cette règle: Mozilla/NN6, comme MSIE, traite les pages HTML 4.0 -- même celles avec un DOCTYPE valide -- en mode "Quirks". Si vous n'êtes pas encore prêt pour le XHTML, mais que vous écrivez du HTML et des CSS valides et que vous voulez que votre page s'affiche correctement, choisissez donc un DOCTYPE HTML 4.01. Sachant bien sûr, que nous vous encourageons à utiliser plutôt du XHTML.)
Après vous être converti au XHTML, si vos images commencent à envahir les frontières de pays voisins, il vous faudra prendre quelques minutes pour ajouter des règles compensatoires à vos feuilles de style. Chaque mise en page est différente, et donc aucune règle ou collection de règles CSS ne corrigeront tous vos problèmes, mais l'article d'Eric Meyer et les règles que nous avons listé ci-dessus devraient vous procurer un bon point de départ, et ce travail supplémentaire ne devrait pas vous prendre trop longtemps.
Espaces blancs et affichage
A travers l'article d'Eric Meyer, Mozilla/Netscape a documenté la manière dont il fonctionne. Nous ne sommes pas sûrs de la raison pour laquelle IE6/Win a décidé de modifier l'affichage lorsque nous avons passé le DOCTYPE de notre page en XHTML (Les deux versions -- la vieille HTML 4.01 Transitional et la nouvelle XHTML 1.0 Transitional -- utilisent des DOCTYPEs complets).
Nous pensons que cela est lié à la manière dont les navigateurs gèrent les espaces blancs (dans le code source -NdT). Chacune des deux balises ci-dessous est équivalente d'un point de vue fonctionnel, mais à cause de leur usage (ou non-usage) des espaces blancs, elles peuvent s'afficher différemment dans des navigateurs qui essayent d'analyser les espaces blancs dans le balisage, de sorte que :
<td><img src="foo.gif" /></td>
... pourrait s'afficher différemment de :
<td> <img src="foo.gif" /> </td>
Le second exemple -- celui avec des espaces blancs dans le balisage -- pourrait produire des trous visuels indésirables dans votre mise en page. De la même manière, dans l'exemple suivant, la première balise (celle sans espace blanc) ...
<td><a href="/traduction/mieuxvivre#foo"><img src="foo.gif" /></a></td>
... pourrait s'afficher différemment du balisage suivant, pourtant fonctionnellement identique :
<td> <a href="/traduction/mieuxvivre#foo"> <img src="foo.gif" /> </a> </td>
Quelle est la raison de ce comportement ? Le "bug de l'espace blanc" était un problème connu dans Netscape Navigator depuis sa version 3.0 (au moins). Quand Microsoft a décidé de construire un navigateur concurrent, ses ingénieurs ont émulé la plupart de comportements de Netscape -- y compris quelques-uns de ses bugs. Nous croyons que MSIE6 continue aujourd'hui à émuler ce vieux bug de Netscape.
Nonobstant la raison d'un tel comportement d'IE6, notre règle additionelle (display: block)
a également corrigé le problème dans ce navigateur. Ce truc vous sera plus ou moins utile, mais des variations de (display: block)
devraient corriger vos problèmes d'affichage d'images à la fois sous Mozilla/NN6 et IE6.
Le XHTML changera votre vie
Utilisés correctement, les standards du W3C améliorent l'accessiblité et promettent une durabilité à long terme (que nous appelons "compatibilité ascendante") à tout document publié sur le web. S'il est important pour vous d'avoir accès au public le plus large pour une durée la plus longue possible, les standards web sont le choix qu'il vous faut, et là où la structure des documents est concernée, le XHTML est le chemin à suivre.
Alors que les standards du W3C sont créés pour aider les experts à accomplir des tâches sophistiquées, le balisage (XHTML) et les feuilles de style sont faits pour tous, et le W3C a pris la peine de paver la voie qui y conduit.
Les règles du XHTML prennent quelques minutes à apprendre et ses bénéfices sont immenses. Il est facile de créer des pages en XHTML et tout aussi facile de convertir du HTML en XHTML à la main. Des outils comme Tidy peuvent aider à automatiser le processus, du moment que vous prenez quelques minutes pour lire la documentation avant d'appuyer sur le bouton.
Les validateurs en ligne gratuits vous aideront à vous assurer que votre XHTML et vos CSS sont corrects, même si les rapports d'erreur peuvent parfois vous dérouter, et si dans de très rares circonstances le validateur peut se planter.
Après être passé au XHTML, vous pourriez avoir à ajuster votre feuille de style de manière à compenser les défauts de présentation d'images de certains navigateurs, particulièrement à l'intérieur des tableaux. Mais si vous intégrez ces étapes à votre méthode de travail, cela deviendra vite une seconde nature. Et, les nouveaux navigateurs gagnant des parts de marché, nous travaillerons de moins en moins avec des tableaux, et de plus en plus avec des CSS.
Avec un peu d'attention et d'amour, le XHTML aidera vos sites à mieux fonctionner avec un plus grand nombre de navigateurs et d'autres appareils, touchant de plus en plus de lecteurs, maintenant et pour les années à venir. Que pourriez vous demander de plus ?
http://alistapart.com/articles/betterliving/