Netscape DevEdge

Accès direct : [contenu] [navigation]

Liberté ! Egalité ! Validité !

Comme une nation ou un bâtiment, une page divisée et mal structurée ne tient pas longtemps, tout du moins dans un navigateur conforme aux standards. Chaque page a sa structure, et il se trouve que si l'on ne fait pas attention aux méthodes de construction, la structure sera affaiblie, et potentiellement dangereuse. Si, après avoir chargé une page dans Opera, Netscape 6/7 ou encore Internet Explorer, son affichage est catastrophique, c'est très certainement parce que sa structure n'est pas correcte.

Imaginons que l'on construit une maison sur des fondations en sable ou avec des poutres en caoutchouc... La plupart des gens ne s'inquiètent pas de ce genre de choses. Mais ceux qui s'en préoccupent ne seront pas étonnés par de grosses fissures dans les murs, un plancher de travers ou encore un effondrement complet du bâtiment. Pourtant, bien des auteurs de pages web s'étonnent de voir ces même pages s'effondrer dans les navigateurs récents. La réaction habituelle est "avant, ça marchait !" un peu comme s'ils disaient : "ma maison avec des piliers en caoutchouc ne s'est pas effondrée le jour même de sa construction". Certes non, mais elle a toujours été sur le point de s'écrouler.

Alors comment peut-on s'assurer de construire une web-maison solide ? Avec du HTML bien structuré. Une structure de document impeccable est absolument essentielle pour s'assurer que vos pages rendront correctement dans les navigateurs d'aujourd'hui et de demain. Heureusement, modifier la structure d'une page après sa construction est infiniment plus facile que modifier celle d'une maison ! En fait, des validateurs de HTML sont disponibles pour vous aider à identifier les problèmes et les corriger. Nous ne saurions trop vous recommander le validateur du Consortium W3, non seulement parce qu'il est proposé par ceux qui sont responsables des spécifications HTML et XHTML, mais aussi et surtout parce que la plupart des messages d'erreur sont dotés d'un lien menant à une explication sur l'origine de l'erreur. Bien sûr, au cours du temps, vous apprendrez à vous passer de ces liens, mais pour commencer, ils sont très utiles.

Votre mission est simple : modifier votre page pour qu'elle passe dans le Validateur sans générer de message d'erreur. Et pour aller plus loin (et toucher des points de Bonus !), vous pouvez essayer d'éliminer les avertissements (Warnings), mais l'essentiel est bien d'éliminer les messages d'erreur. Concrètement, les erreurs peuvent étre séparées en deux catégories :

En modifiant votre HTML pour supprimer une erreur, il est possible que d'autres apparaissent -- ou que soudainement plusieurs autres disparaissent. Par exemple, si vous ajoutez une balise manquante de fin de table, (</table>) dans un document,  cela peut faire disparaître toutes les erreurs "element not allowed here" (élément non autorisé ici) qui suivaient. Dans tous les cas, l'objectif de chaque auteur de page HTML devrait être de n'avoir aucun message d'erreur d'aucune sorte.

DOCTYPE et la validation

Quand vous validez un document, vous pouvez choisir quelle Document Type Definition (DTD) que vous voulez utiliser comme référence. Plusieurs options sont disponibles, depuis HTML 2.0 jusqu'aux standards les plus récents (XHTML 1.1 au moment ou nous écrivons ces lignes). Si vous souhaitez  que vos pages fonctionnent dans les navigateurs modernes, alors il est recommandé de choisir une DTD récente. Compte tenu de la compatibilité ascendante d'HTML et d'XHTML, utiliser une DTD récente pour valider votre code signifie que votre page sera affichée correctement par les navigateurs anciens.

Plutôt que de choisir une DTD de la liste fournie, vous pouvez aussi en indiquer une en haut de votre document, signifiant ainsi à quelle DTD spécifique il se réfère. Partons du principe que vous souhaitez utiliser la DTD "HTML 4.0 Strict". Dans ce cas, la toute première ligne de votre document (avant même la balise <html>) devrait être :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">

Une fois que vous avez ajouté cet élément en haut du document, vous pouvez utiliser l'option DTD "specified inline" (spécification incluse dans le document) et le Validateur du W3C utilisera la DTD spécifiée pour valider votre code.

