Traduction : Erreurs de Développement Web

Voici la traduction d’un article (amha) très intéressant de Roger Johansson sur son site 456 Berea Street.
J’espère que la lecture de cet article pourra vous aider (ou au pire vous rappeler de « bons souvenirs »… ;) !
(Attention, c’est long !)
Edit du 11/03/06 : petites corrections d’orthographe, de coquilles et de traduction, merci « Pierre alias Mozinet » ! :)


Début de la traduction (Article d’origine)

Ceci est une compilation des erreurs communes en développement web dont j’avais déjà parlé dans les articles "Web development mistakes" et "Web development mistakes, Redux".

Cette liste répertorie les erreurs qui sont communément rencontrées sur le Web, accompagnées d’une explication de la raison pour laquelle je les considère comme des erreurs. J’essaye aussi d’offrir un moyen d’éviter chaque erreur, ainsi que des liens vers plus d’informations sur certaines des erreurs.

Confusion de DOCTYPE

Manquant complètement, incorrect, ou au mauvais endroit. J’ai vu du HTML 4.0 Transitional utilisé dans des documents contenant du code XHTML ainsi que dans des documents avec <frameset>, des déclarations de DOCTYPE apparaissant après la balise <html> d’ouverture, et des DOCTYPES incomplets.

Pourquoi ?

Deux raisons. D’abord c’est requit comme déclaré dans les Spécifications HTML 4.01 du W3C (en) ainsi que dans les Spécifications XHTML 1.0 du W3 (en). Ensuite, les navigateurs web modernes utilisent le DOCTYPE spécifié pour décider du mode de rendu qu’ils utilisent. Ceci est aussi connu sous le nom de “DOCTYPE switching”. Afin d’obtenir des résultats plus homogènes d’un navigateur à l’autre, surtout quand on utilise les CSS, vous voudrez que les navigateurs utilisent le mode « Standard ». Plus d’information sur le “DOCTYPE switching” peut être trouvée dans les articles : Réparez votre site avec le bon DOCTYPE ! (en) et Activer le bon mode de mise en page en utilisant la déclaration de DOCTYPE (en).

<span> mania

Une façon commune de donner un style à un élément avec les CSS est de l’encapsuler dans un élément <span> avec un attribut class et d’utiliser cela pour le lier au style. Je suis sûr que nous avons tous vu des choses comme <span class="titre"> et <span class="textecontenu">.

Pourquoi ?

Dans la plupart des cas, c’est complètement inutile, ça n’a aucune valeur sémantique, et ça ne fait qu’encombrer le code. Utilisez des balises de titre (hx) pour les titres, mettez les paragraphes dans des balises de paragraphe, codez vos listes avec les éléments HTML de liste. Utilisez les CSS pour appliquer des styles à ces éléments. Si nécessaire, ajoutez des attributs de class ou d’id.

Penser (trop) visuellement

Traiter le web comme du WYSIWYG (“What You See Is What You Get”) : commencer en se concentrant sur l’aspect des éléments au lieu de réfléchir à la structure d’abord et à la présentation après.

Pourquoi ?

Bien que la plupart des gens voient, tous ne le peuvent pas. Et il n’y a aucun moyen de rendre le site WYSIWYG. Il y aura toujours des variations tant que les gens n’utiliseront pas tous les mêmes : navigateur, système d’exploitation, résolution, taille de fenêtre, calibration chromatique et taille de typo. Le Web n’est PAS du print ou de la télévision. Faites des mises en pages flexibles !

Manque de sémantique

Code non-sémantique. Baser son choix de l’élément HTML à utiliser en fonction de son apparence par défaut dans la plupart des navigateurs graphiques, au lieu de le faire en fonction du sens de l’élément.

Pourquoi ?

Cette erreur est très proche de la “<span> mania” en ce qu’elle ne correspond pas à une utilisation correcte des éléments HTML préexistants afin de donner un sens au contenu. Sans un code HTML sémantique, il est bien plus difficile pour les agents utilisateurs non visuels [NDLT : navigateurs textes ou oraux par exemple] de donner un sens au contenu. Le code HTML sémantique tend aussi à être facile à styler avec les CSS.

Disparités d’encodages de caractères

