Pourquoi les éléments de script à fermeture automatique ne fonctionnent-ils pas?

Quelle est la raison pour laquelle les navigateurs ne reconnaissent pas correctement:

<script src="foobar.js" /> <!-- self-closing script element -->

Seul cela est reconnu:

<script src="foobar.js"></script>

Cela brise-t-il le concept de prise en charge XHTML?

Remarque: Cette déclaration est correcte au moins pour tous les IE (6-8 beta 2).

La spécification XHTML 1 dit:

С.3. Minimisation des éléments et contenu des éléments vides

Étant donné une instance vide d'un élément dont le modèle de contenu n'est pas EMPTY(par exemple, un titre ou un paragraphe vide), n'utilisez pas la forme minimisée (par exemple, use <p> </p>and not <p />).

La DTD XHTML spécifie les éléments de script comme suit:

<!-- script statements, which may include CDATA sections -->
<!ELEMENT script (#PCDATA)>

Pour ajouter à ce que Brad et squadette ont dit, la syntaxe XML à fermeture automatique est<script /> en fait du XML correct, mais pour que cela fonctionne dans la pratique, votre serveur Web doit également envoyer vos documents en XML correctement formé avec un type de mime XML comme application/xhtml+xmldans le HTTP En-tête Content-Type (et non as text/html).

Cependant, l'envoi d'un type mime XML empêchera l'analyse de vos pages par IE7, qui n'aime que cela text/html.

De w3 :

En résumé, 'application / xhtml + xml' DEVRAIT être utilisé pour les documents de la famille XHTML, et l'utilisation de 'text / html' DEVRAIT être limitée aux documents XHTML 1.0 compatibles HTML. 'application / xml' et 'text / xml' PEUVENT également être utilisés, mais chaque fois que cela est approprié, 'application / xhtml + xml' DEVRAIT être utilisé plutôt que ces types de supports XML génériques.

Je me suis posé la question il y a quelques mois, et la seule solution réalisable (compatible avec FF3 + et IE7) était d'utiliser l'ancienne <script></script>syntaxe avec text/html(syntaxe HTML + type MIME HTML).

Si votre serveur envoie le text/htmltype dans ses en-têtes HTTP, même avec des documents XHTML autrement correctement formés, FF3 + utilisera son mode de rendu HTML ce qui signifie que <script />cela ne fonctionnera pas (ceci est un changement, Firefox était auparavant moins strict).

Cela se produira indépendamment de toute manipulation des http-equivméta-éléments, du prologue ou du doctype XML à l'intérieur de votre document - Firefox se branche une fois qu'il obtient l'en- text/htmltête, qui détermine si l'analyseur HTML ou XML regarde à l'intérieur du document, et l'analyseur HTML ne comprend pas <script />.

Au cas où quelqu'un serait curieux, la raison ultime est que HTML était à l'origine un dialecte de SGML, qui est le frère aîné étrange de XML. Dans SGML-land, les éléments peuvent être spécifiés dans la DTD comme à fermeture automatique (par exemple BR, HR, INPUT), implicitement fermables (par exemple P, LI, TD) ou explicitement fermables (par exemple TABLE, DIV, SCRIPT). XML, bien sûr, n'a aucune idée de cela.

Les analyseurs tag-soup utilisés par les navigateurs modernes ont évolué à partir de cet héritage, bien que leur modèle d'analyse ne soit plus pur SGML. Et bien sûr, votre XHTML soigneusement conçu est traité comme une soupe de balises d'inspiration SGML mal écrite, sauf si vous l'envoyez avec un type mime XML. C'est aussi pourquoi ...

<p><div>hello</div></p>

... est interprété par le navigateur comme:

<p></p><div>hello</div><p></p>

... qui est la recette d'un joli bug obscur qui peut vous mettre en crise lorsque vous essayez de coder contre le DOM.

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/htmlpour 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-Typerè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.

Internet Explorer 8 et versions antérieures ne prennent pas en charge l'analyse XHTML. Même si vous utilisez une déclaration XML et / ou un doctype XHTML, l'ancien IE analyse toujours le document en HTML simple. Et en clair HTML, la syntaxe à fermeture automatique n'est pas prise en charge. La barre oblique de fin est simplement ignorée, vous devez utiliser une balise de fermeture explicite.

Même les navigateurs prenant en charge l'analyse XHTML, tels qu'IE 9 et versions ultérieures , analyseront toujours le document au format HTML, sauf si vous le diffusez avec un type de contenu XML. Mais dans ce cas, l'ancien IE n'affichera pas du tout le document!

Les personnes ci-dessus ont déjà à peu près expliqué le problème, mais une chose qui pourrait clarifier les choses est que, bien que les gens utilisent <br/>et tels tout le temps dans les documents HTML, tout /dans une telle position est fondamentalement ignoré, et uniquement utilisé lorsque vous essayez de faire quelque chose à la fois analysable en XML et HTML. Essayez <p/>foo</p>, par exemple, et vous obtenez un paragraphe régulier.

La balise de script à fermeture automatique ne fonctionnera pas, car la balise de script peut contenir du code en ligne, et HTML n'est pas assez intelligent pour activer ou désactiver cette fonctionnalité en fonction de la présence d'un attribut.

D'un autre côté, HTML a une excellente balise pour inclure des références à des ressources externes: la <link>balise, et elle peut se fermer automatiquement. Il est déjà utilisé pour inclure des feuilles de style, des flux RSS et Atom, des URI canoniques et toutes sortes d'autres goodies. Pourquoi pas JavaScript?

Si vous voulez que la balise de script soit incluse, vous ne pouvez pas le faire comme je l'ai dit, mais il existe une alternative, mais pas intelligente. Vous pouvez utiliser la balise de lien à fermeture automatique et le lien vers votre JavaScript en lui donnant un type de texte / javascript et rel comme script, quelque chose comme ci-dessous:

<link type="text/javascript" rel ="script" href="/path/tp/javascript" />

Contrairement à XML et XHTML, HTML n'a aucune connaissance de la syntaxe à fermeture automatique. Les navigateurs qui interprètent XHTML comme HTML ne savent pas que le /caractère indique que la balise doit se fermer automatiquement; au lieu de cela, ils l'interprètent comme un attribut vide et l'analyseur pense toujours que la balise est «ouverte».

Tout comme <script defer>est traité comme <script defer="defer">, <script />est traité comme <script /="/">.

Internet Explorer 8 et plus ne supportent pas le type MIME approprié pour XHTML, application/xhtml+xml. Si vous utilisez XHTML as text/html, ce que vous devez faire pour que ces anciennes versions d'Internet Explorer fassent quoi que ce soit, il sera interprété comme HTML 4.01. Vous ne pouvez utiliser la syntaxe courte qu'avec n'importe quel élément permettant d'omettre la balise de fermeture. Voir la spécification HTML 4.01 .

La «forme courte» XML est interprétée comme un attribut nommé /, qui (parce qu'il n'y a pas de signe égal) est interprété comme ayant une valeur implicite de «/». C'est strictement faux en HTML 4.01 - les attributs non déclarés ne sont pas autorisés - mais les navigateurs l'ignoreront.

IE9 et versions ultérieures prennent en charge XHTML 5 avec application/xhtml+xml.

C'est parce que SCRIPT TAG n'est pas un élément vide.

Dans un document HTML - LES ÉLÉMENTS NULS ne besoin d'une "balise de fermeture"!

En xhtml , tout est générique, donc ils ont tous besoin d'une terminaison, par exemple une "balise de fermeture"; Y compris br, un simple saut de ligne, comme <br></br>ou sa sténographie <br /> .

Cependant, un élément de script n'est jamais un élément vide ou paramétrique, car la balise de script avant toute chose est une instruction de navigateur et non une déclaration de description de données.

Principalement, une instruction de terminaison sémantique, par exemple, une "balise de fermeture" n'est nécessaire que pour traiter des instructions dont la sémantique ne peut pas être terminée par une balise suivante. Par exemple:

<H1>la sémantique ne peut pas être terminée par un suivant <P>car elle ne contient pas suffisamment de sa propre sémantique pour remplacer et donc terminer le jeu d'instructions H1 précédent. Bien qu'il puisse diviser le flux en une nouvelle ligne de paragraphe, il n'est pas "suffisamment fort" pour remplacer la taille de police et la hauteur de ligne de style actuelles qui se déversent dans le flux. , c'est-à-dire qui fuient de H1 (car P ne l'a pas) ).

C'est ainsi et pourquoi la signalisation "/" (terminaison) a été inventée.

Une balise de terminaison générique sans description comme < />, aurait suffi pour toute chute unique de la cascade rencontrée, par exemple: <H1>Title< />mais ce n'est pas toujours le cas, parce que nous voulons également être capables de «s'emboîter», plusieurs balisage intermédiaire du Stream: split en torrents avant de s'enrouler / tomber sur une autre cascade. En conséquence, un terminateur générique tel que < />ne serait pas en mesure de déterminer la cible d'une propriété à terminer. Par exemple: <b>gras <i>gras-italique < /> italique </> normal. Serait sans doute de ne pas obtenir notre droit d'intention et ne plus interpréter probablement comme gras gras-itallic gras normal.

C'est ainsi qu'est née la notion de wrapper, c'est-à-dire de conteneur. (Ces notions sont tellement similaires qu'il est impossible de les discerner et parfois le même élément peut avoir les deux. <H1>Est à la fois wrapper et container en même temps. Alors que <B>seul un wrapper sémantique). Nous aurons besoin d'un conteneur simple et sans sémantique. Et bien sûr, l'invention d'un élément DIV est arrivée.

L'élément DIV est en fait un conteneur 2BR. Bien sûr, l'arrivée de CSS a rendu la situation plus étrange qu'elle ne l'aurait été autrement et a provoqué une grande confusion avec de nombreuses grandes conséquences - indirectement!

Parce qu'avec CSS, vous pouvez facilement remplacer le comportement natif pré et après BR d'un DIV nouvellement inventé, il est souvent appelé «conteneur de ne rien faire». Ce qui est naturellement faux! Les DIV sont des éléments de bloc et coupent nativement la ligne du flux à la fois avant et après la signalisation de fin. Bientôt, le WEB a commencé à souffrir de la page DIV-itis. La plupart d'entre eux le sont toujours.

L'arrivée de CSS avec sa capacité à remplacer et à redéfinir complètement le comportement natif de toute balise HTML, a en quelque sorte réussi à confondre et à brouiller tout le sens de l'existence HTML ...

Soudain, toutes les balises HTML sont apparues comme obsolètes, elles ont été effacées, dépouillées de toute leur signification, identité et finalité d'origine. D'une certaine manière, vous auriez l'impression qu'ils ne sont plus nécessaires. Dire: une seule balise wrapper de conteneur suffirait pour toute la présentation des données. Ajoutez simplement les attributs requis. Pourquoi ne pas avoir des balises significatives à la place; Inventez les noms de balises au fur et à mesure et laissez le CSS s'occuper du reste.

C'est ainsi que le xhtml est né et bien sûr le grand émoussé, payé si cher par les nouveaux arrivants et une vision déformée de ce qui est quoi, et quel est le fichu but de tout cela. Le W3C est passé du World Wide Web à What Wong Wrong, Camarades? !!

Le but du HTML est de diffuser des données significatives au destinataire humain.

Pour fournir des informations.

La partie formelle n'est là que pour aider à la clarté de la livraison de l'information. xhtml ne donne pas la moindre considération à l'information. - Pour lui, l'information est absolument hors de propos.

La chose la plus importante en la matière est de savoir et de pouvoir comprendre que xhtml n'est pas seulement une version de HTML étendu , xhtml est une bête complètement différente; motifs vers le haut; et donc il est sage de les garder séparés.

La différence entre «vrai XHTML», «faux XHTML» et HTML ainsi que l'importance du type MIME envoyé par le serveur avaient déjà été bien décrites ici . Si vous souhaitez l'essayer dès maintenant, voici un simple extrait modifiable avec aperçu en direct, y compris une balise de script auto-fermée pour les navigateurs capables:

div { display: flex; }
div + div {flex-direction: column; }

<div>Mime type: <label><input type="radio" onchange="t.onkeyup()" id="x" checked  name="mime"> application/xhtml+xml</label>
<label><input type="radio" onchange="t.onkeyup()" name="mime"> text/html</label></div>
<div><textarea id="t" rows="4" 
onkeyup="i.src='data:'+(x.checked?'application/xhtml+xml':'text/html')+','+encodeURIComponent(t.value)"
><?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
[<!ENTITY x "true XHTML">]>
<html xmlns="http://www.w3.org/1999/xhtml">
<body>
  <p>
    <span id="greet" swapto="Hello">Hell, NO :(</span> &x;.
    <script src="data:text/javascript,(g=document.getElementById('greet')).innerText=g.getAttribute('swapto')" />
    Nice to meet you!
    <!-- 
      Previous text node and all further content falls into SCRIPT element content in text/html mode, so is not rendered. Because no end script tag is found, no script runs in text/html
    -->
  </p>
</body>
</html></textarea>

<iframe id="i" height="80"></iframe>

<script>t.onkeyup()</script>
</div>

Vous devriez voir Hello, true XHTML. Nice to meet you!ci - dessous la zone de texte.

Pour les navigateurs incapables, vous pouvez copier le contenu de la zone de texte et l'enregistrer sous forme de fichier avec .xhtml(ou .xht) l'extension ( merci Alek pour cet indice ).

La réponse est simplement moderne parce que la balise est indiquée comme obligatoire de cette façon

Omission de balise Aucune, les balises de début et de fin sont obligatoires.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script