javascript - page - ou placer la balise script




Pourquoi les balises de script à fermeture automatique ne fonctionnent-elles pas? (8)

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 déclaration est correcte au moins pour tous les IE (6-8 beta 2).


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

Dans un document HTML - VOID ELEMENTS n'a pas besoin d'un "tag de fermeture" du tout!

Dans 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 son raccourci <br /> .

Cependant, un élément de script n'est jamais un élément vide ou un élément paramétrique, car une 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 "étiquette de fermeture" est seulement nécessaire pour le traitement des instructions dont la sémantique ne peut pas être terminée par une étiquette suivante. Par exemple:

<H1> sémantique <H1> ne peut pas être terminée par un <P> car elle ne porte pas assez de sa propre sémantique pour surcharger et donc terminer l'ensemble d'instructions H1 précédent. Bien qu'il soit capable de diviser le flux en une nouvelle ligne de paragraphe, il n'est pas "assez fort" pour remplacer la taille de police et la hauteur de style actuelles qui descendent le flux , c.-à-d. ).

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

Une < /> terminaison sans description générique comme < /> aurait suffi pour une seule chute de la cascade rencontrée, par exemple: <H1>Title< /> mais ce n'est pas toujours le cas, car nous voulons aussi pouvoir "imbriquer" ", plusieurs marquages ​​intermédiaires du Stream: divisé en torrents avant d'envelopper / tomber sur une autre cascade. En conséquence, un terminateur générique tel que < /> ne serait pas capable de déterminer la cible d'une propriété à terminer. Par exemple: <b> gras <i> gras-italique < /> italique </> normal. Serait sans doute échouer à obtenir notre intention juste et probablement l'interpréter comme audacieux bold-itallic bold normal.

C'est ainsi que naît la notion d'emballage, c'est-à-dire de conteneur. (Ces notions sont si semblables qu'il est impossible de 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> seulement un wrapper sémantique). Nous aurons besoin d'un conteneur simple, sans sémantique. Et bien sûr, l'invention d'un élément DIV est venue.

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

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

L'arrivée du CSS avec sa capacité à surcharger complètement et à redéfinir complètement le comportement natif de n'importe quelle balise HTML, a réussi à confondre et à brouiller toute la signification de l'existence HTML ...

Soudain, toutes les balises HTML sont apparues comme obsolètes, elles ont été défigurées, dépouillées de toute signification, de toute identité et de tout but. D'une façon ou d'une autre, vous aurez l'impression qu'ils ne sont plus nécessaires. Dire: Une seule balise de conteneur-emballage suffirait pour toute la présentation de données. Ajoutez simplement les attributs requis. Pourquoi ne pas avoir des tags significatifs à la place? Inventez les noms des tags au fur et à mesure et laissez le CSS s'occuper du reste.

C'est ainsi qu'est né le xhtml et, bien sûr, la grande franchise, si chèrement payée par les nouveaux venus et une vision déformée de ce qui est quoi, et quel est le but sacré de tout cela. W3C est passé de World Wide Web à ce qui ne va pas, camarades? !!

Le but de HTML est de diffuser des données significatives pour le destinataire humain.

Pour fournir des informations.

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

La chose la plus importante en la matière est de savoir et être capable de comprendre que xhtml n'est pas seulement une version de HTML étendue , xhtml est une bête complètement différente; se lève; et donc il est sage de les garder séparés.


Contrairement à XML et XHTML, le HTML n'a aucune connaissance de la syntaxe à fermeture automatique. Les navigateurs qui interprètent XHTML en HTML ne savent pas que le caractère / indique que la balise doit être fermée automatiquement; au lieu de cela, ils l'interprètent comme un attribut vide et l'analyseur pense toujours que le tag est "ouvert".

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


Dans le cas où quelqu'un est 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 balises peuvent être spécifiées dans la DTD comme étant à fermeture automatique (par exemple BR, HR, INPUT), implicitement fermable (par exemple P, LI, TD) ou explicitement fermable (par exemple TABLE, DIV, SCRIPT). XML n'a bien sûr aucun concept de cela.

Les analyseurs de tag-soupe utilisés par les navigateurs modernes ont évolué à partir de cet héritage, bien que leur modèle d'analyse ne soit plus un pur SGML. Et bien sûr, votre XHTML soigneusement conçu est traité comme un tag-tag inspiré de SGML mal écrit à moins que vous ne l'envoyiez 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 pour un bogue obscur charmant qui peut vous jeter dans des ajustements pendant que vous essayez de coder contre le DOM.


Internet Explorer 8 et les versions antérieures ne prennent pas en charge le type MIME approprié pour XHTML, application/xhtml+xml . Si vous diffusez XHTML en tant que text/html , ce que vous devez faire pour ces versions antérieures d'Internet Explorer, il sera interprété comme HTML 4.01. Vous pouvez uniquement utiliser la syntaxe courte avec n'importe quel élément qui permet d'omettre la balise de fermeture. Voir la spécification HTML 4.01 .

Le 'format court' XML 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 faux dans HTML 4.01 - les attributs non déclarés ne sont pas autorisés - mais les navigateurs l'ignoreront.

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


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> , et elle peut être fermée 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 l'étiquette de script soit auto-jointe, vous ne pouvez pas le faire comme je l'ai dit, mais il y a une alternative, mais pas une puce. Vous pouvez utiliser la balise de lien de fermeture automatique et un 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" />

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é décrites ici . Si vous voulez l'essayer dès maintenant, voici un simple extrait éditable avec prévisualisation en direct incluant une balise 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! Hello, true XHTML. Nice to meet you! ci-dessous textarea.

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


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


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

Cependant, l'envoi d'un type MIME XML entraînera l'analyse de vos pages par IE7, qui n'a que du 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 aussi être utilisés, mais chaque fois que nécessaire, 'application / xhtml + xml' DEVRAIT être utilisé plutôt que ces types de média XML génériques.

J'ai réfléchi à cela il y a quelques mois, et la seule solution réalisable (compatible avec FF3 + et IE7) était d'utiliser l'ancienne syntaxe <script></script> avec text/html (syntaxe HTML + HTML mimetype).

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 (ceci est un changement, Firefox était auparavant moins strict ).

Cela se produira sans tenir compte des méta-tags http-equiv , le XML prolog ou doctype dans votre document - branches de Firefox une fois qu'il obtient l'en text/html 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 /> .





xhtml