Frage Warum funktionieren selbstschließende Script-Tags nicht?


Was ist der Grund, warum Browser nicht richtig erkennen:

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

Nur das ist anerkannt:

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

Unterbricht dies das Konzept der XHTML-Unterstützung?

Hinweis: Diese Aussage ist zumindest für alle IE korrekt (6-8 beta 2).


1155
2017-09-16 06:52


Ursprung


Antworten:


XHTML 1 Spezifikation sagt:

С.3. Elementminimierung und leerer Elementinhalt

Gegeben eine leere Instanz eines Elements, dessen Inhaltsmodell nicht existiert EMPTY (z. B. ein leerer Titel oder Absatz) verwenden Sie nicht das minimierte Formular (z. B. verwenden <p> </p> und nicht <p />).

XHTML-DTD spezifiziert Script-Tags als:

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

419
2017-09-16 07:08



Um das zu ergänzen, was Brad und Squadette gesagt haben, die selbstschließende XML-Syntax <script /> tatsächlich ist Korrektes XML, aber damit es in der Praxis funktioniert, muss Ihr Webserver auch Ihre Dokumente als korrekt formatiertes XML mit einem XML-MIME-Typ senden application/xhtml+xml im Header HTTP Content-Type (und nicht wie text/html).

Wenn Sie jedoch einen XML-MIME-Typ senden, werden Ihre Seiten nicht von IE7 analysiert, was nur gefällt text/html.

Von w3:

Zusammenfassend: "application / xhtml + xml"   SOLLTE für XHTML-Familie verwendet werden   Dokumente und die Verwendung von 'text / html'   SOLLTE auf HTML-kompatibel sein   XHTML 1.0 Dokumente. 'Anwendung / xml'   und 'text / xml' kann auch verwendet werden, aber   wann immer es angebracht ist,   'application / xhtml + xml' SOLLTE verwendet werden   anstatt diese generischen XML-Medien   Arten.

Ich habe vor ein paar Monaten darüber rätseln müssen, und die einzig praktikable (kompatibel mit FF3 + und IE7) Lösung war die alte zu verwenden <script></script> Syntax mit text/html (HTML-Syntax + HTML-MIME-Typ).

Wenn Ihr Server das sendet text/html Geben Sie seine HTTP-Header ein, selbst bei ansonsten korrekt formatierten XHTML-Dokumenten verwendet FF3 + den HTML-Rendering-Modus <script /> wird nicht funktionieren (das ist eine Änderung, Firefox war vorher weniger streng).

Dies wird unabhängig von irgendwelchen Fummeln geschehen http-equiv Meta - Tags, der XML - Prolog oder Doctype in Ihrem Dokument - Firefox verzweigt sobald es den text/html Header, der bestimmt, ob der HTML- oder XML-Parser in das Dokument hineinschaut und der HTML-Parser das nicht versteht <script />.


211
2017-09-16 08:14



Falls jemand neugierig ist, ist der ultimative Grund, dass HTML ursprünglich ein Dialekt von SGML war, welches der seltsame ältere Bruder von XML ist. In SGML-Land können Tags in der DTD entweder als selbstschließend (z. B. BR, HR, INPUT), implizit schließbar (z. B. P, LI, TD) oder explizit schließbar (z. B. TABLE, DIV, SCRIPT) angegeben werden. XML hat dazu natürlich kein Konzept.

Die Tag-Suppen-Parser, die von modernen Browsern verwendet werden, entwickelten sich aus diesem Vermächtnis, obwohl ihr Parsing-Modell nicht mehr reines SGML ist. Und natürlich wird Ihr sorgfältig gestaltetes XHTML als schlecht geschriebene SGML-inspirierte Tag-Suppe behandelt, es sei denn, Sie senden es mit einem XML-Mime-Typ. Aus diesem Grund ...

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

... wird vom Browser interpretiert als:

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

... das ist das Rezept für einen schönen, obskuren Fehler, der Sie beim Versuch, gegen das DOM zu codieren, in Anfälle bringt.


140
2017-07-25 02:52



Andere haben "wie" geantwortet und die Spezifikation zitiert. Hier ist die wahre Geschichte von "warum nicht <script/>", nach vielen Stunden in Bug-Berichte und Mailing-Listen zu graben.


HTML 4

HTML 4 basiert auf SGML.

SGML hat einige Kurztags, sowie <BR//, <B>text</>, <B/text/, oder <OL<LI>item</LI</OL>. XML nimmt die erste Form an, definiert die Endung als ">" (SGML ist flexibel), so dass es wird <BR/>.

HTML wurde jedoch nicht redfine <SCRIPT/>  sollte bedeuten  <SCRIPT>>.
(Ja, das '>' sollte Teil des Inhalts sein, und das Tag ist still nicht geschlossen.)

