Pourquoi les étiquettes auto-fermantes ne marchent pas?

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

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

seulement ceci est reconnu:

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

est-ce que cela brise le concept de support XHTML?

Note: Cette affirmation est correcte au moins pour toute IE (6-8 beta 2).

1175
demandé sur Darshan Rivka Whittle 2008-09-16 10:52:38
la source

11 ответов

spécification XHTML 1 dit:

С.3. Réduction au minimum 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), ne pas utiliser la forme minimisée (par exemple utiliser <p> </p> et non <p /> ).

XHTML DTD spécifie les balises de script comme suit::

<!-- script statements, which may include CDATA sections -->
<!ELEMENT script (#PCDATA)>
430
répondu squadette 2015-04-21 03:19:50
la source

pour ajouter à ce que Brad et squadette ont dit, la syntaxe d'auto-fermeture XML <script /> en fait est correct XML, mais pour que cela fonctionne dans la pratique, votre serveur Web doit également envoyer vos documents comme XML correctement formé avec un mimetype XML comme application/xhtml+xml dans L'en-tête de type de contenu HTTP (et pas comme text/html ).

cependant, l'envoi D'un mimetype XML fera en sorte que vos pages ne seront pas analysées par IE7, qui n'aime que text/html .

de w3 :

en résumé, 'application / xhtml+xml' Devrait être utilisé pour la famille XHTML les documents, et l'utilisation de 'text/html' Devrait être limité à HTML-compatible XHTML 1.0 documents. "application / xml" et "text / xml" peut également être utilisé, mais le cas échéant, "application / xhtml+xml" doit être utilisé plutôt que ces médias XML génériques type.

cela m'a intrigué il y a quelques mois, et la seule solution possible (compatible avec FF3+ et IE7) était d'utiliser l'ancienne syntaxe <script></script> avec text/html (syntaxe HTML + mimetype HTML).

si votre serveur envoie le type text/html Dans Ses en-têtes HTTP, même avec des documents XHTML correctement formés, FF3+ utilisera son mode de rendu HTML ce qui signifie que <script /> ne fonctionnera pas (c'est un changement, Firefox était auparavant moins strict.)

cela se produira indépendamment de toute manipulation avec les métabalises http-equiv , le prolog ou doctype XML à l'intérieur de votre document -- branches Firefox une fois qu'il obtient l'en-tête text/html , qui détermine si L'analyseur HTML ou XML regarde à l'intérieur du document, et L'analyseur HTML ne comprend pas <script /> .

213
répondu joelhardi 2008-09-16 14:44:28
la source

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é bizarre de XML. Dans SGML-land, les étiquettes peuvent être spécifiées dans la DTD soit comme se fermant automatiquement (par exemple, BR, HR, INPUT), soit comme se fermant implicitement (par exemple, P, LI, TD), soit comme se fermant explicitement (par exemple, TABLE, DIV, SCRIPT). Bien entendu, XML n'en a pas la moindre idée.

les analyseurs d'étiquettes utilisés par les navigateurs modernes ont évolué à partir de cet héritage, bien que leur modèle d'analyse n'est pas SGML pur désormais. Et bien sûr, votre XHTML soigneusement conçu est traité comme une soupe d'étiquettes inspirée de SGML à moins que vous ne l'envoyiez avec un type mime XML. C'est aussi pourquoi...

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

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

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

...qui est la recette pour un joli bug obscur qui peut vous jeter dans les crises que vous essayez de code contre le DOM.

143
répondu greim 2017-12-11 22:48:52
la source

D'autres ont répondu "comment" et cité spec. Voici la vraie histoire de "pourquoi pas <script/> ", après de nombreuses heures à fouiller dans les rapports de bogue et les listes de diffusion.


HTML 4

HTML 4 est basé sur SGML .

SGML a quelque shorttags , tels que <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), de sorte qu'il devient <BR/> .

Toutefois, le HTML n'a pas redfine, donc <SCRIPT/> devrait signifie <SCRIPT>> .

(Oui, le '>' doit faire partie du contenu, et l'étiquette est toujours et non fermée.)

évidemment, cela est incompatible avec XHTML et sera briser de nombreux sites (par le temps, les navigateurs étaient suffisamment mûrs aux soins de à propos de ce ), donc personne n'a mis en œuvre shorttags et la spécification déconseille .

en fait, toutes les étiquettes "fonctionnelles" sont des étiquettes avec étiquette d'extrémité facultative sur les analyseurs techniquement non conformes et sont en fait invalides. C'est W3C qui a écrit avec ceci: hack pour aider à la transition vers XHTML en le faisant compatible HTML .

Et <script> balise de fin est pas une option .

"Auto-fin" tag est un hack dans le HTML 4 et est dénuée de sens.


HTML 5

HTML5 a cinq types d'étiquettes et seules les étiquettes" nul "et" étranger "sont autorisées à se fermer automatiquement .

parce que <script> n'est pas nul (il peut ont contenu) et n'est pas étranger (comme MathML ou SVG), <script> ne peut pas être auto-fermé, quelle que soit la façon dont vous l'utilisez.

mais pourquoi? Ne peuvent-ils pas le considérer comme étranger, faire un cas particulier, ou quelque chose?

HTML 5 vise à être backward-compatible avec implémentations de HTML 4 et XHTML 1. Il n'est pas basé sur SGML ou XML; sa syntaxe est principalement axée sur la documentation et l'unification des implémentations. (C'est pourquoi <br/> <hr/> etc. sont valide HTML 5 en dépit d'être invalide HTML4.)

fermeture automatique <script> est l'un des balises où implémentations utilisés diffèrent. Il utilisé pour travailler dans Chrome, Safari , et Opéra ; à ma connaissance, il n'a jamais fonctionné dans Internet Explorer ou Firefox.

cela a été discuté lorsque HTML 5 a été rédigé et a été rejeté parce qu'il pauses navigateur compatibilité . Les pages web qui se ferment d'elles-mêmes avec la balise script peuvent ne pas afficher correctement (si c'est le cas) dans les anciens navigateurs. Il y avait d'autres propositions , mais ils ne peuvent pas résoudre le problème de compatibilité.

après la publication de L'ébauche, WebKit a mis à jour l'analyseur pour qu'il soit conforme.

fermeture automatique <script> ne se fait pas en HTML 5 en raison de la compatibilité descendante avec le HTML 4 et XHTML 1.


XHTML 1 / XHTML 5

quand vraiment servi comme XHTML, <script/> est vraiment fermé, comme autres réponses ont déclaré.

sauf que le spec dit il si avait fonctionné quand il était servi comme HTML:

XHTML Documents ... peut être étiqueté avec le type de média Internet "text / html" [RFC2854], car ils sont compatibles avec la plupart des navigateurs HTML.

alors, que s'est-il passé?

les Gens demanda Mozilla à laissez Firefox analyser conforme des documents comme XHTML quel que soit le contenu de l'en-tête (connu sous le nom "15191510920 de contenu" renifler ). Cela aurait permis des scripts d'auto-fermeture, et renifler le contenu était nécessaire de toute façon parce que les hébergeurs web n'étaient pas assez mûrs pour servir l'en-tête correct; IE était bon à elle .

si la Première Guerre de navigateur ne s'est pas terminée avec IE 6, XHTML peut avoir été sur la liste, aussi. Mais il n'fin. Et IE 6 a un problème avec XHTML. En fait IE n'a pas supporté le type MIME correct du tout , forçant tout le monde à utiliser text/html pour XHTML parce que IE a eu une part de marché majeure pendant une décennie entière.

et aussi le contenu reniflant peut être vraiment mauvais et les gens disent il devrait être arrêté .

enfin, il s'avère que le W3C ne signifie pas que XHTML soit sniffable : le document est à la fois , HTML et XHTML, et Content-Type règle. On peut dire qu'ils étaient fermes sur "just follow our spec" et ignorant ce qui était pratique . Une erreur que a continué dans les versions ultérieures de XHTML.

quoi qu'il en soit, cette décision a réglé l'affaire pour Firefox. C'était 7 ans avant Chrome est né ; il n'y avait pas d'autre navigateur significatif. Il est donc décidé.

Le fait de spécifier le type de document seul ne déclenche pas L'analyse XML à cause des spécifications suivantes.

128
répondu Sheepy 2017-05-23 15:26:27
la source

Internet Explorer 8 et versions antérieures ne supportent pas le parsing XHTML. Même si vous utilisez une déclaration XML et/ou un doctype XHTML, L'ancienne IE analyse toujours le document en HTML. Et en HTML simple, la syntaxe d'auto-fermeture n'est pas supportée. La barre oblique est simplement ignorée, vous devez utiliser une étiquette de fermeture explicite.

même les navigateurs avec prise en charge de l'analyse XHTML, tels que IE 9 et plus tard , vont encore analyser le document en HTML à moins que vous ne serviez le document avec un type de contenu XML. Mais dans ce cas, le vieux IE n'affichera pas le document du tout!

43
répondu JacquesB 2015-03-13 18:31:01
la source

les personnes ci-dessus ont déjà assez bien expliqué le problème, mais une chose qui pourrait rendre les choses claires est que, bien que les gens utilisent '&lt;br/>' et tel tout le temps dans HTML documents, toute '/' dans une telle position est fondamentalement ignoré, et seulement utilisé lorsque l'on essaie de faire quelque chose à la fois parse comme XML et HTML . Essayez '&lt;p/>foo&lt;/p>' , par exemple, et vous obtenez un paragraphe normal.

25
répondu Marijn 2018-03-17 04:59:22
la source

la balise self closing script ne fonctionnera pas, car la balise script peut contenir du code inline, et HTML n'est pas assez intelligent pour activer ou désactiver cette fonctionnalité basée sur la présence d'un attribut.

D'un autre côté, HTML a une étiquette excellente pour inclure références à des ressources externes: la balise <link> , et il peut être à fermeture automatique. Il est déjà utilisé pour inclure les feuilles de style, RSS et Atom alimente, URIs canonique, et toutes sortes de d'autres goodies. Pourquoi pas JavaScript?

si vous voulez que l'étiquette de script soit auto-enfermée vous ne pouvez pas faire cela comme je l'ai dit, mais il y a une alternative, mais pas intelligente. Vous pouvez utiliser la balise de fermeture automatique de lien 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" />
23
répondu defau1t 2014-04-22 12:51:03
la source

contrairement à XML et XHTML, HTML ne connaît pas la syntaxe de fermeture automatique. Les navigateurs qui interprètent XHTML comme HTML ne savent pas que le caractère / indique que la balise doit se fermer d'elle-même; au lieu de cela, ils l'interprètent comme un attribut vide et l'analyseur pense toujours que la balise est 'ouverte'.

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

20
répondu rpetrich 2015-07-27 14:05:22
la source

Internet Explorer 8 et plus ne supporte pas le type MIME approprié pour XHTML, application/xhtml+xml . Si vous servez XHTML comme text/html , ce que vous devez faire pour ces anciennes versions D'Internet Explorer pour faire 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 qui permet d'omettre la balise de fermeture. Voir la HTML 4.01 Spécification .

le XML 'short form' est interprété comme un attribut nommé /, qui (parce qu'il n'y a pas de signe égal) est interprété comme ayant une valeur implicite de "/". Ceci est strictement incorrect dans HTML 4.01 - les attributs non déclarés ne sont pas autorisés - mais les navigateurs l'ignoreront.

IE9 et plus tard support XHTML 5 served with application/xhtml+xml .

18
répondu Mike Dimmick 2015-03-23 19:21:04
la source

différence entre 'true XHTML', 'faux XHTML' et HTML ainsi que l'importance du type MIME envoyé par le serveur avait été déjà décrit ici bien . Si vous voulez l'essayer tout de suite, voici simple editable snippet avec prévisualisation en direct, y compris l'étiquette de script Auto-fermé 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 textarea.

pour inapte navigateurs vous pouvez copier le contenu du textarea et le sauvegarder dans un fichier avec .xhtml (ou .xht ) extension ( merci Alek pour cet indice ).

3
répondu myf 2018-04-27 13:48:10
la source

c'est parce que SCRIPT TAG n'est pas un élément nul.

Dans un Document HTML - VOID ÉLÉMENTS ne pas besoin d'une "balise de fermeture" à tous!

Dans xhtml , tout est Générique, donc ils ont tous besoin de résiliation par exemple, une "balise de fermeture"; y Compris br, un simple saut de ligne, comme <br></br> ou de ses raccourci <br /> .

cependant, un élément de Script n'est jamais un vide ou un élément paramétrique, parce que étiquette de script avant toute autre chose, est une Instruction de navigateur, pas une déclaration de Description de données.

principalement, une Instruction de terminaison sémantique, par exemple, une" étiquette de fermeture " n'est nécessaire que pour les instructions de traitement dont la sémantique ne peut être terminée par une étiquette successive. Par exemple:

<H1> la sémantique ne peut pas être terminée par un <P> suivant, car elle ne contient pas assez de sa propre sémantique pour outrepasser et donc terminer le jeu d'instructions H1 précédent. Bien qu'il soit capable de briser le stream dans une nouvelle ligne de paragraphe, il n'est pas "assez fort" pour surpasser la taille de police actuelle et la ligne de style-hauteur couling down the stream , I. e fuyant de H1 (parce que P ne l'a pas).

This comment et pourquoi la signalisation "/" (terminaison) a été inventée.

générique no-description résiliation Tag < /> , aurait suffi pour tout tomber rencontrés en cascade, par exemple: <H1>Title< /> mais ce n'est pas toujours le cas, parce que nous voulons aussi être capable de "nidification", de multiples intermédiaire de marquage du Flux: divisé en torrents avant de l'emballage et de tomber sur une autre cascade. En conséquence, un générique terminator comme < /> ne serait pas en mesure de déterminer la cible d'une propriété à la fin. Par exemple: <b> en gras <i> gras-italique < /> italique </> normal. Ne réussirait sans doute pas à obtenir notre intention et serait très probablement interpréter comme bold bold-itallic bold normal.

C'est ainsi que la notion d'un emballage ie., le conteneur est né. (Ces notions sont tellement semblables qu'il est impossible de discerner et parfois le même élément peut avoir les deux. <H1> est à la fois un emballage et un conteneur. Alors que <B> n'est qu'un emballage sémantique). Il nous faut un container simple, 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 2BR-Container. Bien sûr, la venue de CSS a rendu la situation plus étrange qu'elle ne l'aurait été autrement et a provoqué une grande confusion avec de nombreuses conséquences importantes - indirectement!

parce qu'avec CSS vous pouvez facilement passer outre le comportement natif pre&after BR d'un DIV nouvellement inventé, il est souvent appelé, comme un"do nothing container". Ce qui est naturellement faux! Les DIVs sont des éléments de bloc et casseront nativement la ligne du flux à la fois avant et après la fin signalisation. Bientôt le WEB a commencé à souffrir de page DIV-itis. La plupart d'entre eux sont encore.

la venue de CSS avec sa capacité à complètement outrepasser et complètement redéfinir le comportement natif de n'importe quelle étiquette HTML, d'une certaine façon réussi à confondre et brouiller le sens entier de L'existence HTML...

tout à coup toutes les balises HTML sont apparues comme obsolètes, elles ont été dégradées, dépouillées de toute leur signification originale, identité et but. En quelque sorte, vous auriez du gagner la l'impression qu'elles ne sont plus nécessaires. En disant: une seule étiquette contenant-emballage suffirait pour toutes les présentations de données. Il suffit d'ajouter les attributs requis. Pourquoi ne pas avoir des étiquettes significatives à la place; inventez des noms d'étiquette pendant que vous allez et laissez le CSS se soucier du reste.

voilà comment xhtml est né et bien sûr le grand blunt, payé si cher par les nouveaux venus et une vision déformée de ce qui est quoi, et quel est le but de tout cela. Le W3C est passé du World Wide Web à quoi S'Est Mal Passé, Camarades?!!

le but de HTML est pour diffuser données significatives au récepteur humain.

pour fournir des informations.

la partie officielle est là pour aider seulement la clarté de la livraison de l'information. xhtml ne donne pas la moindre considération à l'information. - Pour elle, l'information n'est absolument pas pertinente.

la chose la plus importante dans l'affaire est de savoir et être capable de comprendre que xhtml n'est pas seulement une version de quelque 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.

2
répondu Bekim Bacaj 2017-12-09 04:46:30
la source

Autres questions sur javascript html internet-explorer xhtml