Spécifier un encodage de caractère dans le header HTTP envoyé par le serveur, et en utiliser un autre dans le document. Ceci peut troubler les navigateurs et leur faire afficher le document incorrectement.

Pourquoi ?

Parce que vous vous voulez vous assurer que vos visiteurs peuvent lire votre contenu.

Mauvais attributs alt

Manquants ou inutiles. Des éléments <img> auxquels manque un attribut alt peuvent se trouver par milliards sur le web. Un peu moins fréquents sont les attributs aux valeurs inutiles comme “spacer GIF utilisé pour rendre la mise en page plus jolie ”, “grosse puce bleue avec ombré ”, et “Image JPEG, 123 Ko”. Rappelez-vous que l’attribut alt est requis pour les éléments <img> et <area>.

Pourquoi ?

C’est requis (en), et sans eux toute information dans l’image sera invisible pour les lecteurs d’écrans, les navigateurs texte, les robots de moteurs de recherche, ou les utilisateurs chez qui les images sont désactivées. Notez que le texte alternatif devrait être approprié. Ne spécifier pas de texte alternatif pour les images décoratives ou les images utilisées pour la mise en page. Dans ces cas, spécifiez une chaîne vide : alt="".

Attributs id et class invalides

Utilisation multiple d’une même valeur pour l’attribut id. Caractères invalides utilisés dans les attributs de class et d’id et les sélecteurs CSS.

Pour les CSS (Syntaxe et types de données de base en CSS 2.1 (en)) : En CSS 2.1, les identifiants (incluant les noms d’éléments, les class et les id) ne peuvent contenir que les caractères [A-Za-z0-9] et les 10646 caractères ISO U+00A1 et supérieur, plus le tiret (-) et le tiret bas (_); ils ne peuvent commencer par un chiffre.

Pour l’HTML (Types de données de base en HTML (en)) : Les ID et les NAME doivent commencer par une letter ([A-Za-z]) et peuvent être suivis de n’importe quel nombre de lettres, chiffres ([0-9]), tirets (“-“), tirets bas(“_”), deux-points (“:”), et points (“.”).

Pourquoi ?

Les navigateurs qui suivent les spécifications n’afficheront pas le document comment vous l’aviez prévu. Si un document a de multiples occurrences de la même valeur d’id, n’importe quel JavaScript utilisant cette valeur a toute les chances de ne pas fonctionner ou de fonctionner de manière imprévisible.

Reconnaissance du navigateur (“Browser sniffing”)

Utiliser des scripts, côté serveur ou client, de façon à détecter le navigateur du visiteur et lui envoyer ou lui faire exécuter du code spécifique à ce navigateur. Échoue très souvent pour des raisons telles que : nouveaux navigateurs, navigateurs mis à jour, et le « user agent spoofing » [NDLT : fonction qui permet à un navigateur de se faire passer pour un autre] (Opera fait ceci par défaut [NDLT : en se faisant passer pour IE]).

Pourquoi ?

Cela complexifie le processus inutilement et finira par casser à la fin.

Unités manquantes en CSS

Les valeurs de longueur (mesures verticales ou horizontales) requièrent des unités en CSS, sauf quand la valeur est zéro. C’est différent d’en HTML, où vous pouvez taper width="10". En CSS, cela doit être écrit width:10px; (ou n’importe quelle unité que vous utilisez).

Pourquoi ?

Cela ne marchera pas dans les navigateurs qui suivent les spécifications (en).

CSS spécifiques à un navigateur

Styler les barres de scroll, les expressions, les filtres, etc. Les CSS propriétaires qui ne fonctionnent que dans Internet Explorer. Ce n’est pas valide, en plus.

Pourquoi ?

Cela ne marchera que dans un navigateur spécifique. Si vous devez réellement utiliser des CSS spécifiques à IE, déplacez-les dans un fichier séparé et utilisez les commentaires conditionnels (en), ou une autre méthode, afin de vous assurer que seulement IE verra les règles invalides.

Dépendance à JavaScript