Offensichtlich ist dies nicht kompatibel mit XHTML und werden brechen viele Websites (zu der Zeit Browser waren reif genug sich kümmern  darüber), damit niemand hat Shorttags umgesetzt und die Spezifikation rät ihnen davon ab.

Effektiv sind alle 'arbeitenden' selbstbeendeten Tags Tags mit optionalem End-Tag auf technisch nicht-konformen Parsern und sind tatsächlich ungültig. Es war W3C kam mit diesem Hack um den Übergang zu XHTML zu erleichtern HTML-kompatibel.

Und <script>End-Tag ist nicht optional.

"Self-Ending" -Tag ist ein Hack in HTML 4 und ist bedeutungslos.


HTML 5

HTML5 hat fünf Arten von Tags und nur "void" und "fremde" Tags sind darf selbstschließend sein.

weil <script> ist nicht ungültig (es kann Inhalt haben) und ist nicht fremd (wie MathML oder SVG), <script> kann nicht geschlossen werden, unabhängig davon, wie Sie es verwenden.

Aber warum? Können sie es nicht als fremd betrachten, Sonderfälle machen oder so etwas?

HTML 5 soll es sein rückwärtskompatibel mit Implementierungen von HTML 4 und XHTML 1. Es basiert nicht auf SGML oder XML; Seine Syntax betrifft hauptsächlich das Dokumentieren und Vereinigen der Implementierungen. (Deshalb <br/>  <hr/> usw. sind gültiges HTML 5 obwohl HTML4 ungültig ist.)

Selbstschließend <script> ist eines der Tags, bei denen sich Implementierungen unterscheiden. Es verwendet, um in Chrome, Safari zu arbeiten, und Oper; meines Wissens hat es im Internet Explorer oder Firefox nie funktioniert.

Dies wurde diskutiert als HTML 5 erstellt wurde und abgelehnt wurde geht kaputt  Browser  Kompatibilität. Webseiten, die das Skript selbsttätig schließen, werden in alten Browsern möglicherweise (wenn überhaupt) nicht korrekt dargestellt. Dort gab es andere Vorschläge, aber sie können das Kompatibilitätsproblem auch nicht lösen.

Nachdem der Entwurf veröffentlicht wurde, aktualisierte WebKit den Parser entsprechend.

Selbstschließend <script> tritt in HTML 5 aufgrund der Abwärtskompatibilität zu HTML 4 und XHTML 1 nicht auf.


XHTML 1 / XHTML 5

Wann Ja wirklich diente als XHTML, <script/> ist wirklich geschlossen, als Andere Antwort habe gesagt.

Außer dass die Spezifikation sagt es sollte haben funktioniert, wenn sie als HTML geliefert wurden:

XHTML-Dokumente ... können mit dem Internet-Medientyp "text / html" [RFC2854] gekennzeichnet werden, da sie mit den meisten HTML-Browsern kompatibel sind.

Also was ist passiert?

Menschen fragte Mozilla zu Lassen Sie Firefox analysieren konforme Dokumente als XHTML unabhängig vom angegebenen Inhaltsheader (bekannt als Inhalt schnüffeln). Dies hätte selbstschließende Skripte und Content-Sniffing ermöglicht War notwendig sowieso, weil Webhosters nicht reif genug waren, um den richtigen Header zu liefern; IE war gut darin.

Wenn die erster Browserkrieg nicht mit IE 6 endete, XHTML könnte auch auf der Liste gewesen sein. Aber es endete. Und IE 6 hat ein Problem mit XHTML. In der Tat IE hat nicht unterstützt der richtige MIME-Typ überhaupt, zwingen jeder benutzen text/html für XHTML, weil IE hatte einen großen Marktanteil für ein ganzes Jahrzehnt.

Und auch Content-Sniffing kann sein  wirklich schlecht und Leute sagen es sollte gestoppt werden.

Schließlich stellt sich heraus, dass das W3C bedeutete nicht, dass XHTML schnüffelbar ist: Das Dokument ist beide, HTML und XHTML und Content-Type Regeln. Man kann sagen, dass sie standhaft auf "einfach unserer Spezifikation folgen" und ignorieren, was praktisch war. Ein Fehler, der fortgesetzt in spätere XHTML-Versionen.

Wie auch immer, diese Entscheidung legte die Sache fest für Firefox. Es war 7 Jahre vor Chrome wurde geboren; Es gab keinen anderen wichtigen Browser. So wurde es entschieden.

Die Angabe des Doctype allein löst aufgrund der folgenden Spezifikationen kein XML-Parsing aus.


123
2018-02-25 12:37



Internet Explorer 8 und früher unterstützen XHTML-Parsing nicht. Selbst wenn Sie eine XML-Deklaration und / oder einen XHTML-Doctype verwenden, analysiert der alte IE das Dokument immer noch als einfachen HTML-Code. Und in reinem HTML wird die selbstschließende Syntax nicht unterstützt. Der abschließende Schrägstrich wird nur ignoriert, Sie müssen ein explizites schließendes Tag verwenden.

