!
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 (measures verticals ou horizontals) 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 attributes 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 &.
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.
19 réponses à cet article
# - - VeutLaPeauDeGoogle -
Pourquoi utiliser Google (googleit) pour amener le lecteur à aller voir ailleurs ?
Tous les moteurs de recherche possèdent une commande "related" ou "backlink", voire "linkdomain". Soyons équitables. Arrêtons d’utiliser Google qui n’est même pas le meilleur pour la langue française … 
# - - Marie ALHOMME -
Bonjour
1. Parce que je ne savais pas que les autres moteurs permettaient de faire ce genre de liens : j’ai vu ça sur un autre blog et ai aimé le concept alors l’ai gardé !
2. Parce que j’aime bien google, que je ne peux pas en mettre 12 pour ne pas faire de jaloux, alors j’ai choisi google que tout le monde connait aussi.
Quand à vouloir y voir une volonté particulière de privilégier un moteur par rapport à un autre… je la renie !
Voilà, j’espère que c’est plus clair !
Maintenant, si tu as un vrai commentaire en rapport avec la traduction, je t’en serai reconnaissante (et mes lecteurs aussi) !!
Bonne continuation, peut-être à bientôt sur le site !
# - - Cyril 's Blog -
Erreurs de develloppement web
Voici une traduction fort interessante de l’article Web Development mistake ; la traduction se trouve…
# - - Nico -
Hum… c plus de l’intégration web ou du design que du dev mais c très bien d’avoir sous la main ce genre mémo.
je dirai aussi de penser a utilisé les attributs "média" qui permette notament de définir une impression propre avec la gestion des sauts de pages, des formats, l’affichage ou non d’éléments de navigation ou d’une entete plus "papier" ect…
Je parlerai de penser aux listes (<ul><li></li><li></li>…</ul>) qui peuvent souvent replacer avantageusement les tableaux (notament pour les menus)
Je noterai également d’utilisé à loisir des images de fond définis dans les css plutot que de mettre les tags <img /> en dur dans le code de la page
et si quelqu’un à une bonne astuce pour être sur de la sortie écran de ses couleurs je suis prenneur car franchement d’un écran à l’autre c’est souvent la cata !!
A nouveau merci pour le mémo !
Nico
# - - Nhk -
Un véritable article de référence selon moi.
Merci beaucoup Marie pour ce bel effort.
# - - Marie ALHOMME -
Bonjour Nico et Nhk !
Nico : ces remarques sont très intéressantes, mais d’une part je ne suis pas l’auteur de l’article, uniquement la traductrice, je ne peux donc pas ajouter ce que je veux dans l’article… et d’autre part les remarques que tu fais sont des conseils alors que cet article se concentre sur des erreurs qu’il tente d’expliquer et auquel il essaye d’apporter des réponses… ce n’est pas la même démarche !
Mais tu peux écrire à l’auteur d’origine sur son site et lui proposer d’incorporer ces remarques à son article, il aura peut-être une réponse positive pour toi !
En tout cas merci de ta visite et de ton commentaire !!
Nhk : mais avec plaisir mon ami, avec plaisir…
Et surtout merci d’apprécier (et de le dire) !!
Je me suis aussi dit, comme toi, que cet article était très important, et qu’il était impensable qu’il n’en existe pas de version française !!
# - - Fro -
Merci d’avoir pris le temps de traduire cette ressource et de l’avoir rendue disponible aux communautés de développeurs et webmestres francophones.
Je pense que l’on ne rappellera jamais assez ces choses pourtant simple et malgrè tout peu appliquées.
Chers amis, prenez en de la graine… je tacherai d’en faire de même.
# - - Bertrand -
Merci pour cette traduction, il est toujours bon d’avoir sous la main tous ces conseils ; un oubli ou une erreur est si vite arrivé !
# - - Whynet.org - Actualités -
Webmaster : Article sur les erreurs de Développement Web
Le site Pouipoui Design nous propose une traduction d’un article intitulé « Erreurs de Développement Web » de Roger Johansson qui fait un petit état des lieux des erreurs de développement au niveau XHTML et CSS rencontrées avec une explication pour chacune.
# - - MrDurden -
Bonjour, Merci pour cette traduction sur un sujet utile.
# - - Les Doigts dans la Prise -
Dev Web Propre
un joli r?m?es mauvaises pratiques que cette traduction des Erreurs de D?loppement Web; comme quoi la preuve par le contre exemple est tres efficace…. Viiiiiite que je check un peu mon code (de que j’arr? de parler franglais, mais ?…
# - - Fred -
Salut !
Juste un grand merci également !
Enfin une vraie traduction pas robotique… !
# - - Marie ALHOMME -
Bonjour !
Merci beaucoup de vos visites et de vos remerciements ! Ca (re)motive !
A bientôt j’espère !
# - - falter -
bonjour et bravo pour tous ces articles bien traduits.
Si je peux me permettre : j’ai horreur de ce genre de site écrit en gris sur blanc, cela me casse les yeux à mort.
Amicalement
# - - Marie ALHOMME -
Bonjour !
Désolée que la couleur de la typo vous déplaisent, mais en attendant que je propose un autre thème pour ce site, vous pouvez désactiver la feuille de style si vous voulez ?
(ou en bon geek averti en utiliser une qui écrase la mienne)
Bref, ravie que les traductions vous plaisent par contre !
J’espère en sortir d’autres bientôt, dès que je reprends mon souffle et mon rythme (je viens de finir un gros projet puis de faire une pause…) !
A bientôt, donc !
# - - hadrien -
Ok, merci pour l’article, c’est tès instructif et pratique…
mais j’ai essayé (pour rigoler) de passer la page de cet article au validateur W3C… et grande surprise, elle ne valide pas correctement ! zut !
alors voici ma question : est-ce que c’est en conaissance de cause ? sinon, pourquoi cette négligence ?
voir :
validator.w3.org/check?ve…
# - - Marie ALHOMME -
Quel farceur, hadrien !
Y’a erreur et erreur… un <br> mal fermé qui traîne, ce n’est quand même pas de quoi se poser des questions sur la validation d’une page… Dois-je rappeler que la validation est certes indispensable mais qu’une « petite » erreur, de frappe par exemple, n’est pas la marque d’un travail baclé ?
Les autres « erreurs » sont :
1. un autocomplete= »off » que je tiens à garder pour m’assurer que le livesearch fonctionne, et qui ne fait de mal à personne !
2. un name= »form » sur un formulaire, reliquat des temps jadis et qui a échappé à ma vigilance,
3. un label dédié à un input « q » qui n’existe pas, dû à une inattention (l’input s’appelle maintenant « livesearch »)…
Bref, rassurez-vous, rien de catastrophique ni de honteux, et j’ai corrigé les erreurs d’inattention !
En tout cas merci de ta visite, lecture et vigilance
et à bientôt pour d’autres trads j’espère !
# - - Yapafoto -
Bravo et merci pour cette traduction, j’ai beau être vigilant et vouloir faire les choses en respectant toutes et tous pour le plaisir et le confort de chacun, y’avait encore des détails(de taille… parfois!) que je n’avais pas pris en compte, difficile de penser à tout :-/
Voilà, maintenant je me suis réactualisé
Encore merci et je t’encourage à donner encore de ton temps et de ton énergie dans la manufacture ou la traduction d’articles indispensables tel que celui-ci!
<ps id="philosophie">Maintenant que le web a pensé aux mal voyant, mal entendant, handicapés et aux allergiques au graphisme (navigateur texte
), quand est-ce qu’on pense aux mal argentés ? ceux qui ont pas de PC voir même pas à mangé dans leur auge, hein…!! mais que fait le W3C? *rolleyes*
Bon d’accord j’suis p’têtre un peu hors sujet!!</ps>
# - - Ziolrooski -
Merci, c’est très complet.