La validation HTML 5 vaudra-t-elle la chandelle?

StackOverflow https://stackoverflow.com/questions/432933

  •  10-07-2019
  •  | 
  •  

Question

Il est largement admis que la meilleure raison de valider son code HTML est de s’assurer que tous les navigateurs le traiteront de manière cohérente et prévisible.

Le brouillon HTML 5 contient toutefois deux spécifications en une. Tout d’abord, une spécification d’auteur, décrivant les éléments et les attributs que les auteurs HTML doivent utiliser, ainsi que leurs relations réciproques. La validation d'une page HTML 5 est basée sur cette spécification. Les éléments et attributs inclus ne sont pas directement tirés de HTML 4, mais doivent être justifiés à partir des principes de base, ce qui signifie que certaines fonctionnalités de HTML 4, telles que l'attribut summary de & Lt; table & Gt ;, longdesc sur < img > et l'attribut profile sur < head > ;, n'apparaissent pas actuellement dans ce brouillon. Ces fonctionnalités ne sont pas considérées comme obsolètes, elles ne sont tout simplement pas incluses. (Leur absence dans le projet reste controversée, bien que leur inclusion dans un avenir proche ne semble pas probable.)

Deuxièmement, le brouillon définit une spécification de traitement du navigateur qui cherche à définir exactement comment l’analyseur du navigateur traitera tout flux d’octets qui lui est attribué, quel que soit le niveau de forme et de validité du code HTML. Cela signifie que lorsque les navigateurs prendront pleinement en charge HTML 5, il sera possible de prédire comment n'importe quel navigateur traitera HTML pour une gamme d'entrées beaucoup plus large que celles simplement validées.

En particulier, comme HTML 5 est défini comme compatible à 100% avec le Web actuel, tous les codes HTML 4 valides et toutes les balises non valides mais couramment utilisées continueront à être traités exactement de la même manière qu'aujourd'hui, peu importe de savoir si HTML 5 est valide ou non.

Par conséquent, à tout le moins, quiconque utilise une fonctionnalité de HTML 5, HTML 4 ou une version antérieure de HTML, ainsi que de nombreuses extensions propriétaires, peut être assuré que son code HTML bénéficiera d'un traitement cohérent et prévisible sur tous les navigateurs.

Dans ces conditions, est-il judicieux de limiter le code HTML 5 à celui qui valide, et quels avantages concrets en retirerons-nous?

Était-ce utile?

La solution

  • Tout d'abord, & # 8217; s la couche de validité correspondant à & # 8220; erreurs d'analyse & # 8221; dans l ' algorithme d'analyse en HTML5 . Cette couche est similaire au XML bien formé. La principale raison d'éviter les erreurs dans vos documents sur cette couche est que vous pouvez obtenir un arbre d'analyse surprenant. Si votre document ne contient aucune erreur sur cette couche, vous aurez moins de surprises à déboguer lors de l’écriture de fichiers JS ou CSS fonctionnant avec le DOM.
  • En tant que cas particulier de la couche susmentionnée, & # 8217; est le doctype HTML5: <!DOCTYPE html>. La raison pour laquelle on voudrait se conformer ici est d’obtenir le mode standard de la manière la plus simple possible. C’est quelque chose que vous pouvez mémoriser contrairement aux doctypes HTML 4.01 ou XHTML 1.0 que vous devez rechercher, copier-coller à chaque fois. Bien entendu, si vous & # 8217; souhaitez utiliser le mode standard, vous avez moins de surprises sur le calque CSS.
  • La raison principale pour laquelle la validation sur la couche supérieure à l'algorithme d'analyse est importante tient à votre typographie afin que vous passiez moins de temps à déboguer, votre page ne fonctionnant pas & # 8217; ne fonctionnant pas comme prévu.
  • Le point précédent n'explique pas pourquoi vous devez vous préoccuper de la validation lorsqu'un élément ou attribut donné que vous n'avez pas mal orthographié est pris en charge par les navigateurs comme un héritage, mais que les spécifications HTML5 l'évitent toujours. Voici & # 8217; pourquoi HTML5 a une syntaxe obsolète comme celle-ci:
    • HTML5 utilise obsoletion pour signaler aux auteurs que certaines fonctionnalités sont une perte de temps. Ceux-ci incluent longdesc, summary et profile. (Notez que les utilisateurs ne sont pas d’accord sur le point de savoir si ces pertes de temps sont une perte de temps, mais dans leur libellé actuel, HTML5 les rend obsolètes.) En d’autres termes, si vous disposez de ressources limitées pour améliorer l’accessibilité, vous ferez mieux de dépenser vos ressources limitées dans < => et <font>. Si vous avez des ressources limitées pour la pureté sémantique, vous feriez mieux de dépenser vos ressources pour autre chose que de vous assurer que vous avez la bonne incantation dans <applet>.
    • HTML5 rend obsolètes certaines fonctionnalités de présentation pouvant être dupliquées en CSS pour aider les auteurs à utiliser CSS pour leur propre bien. De cette façon, les auteurs qui & # 8217; ne considèrent pas la maintenabilité de leur propre chef sont supposés être guidés vers un code plus facile à gérer. Personnellement, je & # 8217; Je préférerais que le contenu de présentation reste cohérent et que les auteurs eux-mêmes décident de la méthode qui leur convient le mieux.
    • Certaines choses sont obsolètes pour des raisons politiques. L'élément classid est obsolète, car le rendre conforme inciterait les anti-<object> standardistes à penser que les utilisateurs de HTML5 sont devenus fous, ce qui pourrait entraîner de mauvaises relations publiques. name est obsolète principalement par principe de ne pas attribuer de balises spéciales à un plug-in en particulier. L'attribut <a> sur language est obsolète, car il & # 8217; est en pratique spécifique à ActiveX.
    • Certaines choses sont obsolètes pour des raisons esthétiques. Ceci inclut l'attribut <script> sur <=> et l'attribut <=> sur <=>.