Rendre un site dépendant de JavaScript. Plus de personnes que vous ne le voudriez utilisent un navigateur sans support du JavaScript, ou ont désactivé le JavaScript dans leur navigateur. Les statistiques actuelles (Statistiques navigateurs sur W3Schools (en), TheCounter.com) indiquent que cela concerne 8 à 10% des utilisateurs. Les robots des moteurs de recherche ne savant présentement pas bien interpréter le JavaScript non plus, même s’il y a des rapports selon lesquels Google travaille au support de JavaScript pour le Googlebot. Si votre site nécessite du JavaScript pour naviguer, n’espérez pas de bons classements dans les moteurs de recherche.

Pourquoi ?

Non accessible et mauvais pour les classements dans les moteurs de recherche.

Dépendance à Flash

Supposer que tout le monde a Flash installé. Ce n’est pas le cas. Et la plupart des robots des moteurs de recherche n’ont plus (Google aurait commencé à expérimenter avec l’indexage des fichiers Flash, mais il recommande que vous vous assuriez que tous votre contenu textuel et votre navigation soit disponibles dans des fichiers HTML), alors si votre site entier, ou votre navigation, dépend de la présence de Flash, vous n’allez pas avoir beaucoup de succès auprès des moteurs de recherche.

Pourquoi ?

Inaccessible et mauvais pour les classements dans les moteurs de recherche. Je ne dis pas que vous ne devriez pas utiliser Flash du tout, mais seulement qu’il faut le faire raisonnablement.

Texte en image

Faire des images du texte et ne pas fournir une alternative plus accessible. Non seulement il est plus long pour les utilisateurs de charger des images que du texte, mais vous rendez aussi impossible de copier du texte pour tous les visiteurs, ainsi que, pour la plupart d’entre eux, de le zoomer.

Pourquoi ?

Inaccessible, augmente le temps de chargement, mauvais pour les classements dans les moteurs de recherche.

Mauvais formulaires

Formulaires non accessibles et difficiles à utiliser. Apprenez à utiliser les éléments <label>, <fieldset>, et <legend>, et n’utilisez pas de bouton “Reset” (« remise à zéro »).

Pourquoi ?

Inaccessible, diminue l’utilisabilité. Lisez Créer des Formulaires Accessibles (en), De Meilleurs Formulaires Accessibles (en), et Boutons Reset et Cancel (en) afin d’en savoir plus sur la création de formulaires accessibles et utilisables.

HTML "à l’ancienne"

Tables multiples imbriquées, spacers GIF, éléments <font>, code de présentation. Si commun que je n’ai pas vraiment besoin de le mentionner ici.

Pourquoi ?

Complexité accrue, pages artificiellement gonflées, lent, inaccessible, mauvais pour les classements dans les moteurs de recherche.

Etre “IE-centrique”

Coder pour IE/Win d’abord, puis ajuster pour les autres navigateurs s’il reste du temps.

Pourquoi ?

Cela prend plus de temps, encourage les mauvaises habitudes de codage. IE/Win est connu pour accepter un code HTML invalide et bâclé, qui ne fonctionne pas (ou mal) dans de nombreux autres navigateurs. IE accepte aussi du code HTML bien formé et valide, qui fonctionne dans tous les navigateurs, donc en utilisant de l’HTML valide vous rendez tous les navigateurs heureux, et cela ne vous prendra pas plus de temps ou ne coûtera pas plus cher. Voir aussi Le Facteur IE (en).

Attributs HTML invalides

Utiliser des attributs dépréciés ou spécifiques à un navigateur comme marginwidth, leftmargin, language, height pour les éléments <table>, border pour les éléments <img>, etc.

Pourquoi ?

Invalide et inutile. Utilisez plutôt les CSS. Pour les éléments <script>, utilisez type, et non language, afin de spécifier le langage de script utilisé (presque toujours JavaScript).

Signes & (ampersands, ou esperluette en français) non encodés

Beaucoup d’URI contiennent de longues chaines de requêtes avec des esperluettes non encodées (&). Ceci n’est pas valide, et peut causer des problèmes (en). Les esperluettes doivent être écrites &amp;.

Pourquoi ?

Une explication ainsi qu’un exemple de ce qui peut mal se passer peuvent être trouvées dans Esperluettes et validation (en).

Cadres (Frames)

Utiliser des cadres pour séparer l’espace en plusieurs documents indépendants.

Pourquoi ?

