D'autres ont répondu «comment» et cité des spécifications. Voici la vraie histoire de "pourquoi non <script/>
", après de nombreuses heures à fouiller dans les rapports de bogues et les listes de diffusion.
HTML 4
HTML 4 est basé sur SGML .
SGML a quelques shorttags , comme <BR//
, <B>text</>
, <B/text/
ou <OL<LI>item</LI</OL>
. XML prend la première forme, redéfinit la fin comme ">" (SGML est flexible), pour qu'il devienne <BR/>
.
Cependant, HTML n'a pas redéfini, donc <SCRIPT/>
devrait signifier <SCRIPT>>
.
(Oui, le «>» doit faire partie du contenu et la balise n'est toujours pas fermée.)
De toute évidence, cela est incompatible avec XHTML et va briser de nombreux sites (les navigateurs temps étaient assez matures pour prendre soin de cette ), de sorte que personne ne shorttags mis en œuvre et la spécification conseille contre eux .
En effet, toutes les balises auto-terminées «en fonctionnement» sont des balises avec une balise de fin interdite sur les analyseurs techniques non conformes et sont en fait invalides. C'est le W3C qui a proposé ce hack pour faciliter la transition vers XHTML en le rendant compatible HTML .
Et <script>
la balise de fin n'est pas interdite .
La balise "auto-terminante" est un hack en HTML 4 et n'a aucun sens.
HTML 5
HTML5 a cinq types de balises et seules les balises 'void' et 'foreign' sont autorisées à se fermer automatiquement .
Parce qu'il <script>
n'est pas nul (il peut avoir du contenu) et n'est pas étranger (comme MathML ou SVG), <script>
ne peut pas être fermé automatiquement, quelle que soit la façon dont vous l'utilisez.
Mais pourquoi? Ne peuvent-ils pas le considérer comme étranger, faire un cas spécial ou quelque chose?
HTML 5 vise à être rétrocompatible avec les implémentations de HTML 4 et XHTML 1. Il n'est pas basé sur SGML ou XML; sa syntaxe concerne principalement la documentation et l'unification des implémentations. (C'est pourquoi <br/>
<hr/>
etc. sont des HTML 5 valides bien qu'HTML4 non valides.)
La fermeture automatique <script>
est l'une des balises où les implémentations différaient. Il travaillait dans Chrome, Safari , et Opera ; à ma connaissance, cela n'a jamais fonctionné dans Internet Explorer ou Firefox.
Cela a été discuté lors de la rédaction de HTML 5 et a été rejeté car il rompt la compatibilité du navigateur . Les pages Web dont la balise de script à fermeture automatique peut ne pas s'afficher correctement (voire pas du tout) dans les anciens navigateurs. Il y avait d' autres propositions , mais elles ne peuvent pas non plus résoudre le problème de compatibilité.
Après la publication du brouillon, WebKit a mis à jour l'analyseur pour qu'il soit conforme.
La fermeture automatique <script>
ne se produit pas dans HTML 5 en raison de la compatibilité descendante avec HTML 4 et XHTML 1.
XHTML 1 / XHTML 5
Lorsqu'il est réellement utilisé en tant que XHTML, il <script/>
est vraiment fermé, comme l' ont indiqué d' autres réponses .
Sauf que la spécification dit qu'elle aurait dû fonctionner lorsqu'elle a été servie en HTML:
Les documents XHTML ... peuvent être étiquetés avec le type de média Internet "text / html" [RFC2854], car ils sont compatibles avec la plupart des navigateurs HTML.
Alors, qu'est-ce-qu'il s'est passé?
Les gens ont demandé à Mozilla de laisser Firefox analyser les documents conformes au format XHTML indépendamment de l'en-tête de contenu spécifié (connu sous le nom de reniflage de contenu ). Cela aurait permis des scripts à fermeture automatique, et le reniflage de contenu était de toute façon nécessaire parce que les hébergeurs Web n'étaient pas suffisamment matures pour servir l'en-tête correct; IE était bon dans ce domaine .
Si la première guerre des navigateurs ne s'est pas terminée avec IE 6, il se peut que XHTML soit également sur la liste. Mais cela a fini. Et IE 6 a un problème avec XHTML. En fait , IE ne prend pas en charge le type MIME correct du tout , ce qui oblige tout le monde à utiliser text/html
pour XHTML parce que IE a tenu majeure part de marché pendant toute une décennie.
Et le reniflage de contenu peut également être très mauvais et les gens disent qu'il devrait être arrêté .
Enfin, il s'avère que le W3C ne signifiait pas que le XHTML était sniffable : le document est à la fois HTML et XHTML, et des Content-Type
règles. On peut dire qu'ils étaient fermes sur "suivez simplement nos spécifications" et ignoraient ce qui était pratique . Une erreur qui s'est poursuivie dans les versions XHTML ultérieures.
Quoi qu'il en soit, cette décision a réglé la question pour Firefox. C'était 7 ans avant la naissance de Chrome ; il n'y avait pas d'autre navigateur significatif. Ainsi fut-il décidé.
La spécification du doctype seul ne déclenche pas l'analyse XML en raison des spécifications suivantes.