(Je développe le validateur Validator.nu HTML5, qui est également le moteur de validation HTML5 utilisé par le validateur W3C.)

Autres conseils

  

Dans ces conditions, est-il judicieux de limiter le code HTML 5 à celui qui valide, et quels avantages concrets en retirerons-nous?

Oui, bien sûr. Vous oubliez que l'avenir n'est pas fixe. En particulier, vous supposez implicitement que les spécifications HTML 5 ne changeront jamais et ne déprécierez jamais aucune fonctionnalité. Ceci, bien sûr, ne fait que cimenter le statu quo. Il est définitivement souhaitable de supprimer le support de certaines fonctionnalités à long terme, afin de faciliter la mise en place de nouveaux développements (en particulier s'ils pourraient se contredire).

Il peut ne pas y avoir d’avantage immédiat à produire du code HTML 5 valide (sauf que cela reste facilite la validation et donc le développement). Toutefois, la qualité de la plupart des sites Web peut présenter un avantage à long terme, car elle facilite beaucoup le dépassement des technologies et normes actuelles.

La validation n'a jamais vraiment consisté à obtenir des résultats cohérents sur tous les navigateurs, même avant le début de HTML5. C’est un mythe propagé par ceux qui ne comprennent pas ce dont ils parlent, même s’ils pensent le faire.

La véritable raison de la validation est et a toujours été une simple question d’assurance qualité. C'est juste un moyen de détecter les erreurs, qui. Même si les résultats pour une erreur donnée peuvent être, ou vont bientôt devenir, cohérents entre les navigateurs, il est toujours possible que le résultat lui-même ne soit pas tel que prévu.

Il est important que les auteurs puissent détecter les erreurs dans leur code, car un balisage plus propre et sans erreur est plus facile à utiliser et à entretenir, en particulier dans un environnement d'équipe. Bien que la plupart des erreurs individuelles puissent être bénignes et ne pas causer de problèmes majeurs, certaines peuvent donner des résultats inattendus. par exemple. De manière incorrecte, des éléments qui se chevauchent ou qui ne se chevauchent pas peuvent provoquer des problèmes de disposition inattendus dans certains cas, et le fait de laisser un validateur vous dire où est l'erreur, aide à corriger le problème. Mais si les résultats sont remplis de dizaines d’erreurs bénignes, la détection et le traitement risquent d’être plus difficiles qu’il ne le faut.

C’est en effet l’un de mes problèmes avec HTML5. Inutile de définir un sous-ensemble de flux comme étant «valide» si un navigateur doit gérer tous les flux de la même manière. Les temps passés sur la liste du WHATWG à débattre des mécanismes de repli constituent une perte de temps considérable, surtout lorsque XML aurait déjà dû résoudre tous les problèmes d'analyse.

Cela aurait été une idée utile de produire un document sur les meilleures pratiques en matière d'analyse de documents non valides hérités, mais cela ne fait pas partie d'un standard Web, il s'agit simplement d'un autre ingrédient pour compliquer encore plus les choses en HTML5, qui ne peut pas décider si il veut codifier un comportement existant (comme HTML 3.2), redéfinir une plate-forme plus propre (comme HTML 3.0 essayé) ou ajouter de nouvelles extensions au coup par coup.

Quoi qu'il en soit, la question risque d'être mal placée car il n'y aura jamais de navigateur qui & "prend pleinement en charge HTML5 &"; Il y en a bien trop, beaucoup trop: les fabricants de navigateurs ne pouvaient pas implémenter absolument tout, même s'ils le voulaient, ce que Microsoft au moins ne fait pas explicitement. Au lieu de cela, il est évident que les fonctionnalités utiles seront choisies par le fournisseur et rencontrera un large public.

HTML5 n'est pas une spécification HTML cohérente, c'est la recette tentaculaire, illisible et inachevée de Hixie pour tout ce qu'il pense qu'un navigateur Web devrait faire. Ça va échouer. Et l'approche alternative de W3, XHTML2, a déjà échoué. Il n'y a pas de direction future cohérente pour les standards Web. Nous avons lâché la balle.

C'est une bonne question.

Le but principal de la validation (pour moi du moins) est de m'aider à détecter les erreurs dans mon balisage et à me fournir une bonne base sur laquelle construire lorsque je teste des pages dans différents navigateurs. si le balisage est valide et que la page est bouchée dans IE6, il s'agit d'un problème lié à IE6.

Le fait que les navigateurs doivent tous se comporter de manière prévisible même si votre balisage comprend un HTML5 techniquement non valide, tel qu'un résumé de tableau ou une clé d'accès ancre, trouble quelque peu les eaux.

En règle générale, je souhaite toujours que mes pages soient validées, pour la raison susmentionnée. Cependant, si (par exemple) un attribut était supprimé de la spécification HTML5 sans qu'un remplacement apparemment approprié soit ajouté, je pourrais être enclin à continuer à utiliser l'attribut obsolète ou obsolète et à accepter les erreurs de validation.

Comme toujours, je pense qu'il est important de connaître votre métier.

Si vous savez ce que vous faites et avez pris la décision consciente de créer une page qui ne soit pas validée pour des raisons valables, ce n'est pas un problème. Si vous écrivez juste un code qui ne valide pas parce que vous ne connaissez pas mieux, c'est une autre affaire.

Stephen

mainteneur du validateur HTML5 du W3C ici. J'ai récemment écrit un court & # 8220; Pourquoi valider? & # 8221; section pour le & # 8220; à propos de & # 8221; section du validateur HTML5:

http://validator.w3.org/nu/about.html# pourquoi valider

La source du texte de cette section est la suivante:

https://github.com/validator/ validateur / blob / master / site / nu-about.html # L160

Et les requêtes avec les améliorations / ajouts suggérés sont les bienvenues.

Ce que j’ai là actuellement est la suivante:

  

La raison principale pour exécuter vos documents HTML via une conformité   checker est simple: pour détecter les erreurs non intentionnelles & # 8212;   ont autrement manqué & # 8212; afin que vous puissiez les réparer.

     

Au-delà, certaines exigences de conformité des documents (règles de validité)   dans la spécification HTML sont là pour vous aider et les utilisateurs de vos documents   éviter certains types de problèmes potentiels. Expliquer la raison   derrière ces exigences, la spécification HTML contient ces deux sections:

           

Pour résumer ce que & # 8217; est indiqué dans ces deux sections:

     
      
  • Certains cas de marquage sont définis comme des erreurs car ils sont   problèmes potentiels d'accessibilité, de convivialité, d'interopérabilité,   sécurité, ou facilité de maintenance & # 8212; ou parce qu’elles peuvent entraîner de mauvaises   performances, ou qui pourraient entraîner l’échec de vos scripts de manière   difficile à résoudre.
    •   
  • Parallèlement à ceux-ci, certains cas de balisage sont définis   comme des erreurs, car ils peuvent vous amener à rencontrer des problèmes potentiels   Comportement d'analyse et de traitement des erreurs HTML & # 8212; de sorte que, disons, vous & # 8217; d se retrouvent   avec un résultat inattendu et inattendu dans le DOM.
    •   
     

La validation de vos documents vous avertit de ces problèmes potentiels.

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