De plus, les navigateurs récents (Netscape 6 et 7, Explorer 5 pour Macintosh, Explorer 6 pour Windows) utilisent l'élément DOCTYPE pour déterminer le "mode de rendu" que vous souhaitez utiliser lors de l'affichage de cette page. De façon générale, les DTD "transitional" et "loose", ainsi que l'absence d'une déclaration DOCTYPE, feront que les navigateurs utiliseront un mode de rendu qui émule le comportement des anciens navigateurs. Les DTD de type "strict", par contre, feront que les pages seront affichées dans un mode strictement conforme aux standards. Ceci permet simplement aux auteurs de spécifier comment ils souhaitent que les navigateurs rendent les pages. L'Apple Developer Connection propose un article (en anglais) intitulé "DOCTYPE Explained" qui présente le sujet plus en détail. Notons par ailleurs qu'Internet Explorer 6 pour Windows supporte lui aussi ce changement rendu en fonction du DOCTYPE, décrit dans l'article.

Les problèmes courants.

En tant qu'auteur, il est certaines erreurs que vous retrouverez de très nombreuses fois en validant vos pages. Il en est même certaines qu'un validateur ne trouvera pas (les logiciels sont pas meilleurs que leurs auteurs !) En voici quelques-unes parmi les plus souvent rencontrées, et les pièges à éviter...

Oublier des attributs importants

Si vous obtenez une erreur liée à un attribut, c'est très probablement parce que vous avez oublié d'inclure un attribut requis. En particulier :

Ces deux derniers attributs sont importants pour des raisons d'accessibilité, car leur utilisation permet l'accès aux personnes dotées de navigateurs audio ou n'affichant que du texte. Le premier attribut de la liste est très important pour la compatibilité avec les versions futures. Par exemple, beaucoup de navigateurs (dont Netscape 6 et 7) ignorent tout élément style ne disposant pas d'attribut type, ce qui désactive la totalité de la feuille de style, ce qui est rarement l'effet recherché par l'auteur du document.

De la même façon, le DOCTYPE strict pour HTML et XHTML ne permet pas l'attribut language, aussi type est la seule façon d'indiquer quel type de script est utilisé. Aussi, si vous avez un script qui commence par

<script language="Javascript">

... alors le validateur affichera une erreur. Il est possible de régler le problème par ce moyen

<script type="text/javascript">

Problèmes de script

Au-delà des problèmes liés à l'attribut language, les scripts peuvent être à l'origine d'autres soucis au moment de valider votre HTML.

Si votre script contient des balises HTML au sein de chaînes de caractères, il est nécessaire de faire précéder les slashes (barres de division) par un backslash. Par exemple, vous devrez taper var docEle = "<html><\/html>" (notez le caractère en gras) pour éviter les problèmes de validation. Dans tous les cas, c'est une bonne habitude à prendre.

Vous devriez aussi mettre le contenu de vos éléments script dans un commentaire HTML. Voici à quoi cela ressemble généralement :

<script type="text/javascript"><!--
   (...insérer le script ici...)
//--></script>