Tout d’abord, laissez-moi dire que les cadres peuvent être utiles, utilisés de la bonne manière, dans les intranets et certaines applications web. Pour un site publique, cependant, les cadres posent trop de problèmes d’accessibilité et d’utilisabilité. Problèmes d’ajout aux favoris, difficultés d’impression, problèmes avec les liens profonds [NDLT : Deep Linking (en)], et l’obligation de trouver des solutions de contournement pour les moteurs de recherche, sont quelques-uns des inconvénients de l’utilisation des cadres.

Tableaux de données inaccessibles

Les tableaux contenant des données tabulaires, mais dont le code correspond à des tableaux utilisés pour la mise en page, en n’utilisant aucun des nombreux éléments et attributs disponibles afin de rendre les tableaux structurés et accessibles.

Pourquoi ?

Les lecteurs d’écran et autres technologies d’assistance n’ont aucun moyen de donner un sens à un tableau de données à moins qu’il soit codé correctement. Un tas de liens décrivant comment coder des tableaux de données peuvent être trouvés dans A table, s’il vous plaît (en), sur le site du Web Standards Project.

Divitis et classitis

Lié à la "<span> mania". Ajouter des éléments <div> et des attributs class non nécessaires.

Pourquoi ?

Voir “<span> mania” et “Manque de sémantique”.

Largeur fixe trop large

Si vous utilisez un design à largeur fixe, ne le faites pas trop large. Note : Je ne rentrerai pas dans le débat sur fixe vs fluide ici.

Pourquoi ?

Si votre largeur spécifiée est plus large que la place disponible sur l’écran de vos visiteurs, vous les forcez à scroller horizontalement, ce qui est vraiment mauvais pour l’utilisabilité.

Noms d’id et de class vagues et/ou de présentation

Nommer une class ou une id basée sur son apparence plutôt que son action.

Pourquoi ?

C’est chercher les ennuis lors d’une refonte graphique. Une class nommée bleularge peut se retrouver à rendre du texte petit et rouge. Un id nommé colgauche pourrait être affiché sur la droite.

Pas de couleur pour le fond

Ne pas déclarer de couleur de fond pour l’élément body.

Pourquoi ?

Beaucoup d’utilisateurs n’ont pas leur navigateur paramétré pour afficher la même couleur de fond que vous.

XHTML mal formé

Utiliser de l’XHTML qui n’est pas bien formé (en).

Pourquoi ?

Si XHTML est envoyé comme application/xhtml+xml, ce qu’il devrait être, les navigateurs se confirmant strictement aux standards, comme ceux basés sur Mozilla, ne sauront pas afficher de l’XHTML mal formé. Notez que ce site n’envoie pas tous les documents comme application/xhtml+xml, pour certaines raisons expliquées dans mon article sur la Négotiation de contenu (en).

Couleurs incomplètes pour les champs de texte

Spécifier uniquement la couleur du fond ou celle du texte pour les champs de formulaire, surtout les champs de texte uni- et multi-lignes (<input type="text"> et <textarea>).

Pourquoi ?

Certaines personnes ont paramétré leur navigateur ou leur système d’exploitation afin qu’ils affichent des couleurs inversées. Le réglage par défaut d’un champ de texte serait alors texte blanc sur un fond noir, au lieu de texte noir sur fond blanc. Si vous choisissez le gris foncé pour le texte mais ne spécifiez pas de couleur pour le fond, les visiteurs avec les couleurs inversées auront un texte gris foncé sur un fond noir, ce qu’il est quasiment impossible de lire. L’inverse causera aussi des problèmes : spécifier un fond de couleur gris pâle sans spécifier la couleur du texte résultera en un texte blanc sur un fond gris clair.
Spécifiez toujours soit la couleur du texte et celle du fond, soit aucune des deux, pour les champs de texte.

Voilà une liste plutôt longue des choses dont il faut se méfier. Évitez les toutes et vous vous débrouillerez très bien. Si vous faites actuellement une de ces erreurs, eh bien si ça peut vous consoler j’ai moi-même été coupable d’en avoir fait une grande quantité à un moment donné. Avec un peu de chance, cette liste vous aidera à faire moins d’erreurs dans le futur.

Commentaires