Sogar Browser mit Unterstützung für XHTML-Parsing, wie z IE 9 und später, analysiert das Dokument immer noch als HTML, sofern Sie das Dokument nicht mit einem XML-Inhaltstyp bereitstellen. Aber in diesem Fall wird der alte IE das Dokument überhaupt nicht anzeigen!


43
2017-09-16 08:00



Die Leute oben haben das Thema schon ziemlich erklärt, aber eine Sache, die Dinge klarstellen könnte, ist, dass die Leute es benutzen '&lt;br/>' und so die ganze Zeit in HTML Dokumente, any '/' In einer solchen Position wird grundsätzlich ignoriert, und nur verwendet, wenn versucht wird, etwas sowohl als Parseable zu machen XML und HTML. Versuchen '&lt;p/>foo&lt;/p>'zum Beispiel, und Sie erhalten einen regulären Absatz.


25
2017-09-16 13:07



Das selbstschließende Skript-Tag funktioniert nicht, da das Skript-Tag Inline-Code enthalten kann und HTML nicht intelligent genug ist, um dieses Feature basierend auf dem Vorhandensein eines Attributs ein- oder auszuschalten.

Auf der anderen Seite hat HTML ein ausgezeichnetes Tag zum Einschließen   Verweise auf externe Ressourcen: die <link>Tag, und es kann sein   selbstschließend. Es wird bereits verwendet, um Stylesheets, RSS und Atom einzuschließen   Feeds, kanonische URIs und alle möglichen anderen Leckereien. Warum nicht   JavaScript?

Wenn Sie möchten, dass das Skript-Tag selbst eingeschlossen ist, können Sie das nicht tun, wie ich es gesagt habe, aber es gibt eine Alternative, aber keine intelligente. Sie können den selbstschließenden Link-Tag verwenden und einen Link zu Ihrem JavaScript erstellen, indem Sie ihm eine Art Text / JavaScript und Rel als Skript geben, etwa so:

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

23
2017-10-27 09:35



Anders als XML und XHTML kennt HTML die selbstschließende Syntax nicht. Browser, die XHTML als HTML interpretieren, wissen das nicht / Das Zeichen gibt an, dass das Tag selbstschließend sein soll. Stattdessen interpretieren sie es wie ein leeres Attribut und der Parser denkt immer noch, dass das Tag "offen" ist.

Genauso wie <script defer> wird wie behandelt <script defer="defer">, <script /> wird wie behandelt <script /="/">.


19
2017-09-16 07:10



Internet Explorer 8 und älter unterstützen den richtigen MIME-Typ für XHTML nicht application/xhtml+xml. Wenn Sie XHTML als text/html, was Sie für diese älteren Versionen von Internet Explorer alles tun müssen, wird es als HTML 4.01 interpretiert. Sie können die Kurzsyntax nur mit einem beliebigen Element verwenden, das das Schließen des Tags zulässt. Siehe die HTML 4.01 Spezifikation.

Die XML-Kurzform wird als ein Attribut mit dem Namen / interpretiert, das (weil es kein Gleichheitszeichen gibt) als einen impliziten Wert von "/" interpretiert wird. Das ist in HTML 4.01 völlig falsch - nicht deklarierte Attribute sind nicht erlaubt - Browser ignorieren sie jedoch.

IE9 und später unterstützt XHTML 5 serviert mit application/xhtml+xml.


18
2017-09-16 12:48



Der Unterschied zwischen 'True XHTML', 'Faux XHTML' und HTML sowie der Wichtigkeit des vom Server gesendeten MIME-Typs war hier schon gut beschrieben. Wenn Sie es jetzt ausprobieren möchten, hier ist ein einfaches bearbeitbares Snippet mit Live-Vorschau mit selbst geschlossenem Skript-Tag für fähige Browser:

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>

Das solltest du sehen Hello, true XHTML. Nice to meet you! unter Textfeld.

Bei nicht fähigen Browsern können Sie den Inhalt der Textfläche kopieren und als Datei mit speichern .xhtml (oder .xht) Verlängerung (Danke Alek für diesen Hinweis).


3
2017-11-22 00:25



Das liegt daran, dass SCRIPT TAG kein ungültiges Element ist.

