Question

Développer des sites Web prend beaucoup de temps. Pour améliorer la productivité, je coderais un prototype à montrer à nos clients. Je ne crains pas de rendre le prototype conforme à la norme. La plupart du temps, nos clients approuvaient le prototype et donnaient un délai déraisonnable. Je finis habituellement par utiliser le prototype en production (hé, le prototype fonctionne. Inutile de rendre mon travail plus difficile.)

Je pourrais refactoriser le code pour générer du code HTML valide. Mais vaut-il la peine de fournir un code HTML valide?

Était-ce utile?

La solution

Cela ne vaut la peine que si vous bénéficiez d’un avantage pratique. Le respect des normes peut faciliter la création d’un site Web qui fonctionne avec la plupart des navigateurs. Encore une fois, si vous êtes satisfait de la façon dont un site Web s'affiche sur les navigateurs qui vous intéressent (un, voire tous les navigateurs), alors effectuer des étapes pour que sa validation soit validée est une perte de temps.

En outre, la différence de référencement entre un site Web HTML entièrement valide et un site Web HTML presque valide est négligeable.

Vous devez donc toujours rechercher les avantages pratiques, il y en a dans certaines situations, mais ne le faites pas pour le plaisir.

Autres conseils

Oui. Il est déjà assez difficile d'essayer de déterminer comment différents navigateurs génèreront du code HTML valide, sans parler du fait de prédire ce qu'ils feront avec un code non valide. Il en va de même pour les moteurs de recherche. Si vous rencontrez suffisamment de problèmes dans le code HTML, le site ne sera pas indexé correctement, voire pas du tout.

Je suppose que la vraie réponse est "cela dépend de ce qui n’est pas valide à propos du code HTML". Si les éléments non valides sont liés à des problèmes d’accessibilité, vous constaterez peut-être que votre client a des problèmes juridiques s’ils utilisent le site à des fins commerciales.

Probablement pas si vous avez un site non conforme et que vous manquez de temps.

Cependant, et vous ne me croirez pas parce que je ne croyais pas les autres au départ, mais il est plus facile de rendre un site conforme dès le départ - cela vous évite des problèmes de compatibilité de navigateur, de comportement CSS et même Comportement JavaScript et il est généralement moins de balisage à maintenir.

La conformité du site (du moins à la transition) est assez facile.

Produire du code HTML compatible revient à s’assurer que vous n’aurez aucun avertissement lors de la compilation - les avertissements sont là pour une raison, vous ne pouvez pas vous en rendre compte, mais ignorez les avertissements et, avant de savoir où vous vous trouvez, comme autant, vous ne pouvez pas repérer celui qui est pertinent au problème que vous essayez de résoudre.

Si vous utilisez Firefox pour afficher vos pages Web, une coche verte ou une croix rouge apparaît dans le coin inférieur droit de l'écran. Elle vous indique rapidement si vous vous êtes conformé ou non. En cliquant sur une croix rouge, vous verrez tous les endroits où vous avez gaffé. Certains avertissements / erreurs peuvent sembler un peu pédants, mais corrigez-les et vous en bénéficierez à bien des égards.

  1. Votre page est beaucoup plus susceptible de fonctionner avec un plus grand nombre de navigateurs.
  2. La conformité de l'accessibilité sera plus facile (vous aurez par exemple des attributs 'alt' sur vos images)
  3. Si vous choisissez XHTML comme norme, votre balisage sera probablement plus utile dans un environnement AJAX.

Si vous ne le faites pas, le résultat sera imprévisible.

L’un des plus gros problèmes des navigateurs Web est qu’ils ont perpétué de mauvaises habitudes (et le font encore, dans certains cas) en corrigeant en silence certains problèmes de marquage, tels que l’échec de la fermeture de cellules de tableau et / ou de lignes. Ce simple fait a entraîné la création de milliers de pages Web non conformes, mais fonctionnant, entraînant leurs développeurs dans un faux sentiment de sécurité.

Lorsque vous envisagez le nombre de problèmes pouvant survenir sur un site Web, faire preuve de paresse en matière de conformité ne fait qu'ajouter de nouveaux problèmes à votre charge de travail.

EDIT: après avoir relu votre message original, je remarque que vous dites que vous ne vous souciez pas de la conformité lorsque vous travaillez sur un prototype, puis vous continuez en affirmant que vous utilisez habituellement le prototype en production - cela signifie que ce n'est pas le cas. strictement un prototype, mais un candidat. Dans de telles circonstances, la situation normale est qu’une fois que le client a accepté un candidat, aucun délai n’est alloué pour la correction des bogues, ce qui renforce l’argument en faveur de la conformité du balisage.

Si vous ne recevrez pas de temps plus tard, faites-le maintenant.

Si on vous donne du temps plus tard, vous avez quand même le temps de le faire.

Si vous souhaitez que votre vision soit accessible aux personnes handicapées et non handicapées, ainsi qu'aux systèmes externes, vous devez absolument vous assurer de générer du code HTML valide.

Il est facile de tester votre code HTML avec les validateurs automatiques .

Je vais ajouter à ce que Mike Edwards a dit sur les ramifications juridiques et vous rappeler que vous avez également une obligation morale:)