Notez le commentaire mono-ligne (//) sur la dernière ligne, nécessaire pour être certain que l'interpréteur Javascript ignore la chaîne -->

Imbrication incorrecte d'éléments

Au fil du temps, les auteurs ont inventé un certain nombre d'astuces pour obtenir ce qu'ils veulent avec un minimum de travail, et en évitant les limitations de certains navigateurs. Malheureusement, la plupart de ces astuces reposent sur du code invalide, donc qui provoquera des messages d'erreur de la part du validateur. De plus, elles provoqueront des problèmes d'affichage et/ou de fonctionnalité dans des navigateurs conformes aux standards tels que Netscape 6 et Internet Explorer (en mode "strict"), et devront être corrigées de toute façon.

Un exemple très courant est d'utiliser un élément font pour un ou plusieurs paragraphes, tables ou d'autres éléments de niveau bloc. Il se trouve que font est un élément en ligne, et de ce fait, ne peut contenir d'éléments de niveau bloc. Aussi, le code ci-dessous est structurellement invalide :

<font color="red">
<p>Ne pas mettre de paragraphes dans les éléments fonts !</p>
</font>

Le problème est exactement identique si vous mettez une table au sein d'un élément font. Si vous souhaitez avoir de la couleur dans toutes les cellules de votre table, en utilisant font pour cela, il vous faudra mettre des éléments font dans chaque cellule ! Bien sûr, les feuillez de styles (CSS) rendent la tâche beaucoup plus simple :

<table style="color: red;">

Dans le même genre, certains développeurs aime éviter la ligne vierge générée par l'élément form au sein de cellules de tableaux en faisant ceci :

<table>
<form action="script.cgi" method="get">
<tr><td>(...éléments de formulaire...)</td></tr>
</form>
</table>

Cela va provoquer une erreur car il n'est pas possible de mettre un form dans une table en dehors d'une cellule. On pourrait mettre toute la table dans l'élément form ou bien mettre le formulaire dans la cellule et utiliser CSS pour avoir une marge nulle, mais dans ce cas, tout le formulaire devrait se trouver dans cette cellule. Et si vous utilisez une table pour mettre en page votre formulaire, alors ce formulaire doit inclure la totalité de la table, ou une section complète du document, si c'est possible.

Incohérence de la casse entre Class et ID

Bien qu'historiquement HTML ait été insensible à la casse (ne faisant pas de différence entre majuscules et minuscules), les valeurs en XML, XHTML et le HTML moderne sont sensibles au changement de casse. C'est le cas en particulier des identifiants de classe et d'ID.

De ce fait, ExternalLink n'est pas identique à externalLink ni à externallink. Les navigateurs conformes aux standards tels que Netscape 6 et 7 respectent la casse des noms de classes et d'ID. Par contre, le Validateur HTML ne vérifie pas ces éventuelles discordances, et ne vous permettra pas de détecter à l'avance ces problèmes d'affichage. Pour plus d'information, reportez-vous à l'article de Netscape Devedge, "Case Sensitivity in class and id Names".

Commentaires invalides

Au risque de paraître pointilleux, il est important de formater correctement vos commentaires HTML. Le format correct d'un commentaire est :

<!-- commentaire -->

Il y a deux tirets à la fin, pas trois, comme certains auteurs aiment à faire. De façon générale, il vaut mieux éviter toute séquence de tirets dans un commentaire et se limiter à la paire qui sert à délimiter le début et la fin du commentaire. (Se reporter à HTML 4.01, section 3.2.4 pour plus d'information.)

"Et" commercial / esperluette

Parce que l'esperluette (&, aussi connue à tort sous le nom de et-commercial) est réservée pour les entités caractères, les auteurs ne doivent jamais les utiliser tel quel dans leur source HTML, ni dans les URLs qui s'y trouvent. De ce fait, les URLs contenant une esperluette doivent être écrites de cette façon :

http://www.site.web/path/doc.html?var1=val1&amp;var2=val2&amp;var3=val3

Chaque instance de &amp; sera traduite par le navigateur Web en esperluette, sans déclencher de message de la part du validateur.

Présence de la valeur d'attribut entre guillemets

Si vous vous réferez à un DOCTYPE XHTML pour la validation, alors tous vos attributs doivent avoir des valeurs, lesquelles devront être entre guillemets. Vous devrez aussi fermer tous les éléments que vous ouvrez, et dans les cas où il n'existe pas de balise fermante, la fin de l'élément

<input type="checkbox" checked="checked" name="prefSys" value="MacOS" />

Notez bien que l'attribut checkbox a une valeur entre guillemets, et qu'on trouve un "slash" en fin de balise. Sans cela, cette ligne ne serait pas valide en XHTML.

Conclusion

Même si au premier abord, la validation de vos pages peut sembler fastidieuse, elle vous permettra par la suite de gagner du temps par la suite. Non seulement vos documents ont beaucoup plus de chance de s'afficher correctement dans les navigateurs d'aujourd'hui et de demain, mais ils seront aussi beaucoup plus faciles à maintenir, voire même à convertir vers un autre langage de balises tel qu'XML.

Dans l'absolu, l'objectif est de n'avoir ni erreur ni avertissement lors de la validation de votre document. Mais il vaut mieux commencer par éliminer les erreurs effectives. En effet, les erreurs portant sur les éléments sont plus importantes que celles concernant les attributs, même si on ne peut pas se permettre d'ignorer ni l'une ni l'autre. Une fois votre "nettoyage" effectué et que le validateur n'affiche plus d'erreurs, alors vous pouvez commencer à mettre en page le document, sans risquer de le voir mal s'afficher dans à peu près tous les navigateurs du moment, et même ceux qui seront utilisés dans l'avenir.

A+R