In einem (n HTML-Dokument - Leere Elemente unterlassen Sie brauche ein "schließendes tag" überhaupt!

Im xhtmlAlles ist generisch, deshalb brauchen sie alle Beendigung z.B. ein "schließendes Tag"; Einschließlich br, ein einfacher Zeilenumbruch, als <br></br> oder sein Kurzschrift  <br />.

Ein Skriptelement ist jedoch niemals eine Leere oder ein parametrisches Element, weil Skript-Tag vor allem anderen ist eine Browseranweisung, keine Deklaration der Datenbeschreibung.

Im Prinzip wird ein semantischer Beendigungsbefehl, z. B. ein "schließendes Etikett", nur zum Verarbeiten von Befehlen benötigt, dessen Semantik nicht durch ein nachfolgendes Etikett beendet werden kann. Zum Beispiel:

<H1> Semantik kann nicht durch eine Folge beendet werden <P> weil es nicht genug eigene Semantik trägt, um den vorherigen H1-Befehlssatz außer Kraft zu setzen und damit zu beenden. Obwohl es in der Lage sein wird, zu brechen Strom In einer neuen Absatzzeile ist es nicht "stark genug", um die aktuelle Schriftgröße und die Schriftlinienhöhe zu überschreiben den Bach hinunterlaufen, d. h. Leck von H1 (weil P es nicht hat).

Dies ist, wie und warum die "/" (Termination) Signalisierung erfunden wurde.

Ein generisches Keine Beschreibung Kündigung Tag wie < />, hätte für jeden einzelnen Fall aus der angetroffenen Kaskade genügt, z. <H1>Title< /> aber das ist nicht immer der Fall, weil wir auch in der Lage sein wollen, "verschachteln" zu können, mehrere Zwischenmarkierungen des Streams: aufgeteilt in Torrents vor dem Wrapping / Fallen auf eine andere Kaskade. Als Konsequenz wird ein generischer Terminator wie z < /> wäre nicht in der Lage, das Ziel einer zu terminierenden Eigenschaft zu bestimmen. Beispielsweise: <b>Fett gedruckt  <i>Fett Kursiv  < />  kursiv  </>normal. Würde zweifellos unsere Absicht nicht richtig verstehen und würde es wahrscheinlich als interpretieren Fett gedruckt fett-italisch Fett gedruckt normal.

So ist das Begriff von einem Wrapper dh Container wurde geboren. (Diese Begriffe sind so ähnlich, dass es unmöglich ist, sie zu erkennen, und manchmal kann das gleiche Element beides haben. <H1> ist gleichzeitig Wrapper und Container. Wohingegen <B> nur ein semantischer Wrapper). Wir brauchen einen einfachen Semantik-Container. Und natürlich kam die Erfindung eines DIV Elements.

Das DIV-Element ist eigentlich ein 2BR-Container. Natürlich hat das Kommen von CSS die ganze Situation seltsamer gemacht als es sonst gewesen wäre und eine große Verwirrung mit vielen großen Konsequenzen verursacht - indirekt!

Da Sie mit CSS das native Pre- und After-BR-Verhalten eines neu erfundenen DIV leicht überschreiben können, wird es oft als "Do nothing container" bezeichnet. Was natürlich falsch ist! DIVs sind Blockelemente und brechen nativ die Zeile des Streams vor und nach der Endsignalisierung. Bald begann das WEB von der Seite DIV-itis zu leiden. Die meisten von ihnen sind immer noch.

Das Kommen von CSS mit seiner Fähigkeit, das native Verhalten jedes HTML-Tags vollständig zu überschreiben und völlig neu zu definieren, hat es irgendwie geschafft, die ganze Bedeutung von HTML-Existenz zu verwirren und zu verwischen ...

Plötzlich erschienen alle HTML-Tags als obsolet, sie wurden entstellt, entkleidet von ihrer ursprünglichen Bedeutung, ihrer Identität und ihrem Zweck. Irgendwie bekommt man den Eindruck, dass sie nicht mehr gebraucht werden. Sprich: Ein einzelnes Container-Wrapper-Tag würde für die gesamte Datenpräsentation ausreichen. Fügen Sie einfach die erforderlichen Attribute hinzu. Warum haben Sie keine aussagekräftigen Tags? Erfinde Tag-Namen, während du gehst und lass CSS mit dem Rest herumalbern.

So wurde XHTML geboren und natürlich das große, von Neuankömmlingen so teuer bezahlte und verzerrte Bild von dem, was was ist, und was ist der verdammte Zweck von allem. W3C ging vom World Wide Web zu Was ging falsch, Genossen? !!

Der Zweck von HTML ist streamen aussagekräftige Daten für den menschlichen Empfänger.

Informationen liefern.

Der formale Teil dient nur dazu, die Informationsbereitstellung zu vereinfachen. xhtml berücksichtigt die Informationen nicht im geringsten. - Dazu sind die Informationen absolut irrelevant.

Das Wichtigste in der Sache ist, das zu wissen und verstehen zu können xhtml ist nicht nur eine Version von erweitertem HTML, xhtml ist ein völlig anderes Tier; Gründe; und deshalb es ist klug, sie getrennt zu halten. 


2
2017-08-17 22:54