Pourquoi ne pas écrire le prototype en (X) HTML valide en premier lieu? J'ai jamais trouvé que cela représentait plus un effort que d'utiliser un code HTML invalide. Produire du XHTML valide devrait être une tâche triviale. (D'autre part, produire du XHTML sémantiquement significatif pourrait être plus contraignant.)

En bref, je ne vois aucun avantage à utiliser du code HTML non valide pour les prototypes.

Honnêtement, je ne sais pas pourquoi il est un effort supplémentaire de faire du HTML basé sur des standards. Ce n'est pas comme si c'était difficile et vous devriez le faire par souci de professionnalisme.

Si vous avez payé quelqu'un pour vous construire une maison et qu'il se démarque par paresse, que vous n'aviez pas remarqué à l'époque, mais que dans 10 ans des fissures sont apparues sur vos murs, seriez-vous heureux?

HTML valide juste pour pouvoir avoir un badge sur votre site - non.

Avoir " HTML valide " au sens de "HTML qui fonctionne sur tous les principaux navigateurs ou moteurs de navigateur". - oui.

Absolument. Un code non valide peut entraîner toutes sortes de comportements étranges et des erreurs qui ne masquent pas celles qui se produisent lorsque vous obtenez un rapport de validation.

Exemple:

Un fond jaune débordait de la liste de messages et de l'en-tête de la liste suivante, mais uniquement dans Internet Explorer.

Pourquoi? L’arrière-plan a été appliqué à un élément de la liste, mais la personne qui a écrit la page l’a écrite sous forme de liste unique avec un en-tête au milieu. Les titres ne sont pas autorisés entre les éléments de la liste et différents navigateurs ont tenté de les récupérer de différentes manières. Internet Explorer a terminé l'élément de la liste (avec la couleur d'arrière-plan) lorsqu'il a vu le début de l'élément suivant (après le titre), tandis que les autres navigateurs l'ont terminé lorsqu'il a vu la balise de fin du premier élément de la liste.

C’était la seule erreur de validité de la page. Il n’a donc fallu que quelques minutes pour localiser le problème et le résoudre.

Parce que, si vous vous en tenez aux normes, votre travail sera compatible à l'avenir. Les agents d'utilisateur s'efforceront d'atteindre la conformité standard et le mode de non-conformité de leurs bizarreries sera toujours sujet à modification. C'est comme ça qu'on est censé être.

À moins que vous ne vous intéressiez à la perpétuation des normes IE8 qu’ils souhaitent activer par défaut. - c'est un autre argument.
Kit Web, Gecko, Presto? (est-ce le moteur de cet opéra?), et les autres deviendront toujours plus conformes à chaque sortie.

À moins que votre travail HTML ne se trouve dans un contrôle de navigateur intégré IE, il n’ya vraiment aucune raison de générer du code HTML valide tant qu’il restitue.

À mon avis, le critère clé est "adapté à l'objectif". - Si vos clients veulent quelque chose pour un petit marché / marché intérieur (et ne se soucient pas de savoir si cela aliène des clients potentiels qui ont une déficience ou utilisent des navigateurs moins communs), alors c'est leur choix.

Dans le même temps, je pense qu'il est de notre responsabilité (en tant que développeurs) de nous assurer qu'ils connaissent les implications de leurs décisions - Certaines organisations seront tenues par la loi à ce que les sites Web soient utilisables par des lecteurs d'écran, ce qui signifie généralement un code HTML conforme aux normes. .

Je pense que créer des sorties HTML valides ne nuira pas autant à votre temps de développement si vous vous êtes entraîné au code html valide dès le début. Pour la première personne, ce n'est pas si difficile de savoir quelles balises ne sont pas autorisées dans un élément
et les attributs requis dans une balise sont parfois ceux dont vous auriez vraiment besoin de toute façon - je crois que ce sont les principaux erreurs qui rendent votre code html invalide, alors pourquoi ne pas simplement les apprendre dès maintenant si vous prévoyez de rester sur le Web pour longtemps?

Il existe deux règles pour écrire des sites Web:

  1. Le site doit fonctionner pour vos utilisateurs.
  2. Le site doit fonctionner pour vos utilisateurs.

Pour respecter la première règle, vous devez coder de manière à ce que votre site s'affiche correctement lors de l'utilisation d'Internet Explorer. Sauf si vous êtes libre de modifier la conception de votre site afin de n'utiliser que les fonctionnalités rendues correctement par IE, cela signifie que vous écrivez du HTML non valide.

Pour respecter la seconde règle, vous devez coder de manière à ce que votre site s'affiche correctement lors de l'utilisation de lecteurs d'écran et d'écrans braille. Bien que certains nouveaux lecteurs d'écran puissent fonctionner avec des sites ciblés par IE, cela signifie en général écrire du code HTML valide.

Si vous travaillez sur un petit projet ou si vous faites partie d'une grande équipe, vous pouvez coder un site qui génère du code HTML ciblé par IE pour IE, et valide le code HTML sinon. Mais si vous prenez vous-même un projet de moyenne à grande envergure, vous devez décider quelle règle vous allez suivre et laquelle vous allez ignorer.

MISE À JOUR:

Cela est rejeté par les utilisateurs qui pensent que vous pouvez toujours vous échapper avec un code HTML valide dans IE. Cela peut être vrai si vous avez la possibilité de modifier votre conception pour pallier les faiblesses d’IE, mais si un client vous a confié une conception et que vous devez la faire fonctionner, vous devrez peut-être recourir à un code HTML invalide. C’est triste, mais c’est vrai, quoi qu’ils en pensent.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top