Pourquoi l'analyse stricte n'a-t-elle pas été choisie pour HTML?

Je me suis souvent demandé pourquoi l'analyse syntaxique stricte n'avait pas été choisie lors de la création de HTML. Pendant la majeure partie de l’histoire d’Internet, les navigateurs ont accepté tous les types de balises et ont fait de leur mieux pour les analyser. Le processus dégrade les performances, permet aux utilisateurs d'écrire du charabia et rend difficile la suppression des fonctionnalités obsolètes.

Existe-t-il une raison spécifique pour laquelle HTML n'est pas strictement analysé?

La raison en est simple: à l'époque des premiers navigateurs graphiques, NCSA Mosiac et plus tard Netscape Navigator, presque tout le HTML était écrit à la main. Les auteurs du navigateur (Netscape a été construit par des anciens de Mosaic) ont rapidement reconnu que le refus de restituer du code HTML incorrect leur serait reproché par les utilisateurs, et le tour est joué!

Parce que faire des suppositions est la bonne chose à faire, du point de vue du fabricant du navigateur. Considérez la situation: idéalement, le code HTML que vous recevez est tout à fait correct et conforme aux spécifications. C'est génial. Mais la partie intéressante est ce qui se passe lorsque le code HTML n’est pas correct; étant donné que nous traitons avec des contributions d’une source sur laquelle nous n’avons aucune influence, nous devons vraiment être préparés à cela. Maintenant, quand cela se produit, que pourrions-nous faire? Nous avons deux options: a) échouer et b) faire de son mieux pour remédier à l'erreur. Si nous échouons, l'utilisateur n'a plus qu'un message d'erreur inutile et ne peut rien y faire car il ne contrôle pas le serveur. Si nous faisons de notre mieux, l'utilisateur a au moins ce que nous pourrions faire de la page, et souvent, la supposition est généralement correcte.

Le seul problème avec cela est lorsque vous avez besoin des messages d'erreur, qui sont généralement dans une situation de développement - vous voulez vous assurer que le code HTML que vous générez est correct, et puisque "fonctionne dans le navigateur X" n'est pas équivalent à "correct", nous ne pouvons pas simplement l'exécuter via un navigateur et voir si cela fonctionne: nous ne pouvons pas faire la différence entre le code HTML correct et le code HTML incorrect que le navigateur a corrigé pour vous. C'est un problème qui peut être résolu cependant; il existe des plugins de navigateur qui signalent des violations des normes, il y a le validateur W3C et beaucoup d'autres outils similaires.

Les auteurs HTML et les outils de création produisent un balisage de mauvaise qualité. Les navigateurs font de leur mieux pour des raisons de concurrence: les navigateurs qui ne parviennent pas à rendre la plupart des pages Web de manière raisonnable seront refusés par les utilisateurs, qui se moqueront de la faute.

C'est assez différent de ce que font les implémentations de langage de programmation. Les compilateurs et interprètes travaillent sur du code qui peut être supposé être écrit par un programmeur, alors que tout le monde et son frère peuvent écrire du HTML avec une formation minimale, ou sans. Le balisage HTML est un code, dans un sens, mais il s’agit de données plutôt que d’instructions de langage de programmation, et la (bonne) tradition du logiciel est d’être tolérante vis-à-vis des données.

XHTML impose en principe des règles d'analyse strictes (XML), de sorte qu'un document XHTML avec un type de contenu XML ne sera affiché que s'il est correctement formé au sens XML - sinon, seule la première erreur sera communiquée à l'utilisateur. Cela n’est jamais devenu populaire dans la création Web - la quasi-totalité du «XHTML» existant est utilisée sous forme de texte / html et traitée comme une soupe de balises traditionnelle d’une manière très libérale, avec quelques nouvelles excentricités.

Bref, HTML était basé sur un autre langage de balisage sans hyperlien appelé SGML, souvent utilisé pour la documentation, les manuels, etc.

Extrait d' un article sur l'histoire du HTML:

Tim avait indiqué que certains des premiers documents HTML étaient basés sur un ancien langage SGML que le CERN utilisait déjà: - Nous avons inclus dans HTML certaines balises du jeu de balises SGML utilisé au CERN et pris en charge au CERN [...] L'analyseur HTML ignorera les balises qu'il ne comprend pas et les attributs qu'il ne comprend pas des balises CERN-SGML .

