Je voulais vous parler de cet excellent article de Tantek Celik depuis plusieurs jours, mais entre la refonte organisationnelle et graphique de ce site – la seconde ne me satisfaisant pas encore pleinement – et un week-end en province particulièrement chargé, j’ai du délaisser quelque peu l’écriture.

De nombreux articles exposent les mille et une bonnes raisons de passer ses sites en XHTML, que ce soit en s’appuyant sur l’esprit – respect des standards, accessibilité – ou sur la lettre – à travers les outils de validation mis en place par différents organismes. La plupart d’entre eux sont excellents, mais si la réponse au “pourquoi ?”

apparaît fréquemment, la réponse au “comment ?” se fait beaucoup plus rare. Tantek se propose de l’apporter en abordant les huit points principaux à valider pour produire un XHTML de qualité.

Histoire d’éviter les malentendus, je tiens à répéter ici que l’article original n’est pas de moi, et je vous recommande chaudement de le lire dans sa totalité si vous comprenez l’anglais. Je me contente de reprendre la base des huit points de Tantek afin de les compléter avec mon avis et mes réflexions.

1– Validez la syntaxe de vos pages.

La validation syntaxique concerne aussi bien le XHTML que le CSS. Dites vous bien que 95% des bugs et erreurs que vous rencontrerez durant l’intégration, qu’ils concernent le Javascript reposant sur DOM ou le style, se résolvent d’eux même avec une syntaxe valide. Ne perdez cependant pas de vue que les outils de validation sont bien des outils et non une fin en soi. À ce titre, je partage tout particulièrement l’avis de Dan Cederholm quand il dit que, pour un site destiné à produire un contenu particulièrement important injecté par un grand nombre de personnes – typiquement un wiki, un CMS, ou un blog – les erreurs de validation sont courantes, plus encore si les utilisateurs ne sont pas au fait des standards. La validation doit se faire au moment de l’intégration, et si possible après, mais sur des sites de plusieurs milliers de pages et au contenu complexe, ce n’est pas toujours possible. En revanche, sur de petits sites, ne pas valider est impardonnable.

Voici, si l’on excepte les fautes de frappe, les dix erreurs que je rencontre le plus souvent dans les sites non valides :

  1. L’absence de <doctype>. La présence d’un <doctype> en en-tête de toute page (X)HTML est obligatoire, et fonction du langage de balises utilisé : HTML 4.01, XHTML 1.0 transitionnal ou strict, XHTML 1.1 ou XML. Le <doctype> approprié est indiqué sur le site du W3C dans les pages consacrées au langage choisi, ou dans les entêtes de n’importe quelle page valide. Use the source, Luke ! – un jedi mort d’avoir trop codé.
  2. Les balises tombées en désuétude ou propriétaires.
    Certaines balises HTML sont tombées en désuétude, comment <font> depuis HTML 4.01 ou sont spécifiques à certains navigateurs, comme <embed>. Elles ne doivent donc pas être utilisées. À ce titre, je vous recommande la lecture urgente de cet excellent article sur l’insertion de contenu multimédia dans une page Web sans utiliser <embed>.
  3. Les attributs propriétaires ou tombés en désuétude.
    Tout comme les balises, certains attributs peuvent tomber en désuétude, c’est le cas de target, ou n’avoir tout simplement jamais été supportés par le W3C, comme autocomplete
  4. Les tags vides non fermés.
    Les éléments XHTML vides doivent se terminer par un “/”, notamment <link>, <img> et <br> qui deviennent <link />, <img /> et <br /> en XHTML.
  5. Les éléments de types block imbriqués dans les éléments de type inline.
    Les éléments de type block comme <p> et <div> ne doivent pas être insérés dans des éléments de type inline comme <span> ou <a>.
  6. Les tags de fermeture placés à tort et à travers.
    Rappelez vous qu’on ne ferme un tag qu’à la condition sine qua non d’avoir fermé tous les tags imbriqués.
  7. Les tags non fermés.
    Le cas le plus fréquent est le <div> non fermé, comme celui que je viens de corriger en vérifiant la bonne validation syntaxique de ce site.
  8. Les scripts et styles sans type spécifié.
    Afin d’interpréter un script, le navigateur a besoin d’en connaître le type. Les deux types les plus rencontrés sont les styles CSS et le javascript pour lesquels on indiquera <style type="text/css"> et <script type="text/javascript">, sans oublier de fermer la baslise script à la fin.
  9. L’utilisation du camelCase dans les documents XHTML
    Un des grands principes du XHTML est d’être totalement écrit en minuscules. L’utilisation de onClick pour onclick, ou de onSubmit pour onsubmit est donc interdite, même si le navigateur les interprète à priori correctement.
  10. Les formulaires sans l’attribut action
    Quel qu’en soit la valeur, l’attribut action – la page de destination lors de la validation – doit être obligatoirement mentionné, quand bien même il s’agirait de la page courante.

