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

38

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é?

Shubham
la source
7
Vous trouverez peut-être un article intéressant sur Joels, Martian Headsets . La RFC 793: Robustness Principle , qui stipule explicitement que les implémentations TCP doivent faire de leur mieux pour analyser les ordures, mérite également d’être signalée. Ce principe a depuis été appliqué aux navigateurs.
Brian
25
@ Brian: La robustesse signifie que vous ne devriez pas tomber lorsque vous recevez de la merde. Cela ne signifie pas que vous devez donner un sens à la merde.
Marjan Venema
2
XHTML utilise une analyse syntaxique stricte.
user16764
3
Est-ce juste moi, ou aucune de ces réponses n'est-elle très satisfaisante?
Gsingh2011
2
@ gsingh2011 Aucune des réponses ne satisfait, mais ma réponse est la vérité. Certains d'entre nous étaient actifs sur le net il y a très longtemps :-) Mais oui, c'est étonnant de voir combien de bric-à-brac nous reste pour des raisons aussi simples.
Ross Patterson

Réponses:

39

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é!

Ross Patterson
la source
7
+1 oui, c'est comme ça que tout a commencé, dans vi ou notepad. Avec la plupart des pages copiées à partir de mauvais exemple de code, cela ne s’est jamais amélioré. De plus, le WWW a explosé, de sorte que toute personne capable de taper est devenue un développeur Web et il s’agissait simplement d’obtenir des résultats rapides.
jqa
1
Apparemment, cette réponse en conjonction avec le commentaire de @ Jukka donne la meilleure explication possible
Shubham
35

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.

tdammers
la source
7
Eh bien, je ne pense pas que quiconque utiliserait du HTML qui génère des erreurs. POURQUOI pensez-vous qu'un compilateur supposant du code est différent d'un navigateur utilisant du HTML?
Shubham
1
Je suis d’accord avec Shubham: "puisque nous traitons avec des contributions d’une source sur laquelle nous n’avons aucune influence", c’est faux, l’influence est indirecte, mais certains sites Web continuent de supporter IE6 en raison de cette influence.
Steve314
2
@Shubham: Un compilateur est différent car son objectif n'est pas de transformer le code source lisible par une machine en une forme assimilable par l'homme, mais bien de transformer un code source lisible par l'homme en quelque chose de plus pratique pour un ordinateur (code machine ou quelque chose d'intermédiaire). format). Avec le compilateur, vous corrigez l’entrée et vous êtes heureux que le code n’ait pas été transformé en production. Avec le navigateur, vous maudissez le fabricant du navigateur ou l'auteur du site Web, mais dans les deux cas, vous ne pouvez pas voir la page.
tdammers
2
@ Shubham: Généralement, l'utilisateur d'un compilateur aura le contrôle sur le code source en cours de compilation. Ce n'est généralement pas le cas avec les pages Web.
Supercat
17

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.

Jukka K. Korpela
la source
15
HTML authors and authoring tools produce crappy markup.- Ils le font parce que les navigateurs l'acceptent. Si, depuis le début, les navigateurs ne l'acceptaient pas, ces outils et leurs auteurs n'auraient pas été en mesure de produire du balisage de
mauvaise qualité
3
@GrandmasterB - Je pense que vous ratez le problème. Même s'il n'y avait qu'un seul navigateur sur le marché, l'analyse syntaxique n'était pas stricte.
user93353
3
Note amusante: vous dites que si un navigateur est incapable d'analyser un site invalide, il perdra des parts de marché. Mais il suffit de regarder, c’est-à-dire que si grave soit-il, il ne perd pas de part de marché. Cela oblige simplement les développeurs pauvres à écrire des hacks sales en utilisant de vieilles API ... Et ne me lancez pas sur son schéma de version ...
Max
3
Au début, les navigateurs étaient écrits à la hâte pour traiter avec un langage de balisage non finalisé et dépourvu de spécification officielle - il n’existait pas de règles d’analyse syntaxique strictes. (HTML 2.0, en 1995, était nominalement basé sur SGML, mais il était trop tard pour que cela soit réellement mis en œuvre.)
Jukka K. Korpela Le
2
IE a en réalité perdu une grande partie de sa part de marché. Mais cela n'a probablement rien à voir avec une analyse stricte. IE, avec ses bizarreries, a jugé le Web assez longtemps pour obliger les autres navigateurs à imiter en grande partie ses bizarreries, car tant de pages tomberaient en morceaux.
Jukka K. Korpela
9

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.

Jessica Brown
la source
La syntaxe HTML était en effet basée sur la syntaxe concrète de référence SGML pour la forme de son balisage. Mais SGML n’avait pas d’ éléments de balisage que HTML pourrait emprunter. Le jeu d’éléments HTML ressemble en réalité à celui du langage de balisage de document GML d’ IBM , translittéré dans le RCS SGML.
Ross Patterson
5

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.

monstre à cliquet
la source
6
Même avant qu'IE n'arrive sur le marché, Netscape n'a jamais procédé à une analyse syntaxique stricte. Je me souviens de Netscape à partir de début 1997.
user93353
Même s'il existait des normes claires, il serait difficile pour un navigateur de faire la distinction entre les balises légitimement définies après la publication du navigateur et les balises qui n'ont jamais été et ne seraient jamais légitimes. Si les balises "facultatives" qui amélioraient un document mais n'étaient pas requises pour son exactitude sémantique incluaient le numéro de version de la norme qui les implémentait, alors un navigateur qui implémenterait la version 23 de la norme pourrait ignorer silencieusement une <o24wowzo>balise mais rester en retrait <o23wowzo>, mais une conception aurait altéré l'aspect "lisible par l'homme" du HTML.
Supercat
2

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

Erik Reppen
la source