[...] la plupart des balises HTML anciennes étaient en réalité extraites du langage SGMLGuid du CERN, qui était lui-même une variante de l'AAP (un langage SGML ancien). Par exemple, titre, hn, p, ol, etc., sont apparemment tous tirés de cette langue. Le seul changement radical a été l'ajout du très important lien anchor (), sans lequel le WWW n'aurait pas décollé.

En prenant note de la partie que j'ai mise en gras, ils ont implémenté un sous - ensemble des balises disponibles dans le système SGML avec lequel ils étaient familiers, en ajoutant la nouvelle balise ancre <a> et en choisissant d'ignorer l'une des nombreuses balises qu'ils ont ignorées. Ne vous souciez pas de la raison ou ne souhaitez pas la prendre en charge (comme les balises pour les listes de bibliographie, xmp pour "exemple", la balise "box" pour dessiner un cadre autour d’un bloc de texte, etc.). Le moyen le plus simple de le faire est donc de pardonner le balisage inconnu de l’analyseur et d’ignorer le mieux possible le balisage inconnu, que la cause en soit la mauvaise saisie par l’utilisateur ou le moyen le plus rapide de convertir les documents existants en fichiers. Ce nouveau format HTML consiste à ajouter des hyperliens à des documents SGML existants et à ignorer les balises non prises en charge ou implémentées.

Ceci est en partie un vestige historique de la guerre des navigateurs

IE et NetScape étaient en concurrence pour conquérir le marché et continuaient à publier de nouvelles fonctionnalités qui devenaient de plus en plus "géniales", et étaient obligés d'accepter les pages conçues pour l'autre navigateur.

Cela signifie que le navigateur accepte et ignore les balises inconnues en silence, une fois que les comités ont commencé à participer ... eh bien, vous avez un comité qui conçoit des éléments et, par conséquent, de nombreuses versions (avec certaines spécifications formulées de manière ambiguë) où le navigateur souhaite prendre en charge la plupart des éléments. créer un analyseur distinct pour chaque version serait énorme. Il est donc (relativement) plus facile d’utiliser un seul analyseur avec différents modes.

Pour une autre partie, Netscape et IE voulaient que le HTML soit accessible à l’homme ordinaire (comme c’était la mode à la mode), ce qui signifie essayer de faire ce que l’utilisateur veut faire au lieu de ce qu’il a dit de faire et trébucher sur chaque balise pendante.

Pour aggraver le problème, il existe également plusieurs sites «tutoriels» qui enseignent la mauvaise chose et pensent qu’ils ont raison parce que ce qu’ils enseignent fonctionne.

En fin de compte, cela signifie que si vous créez maintenant un navigateur avec uniquement une analyse HTML stricte, 99% des sites existants ne fonctionneront tout simplement pas.

Eh bien, nous avons essayé d’établir une belle option stricte dans le 000, mais cela n’a pas fonctionné, car les gens qui suivaient aveuglément les "meilleures pratiques" aveuglément, ont blâmé les navigateurs lorsque leur balise incorrecte s’est effondrée en mode strict. Et les éditeurs de navigateurs n'aimaient pas être blâmés.

Ils ont affirmé que c'était parce qu'ils voulaient que le Web soit plus accessible aux non-professionnels, mais personne n'a été empêché d'utiliser HTML 4 dans sa forme la plus clémente.

Cela dit, vous pouvez toujours utiliser HTML5 en tant que XML si vous souhaitez une présentation de style strict. Cela peut être un bon moyen de tirer parti des avantages de la mise en page ou du travail de l’assurance-chômage selon un mode plus strict avant de le transmettre à d’autres personnes qui peuvent le vouloir aussi strictement que possible sans risque réel (à moins de déchirer le doctype parce que ils préfèrent en fait le mode quirks - en 2017 (au moment de cette modification), ils devraient être fusillés. Il est donc toujours en place, mais il faut faire des recherches. Je crois me souvenir qu'il existe certaines mises en garde que nous n'avions pas avec XHTML. N'avancez pas le mot "c'est le seul moyen de bien faire les choses", sinon les twits qui adhèrent à ce genre de propos vont laisser filer l'idée, blâmer à nouveau les internautes et prendre les dents de la seule alternative stricte qui nous reste (édition 2017:

http://mathiasbynens.be/notes/xhtml5