2– Proscrivez les mises en pages utilisant des tableaux et les gifs de 1 pixels de côté en guise de séparateur.

Est-il vraiment besoin de s’attarder dessus ?

3– Supprimez les mots clés <meta>

Les mots clés <meta> représentent tout à la fois une perte de temps, de place, et une insulte mortelle aux principes de visibilité et d’accessibilité contenus dans le Web sémantique, sans compter que les moteurs de recherche ne les prennent pas en compte. Préférez leur les tags bien plus précis et répondant à toutes les exigences précédemment citées.

4– Faites attention à la nomenclature de vos classes et de vos identifiants.

Utilisez le contexte au lieu d’ajouter de nouvelles classes, vous y gagnerez en place et en lisibilité. Par exemple, dans une liste non ordonnée <ul class="menu">, inutile de déclarer tout un tas de <li class="menuitem"> quand un simple ul.nav li dans votre feuille de style suffit largement. Rappelez vous : la structure imbriquée du HTML et le principe d’héritage des propriétés en cascade dans CSS permettent d’économiser à la fois du temps, de l’espace et de l’aspirine lors des tentatives de relectures de soupes de balises indigestes. Utilisez des noms de classes et d’id en minuscule. Préférez id=”sitenav” à id=”siteNav”, vous y gagnerez en lisibilité et éviterez des heures de débogage pour une simple faute de frappe dans un nom de classe. Quand vous le pouvez, utilisez des noms de classe indiqués dans les différents microformats si l’occasion s’en présente.

5– Évitez les grands espaces blancs dans votre code.

Non seulement ça n’a jamais rendu le code plus lisible, mais en plus ça ne sert strictement à rien.

6– Utilisez rel et hreflang dans vos traductions.

Lorsque vous créez des liens vers une version de votre site dans une langue autre que sa langue principale, utilisez l’attribut rel="alternate" pour indiquer une langue alternative, et hreflang="en" pour indiquer la langue de destination. Les navigateurs respectant les standards donnent même la possibilité de faire apparaître la langue alternative à côté du lien avec un peu de CSS :

    a[hreflang]:after { 
        content: "\0000a0[" attr(hreflang) "]";
        color:#20705e;
        text-decoration: none;
    }

Il existe une différence fondamentale entre lang= ou xml:lang= et hreflang= : lang= indique la langue du document courant, tandis que hreflang= indique la langue du document lié. On trouve là une différence semblable à celle entre rel= et rev=.

7- Supprimez les balises commentées.

Des balises commentées n’ont à priori rien à faire dans une page Web en production. Elles font perdre du temps à l’affichage et augmentent inutilement la taille des pages. Si vous utilisez un système de templates, commentez les balises que vous ne voulez pas voir apparaître à l’aide du système de commentaires du langage concerné, et évitez autant que faire se peut les commentaires SGML <!– … –>.

8- Utilisez le microformat hCard.

Il est très facile d’insérer le microformat hCard pour marquer les informations vous concernant directement. Les outils et scripts supportant hCard sont de plus en plus nombreux, et permettent l’insertion de votre carte de visite au format vcard d’un simple clic. Ce serait dommage de s’en priver non ?

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: