Warum funktionieren selbstschließende Skriptelemente nicht?

1346

Was ist der Grund, warum Browser nicht richtig erkennen:

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

Nur das wird erkannt:

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

Verstößt dies gegen das Konzept der XHTML-Unterstützung?

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

Dimarzionist
quelle
12
Funktioniert in Chrome und Opera
Corymathews
46
Einige neuere Versionen von Chrome scheinen dies beschädigt zu haben. Selbstschließende Skript-Tags funktionieren in Chrome nicht mehr
Adam Ness
13
Es sind nicht nur Skript-Tags. Ich glaube auch nicht, dass selbstschließende Div-Tags funktionieren.
DOK
6
Ab Juli 2011 haben Chrome und Firefox dieses Problem. "Es ist kein Fehler, es ist eine Funktion" - wirklich nervig.
Martin Konicek
4
Die allgemeinere Version davon wurde zwei Tage später gefragt: stackoverflow.com/questions/97522/…
Ciro Santilli 1 病毒 审查 六四 事件 法轮功

Antworten:

481

Die XHTML 1-Spezifikation lautet:

С.3. Elementminimierung und leerer Elementinhalt

Verwenden Sie bei einer leeren Instanz eines Elements, dessen Inhaltsmodell nicht ist EMPTY(z. B. ein leerer Titel oder Absatz), nicht die minimierte Form (z. B. verwenden <p> </p>und nicht verwenden <p />).

Die XHTML-DTD gibt Skriptelemente wie folgt an:

<!-- script statements, which may include CDATA sections -->
<!ELEMENT script (#PCDATA)>
Squadette
quelle
111
Dennoch ist „nicht tun“ nicht dasselbe wie „darf nicht“. Dies ist eine Richtlinie (aus Kompatibilitätsgründen, wie im Abschnittstitel vorgeschlagen), keine Regel.
Konrad Rudolph
42
Eigentlich kann ich für diese Einschränkung keine Verwendung finden :) Es scheint völlig künstlich.
Squadette
22
Die richtige Antwort gab olavk. Der Anhang C von XHTML 1.0 ist nicht der Grund, warum die Dinge so sind, wie sie sind - es geht nur darum, wie man die Dinge umgeht.
Hsivonen
32
Es ist kein normativer Teil der Spezifikation. Es ist nur ein Anhang über den Umgang mit Browsern, die XHTML nicht unterstützen
Kornel
12
Das Problem dabei <script />ist nicht, dass die Spezifikation dies nicht zulässt, sondern dass Browser es nicht als "Nicht-Tag-Suppe" interpretieren, wenn der Inhaltstyp nicht application / xhtml + xml ist. Siehe: stackoverflow.com/questions/348736/… @shabunc: Browser scheinen es zu verstehen, aber was tatsächlich passiert, ist, dass der Inhalt nach dem <p /> in den Absatz eingefügt wird, da das Zitat der Squadette so interpretiert wird, dass seit < p> ist nicht leer, es kann nicht selbstschließend sein. In XHTML 1.1, es kann selbstschließend sein.
Joe
241

So fügen Sie zu dem, was Brad und squadette gesagt haben, die selbstschließenden XML - Syntax <script />tatsächlich ist richtig XML, aber dafür in der Praxis, Ihr Web - Server muss auch Ihre Dokumente als richtig gebildet XML mit einem XML - MIME - Typ senden , wie application/xhtml+xmlin dem HTTP Inhaltstyp-Header (und nicht als text/html).

Das Senden eines XML-Mimetyps führt jedoch dazu, dass Ihre Seiten nicht von IE7 analysiert werden, was nur gefällt text/html.

Von w3 :

Zusammenfassend sollte 'application / xhtml + xml' für Dokumente der XHTML-Familie verwendet werden, und die Verwendung von 'text / html' sollte auf HTML-kompatible XHTML 1.0-Dokumente beschränkt sein. 'application / xml' und 'text / xml' KÖNNEN ebenfalls verwendet werden, aber bei Bedarf sollte 'application / xhtml + xml' anstelle dieser generischen XML-Medientypen verwendet werden.

Ich habe vor einigen Monaten darüber gerätselt, und die einzige praktikable (kompatibel mit FF3 + und IE7) Lösung bestand darin, die alte <script></script>Syntax mit text/html(HTML-Syntax + HTML-Mimetyp) zu verwenden.

Wenn Ihr Server den text/htmlTyp in seinen HTTP-Headern sendet , verwendet FF3 + auch bei ansonsten ordnungsgemäß geformten XHTML-Dokumenten den HTML-Rendering-Modus, was bedeutet, dass dies <script />nicht funktioniert (dies ist eine Änderung, Firefox war zuvor weniger streng).

Dies geschieht unabhängig davon , ob http-equivSie mit Metaelementen, dem XML-Prolog oder dem Doctype in Ihrem Dokument herumspielen. Firefox verzweigt, sobald der text/htmlHeader angezeigt wird, der festlegt, ob der HTML- oder XML-Parser in das Dokument eingeht und der HTML-Parser dies nicht versteht<script /> .

joelhardi
quelle
3
Ist es dann richtig zu schließen, dass Sie durch das Senden von Text / XML eine breite Browserunterstützung für <script /> erhalten, wenn Sie die Unterstützung für IE7 einstellen?
Chris Moschini
7
Kurz gesagt, <script /> funktioniert nur, wenn Ihr MIME-Typ der Seite xhtml / xml ist. Bei normalen Text- / HTML-Seiten funktioniert dies nicht. UND wenn wir versuchen, den MIME-Typ "xhtml / xml" zu verwenden, wird die IE-Kompatibilität beeinträchtigt. Zusammenfassend lässt sich
sagen
1
Hervorragende Erklärung. Ein weiterer bemerkenswerter Punkt ist, dass in Firefox .htmlaus ähnlichen Gründen auch lokale Dateien als Tag-Suppe gerendert werden, unabhängig von Meta-Tags. Firefox rendert XHTML-Dateien nur dann entsprechend, wenn sie benannt sind .xhtml.
Alecov
@ ChrisMoschini. Wahrscheinlich, aber verwenden application/xhtml+xml, nicht text/xml.
TRiG
167

Falls jemand neugierig ist, ist der ultimative Grund, dass HTML ursprünglich ein Dialekt von SGML war, dem seltsamen älteren Bruder von XML. In SGML-Land können Elemente 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 natürlich kein Konzept dafür.

Die von modernen Browsern verwendeten Tag-Suppe-Parser sind aus diesem Erbe hervorgegangen, obwohl ihr Parsing-Modell keine reine SGML mehr ist. Und natürlich wird Ihr sorgfältig ausgearbeitetes XHTML als schlecht geschriebene SGML-inspirierte Tag-Suppe behandelt, es sei denn, Sie senden es mit einem XML-MIME-Typ. Dies ist auch der Grund, warum ...

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

... wird vom Browser wie folgt interpretiert:

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

... das ist das Rezept für einen schönen, obskuren Fehler, der Sie in Anfälle stürzen kann, wenn Sie versuchen, gegen das DOM zu codieren.

greim
quelle
4
Ich bin neugierig. Warum interpretiert der Browser dies so?
Ahmed Aeon Axan
32
@AhmedAeonAxan: Das PElement kann nicht enthalten DIVElemente (dies ist ungültig HTML), so dass der Browser implizit das schließt PElement (definiert als „implizit verschließbaren“) vor der Öffnung DIVTag. Browser verhalten sich in dieser Hinsicht jedoch tendenziell anders (wie bei jedem ungültigen HTML-Code).
MrWhite
5
@ColeJohnson Nein, dies ist keine Tag-Suppe. greim verwirrt die Grenze zwischen gültigem und ungültigem HTML. Tag-Suppe erhalten Sie, wenn Autoren die Regeln nicht beachten, da Browser die Fehlerkorrektur verwenden. Ein fehlendes </p>End-Tag hingegen ist Teil der Definition von HTML!
Herr Lister
3
@ MrLister - Art von. "Tag-Suppe" beschreibt, wie HTML analysiert wird, nicht wie es erstellt wird. Es war ein Begriff, der verwendet wurde, um unterschiedliche Strategien zu beschreiben, mit denen Browser HTML verstehen, und steht im Gegensatz zu striktem XML-Parsing. XML-Parsing ist nur für XML-MIME-Typen zulässig. Da diese jedoch nie weit verbreitet waren, haben die Browser auch bei ansonsten gültigen Dokumenten auf verschiedene "Tag-Suppe" -Schemata zurückgegriffen.
Greim
8
HTML5 standardisierte tatsächlich das Parsen von "Tag-Suppe", einschließlich einer konsistenten Methode zum Behandeln ungültiger Markups. Bis dahin mussten Browser selbst herausfinden, was mit ungültigem Markup zu tun ist, was zu Inkonsistenzen führte. Der HTML-Parser in aktuellen Browsern ist eine der fortschrittlichsten Software, die jemals geschrieben wurde. Er ist unglaublich schnell und kann mit fast allen Eingaben umgehen, was zu konsistenten Ergebnissen führt.
Stijn de Witt
161

Andere haben "wie" geantwortet und spec zitiert. Hier ist die wahre Geschichte von "Warum nein <script/>", nachdem wir uns viele Stunden lang mit Fehlerberichten und Mailinglisten befasst haben.


HTML 4

HTML 4 basiert auf SGML .

SGML hat einige Short , wie <BR//, <B>text</>, <B/text/oder <OL<LI>item</LI</OL>. XML nimmt die erste Form an und definiert das Ende als ">" neu (SGML ist flexibel), so dass es wird <BR/>.

HTML wurde jedoch nicht neu definiert, <SCRIPT/> sollte also bedeuten <SCRIPT>> .
(Ja, das '>' sollte Teil des Inhalts sein und das Tag ist immer noch nicht geschlossen.)

Offensichtlich ist dies nicht mit XHTML kompatibel und wird viele Websites beschädigen (als die Browser ausgereift genug waren , um sich darum zu kümmern ), sodass niemand Shorttags implementiert hat und die Spezifikation davon abrät .

Tatsächlich sind alle "funktionierenden" selbstendenden Tags Tags mit verbotenem End-Tag auf technisch nicht konformen Parsern und tatsächlich ungültig. Es war W3C, das diesen Hack entwickelte , um den Übergang zu XHTML zu erleichtern, indem es HTML-kompatibel gemacht wurde .

Und <script>das End-Tag ist nicht verboten .

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


HTML 5

HTML5 hat fünf Arten von Tags und nur "void" - und "fremde" Tags dürfen sich selbst schließen .

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

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

HTML 5 soll abwärtskompatibel mit Implementierungen von HTML 4 und XHTML 1 sein. Es basiert nicht auf SGML oder XML. Die Syntax befasst sich hauptsächlich mit der Dokumentation und Vereinheitlichung der Implementierungen. (Aus diesem Grund sind <br/> <hr/>usw. gültiges HTML 5, obwohl es ungültiges HTML4 ist.)

Selbstschließend <script>ist eines der Tags, bei denen sich die Implementierungen unterschieden. Es verwendet , um Arbeit in Chrome, Safari , und Opera ; Meines Wissens hat es in Internet Explorer oder Firefox nie funktioniert.

Dies wurde beim Entwurf von HTML 5 besprochen und abgelehnt, da es die Browserkompatibilität beeinträchtigt . Webseiten, deren Skript-Tag sich selbst schließt, werden in alten Browsern möglicherweise nicht richtig (wenn überhaupt) gerendert. Es gab andere Vorschläge , aber sie können das Kompatibilitätsproblem auch nicht lösen.

Nach der Veröffentlichung des Entwurfs hat WebKit den Parser so aktualisiert, dass er den Anforderungen entspricht.

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


XHTML 1 / XHTML 5

Wenn wirklich als XHTML gedient, <script/>ist es wirklich geschlossen, wie andere Antworten angegeben haben.

Außer , dass die Spezifikation sagt es sollte gearbeitet haben , wenn sie als HTML serviert:

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

Also was ist passiert?

Die Leute baten Mozilla , Firefox konforme Dokumente als XHTML analysieren zu lassen, unabhängig vom angegebenen Inhaltsheader (bekannt als Content Sniffing ). Dies hätte selbstschließende Skripte ermöglicht, und das Sniffing von Inhalten war ohnehin notwendig, da Webhoster nicht ausgereift genug waren, um den richtigen Header bereitzustellen. IE war gut darin .

Wenn der erste Browserkrieg nicht mit IE 6 endete, war möglicherweise auch XHTML auf der Liste. Aber es endete. Und IE 6 hat ein Problem mit XHTML. In der Tat IE unterstützt nicht den richtigen MIME - Typ überhaupt , zwingt alle zu verwenden , text/htmlfür XHTML , weil IE gehalten großen Marktanteil für ein ganzes Jahrzehnt.

Und auch das Schnüffeln von Inhalten kann sehr schlecht sein und die Leute sagen, es sollte gestoppt werden .

Schließlich stellt sich heraus, dass das W3C nicht bedeutete, dass XHTML schnüffelbar ist : Das Dokument ist sowohl HTML als auch XHTML und Content-TypeRegeln. Man kann sagen, dass sie fest auf "einfach unserer Spezifikation folgen" standen und ignorierten, was praktisch war . Ein Fehler, der in späteren XHTML-Versionen fortgesetzt wurde .

Wie auch immer, diese Entscheidung hat die Angelegenheit für Firefox geregelt . Es dauerte 7 Jahre, bis Chrome geboren wurde . Es gab keinen anderen wichtigen Browser. So wurde entschieden.

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

Schafig
quelle
1
@AndyE Wenn Sie selbstschließendes <script> schreiben, glauben die wichtigsten Browser zu diesem Zeitpunkt nicht, dass es geschlossen ist, und analysieren die HTML-Teilsequenz als Javascript, wodurch gültiges HTML5 in diesen alten Browsern beschädigt wird. Somit wird der Vorschlag abgelehnt. Dies wird in der verknüpften HTML5-Mailingliste erläutert.
Sheepy
2
@AndyE: Was Sie beschreiben, ist Vorwärtskompatibilität - die Fähigkeit des alten Codes, mit dem neuen Compiler / Interpreter / Parser zu arbeiten. Abwärtskompatibilität ist die Fähigkeit von neuem Code, mit altem Compiler / Interpreter / Parser zu arbeiten. Ja, Abwärtskompatibilität war das Problem, da sonst Seiten, die mit Blick auf die neue Spezifikation geschrieben wurden, in alten Browsern nicht funktionieren würden (und ja, es ist eine Tradition der Webprogrammierung, zu versuchen, neuen Code so gut wie möglich in alten Browsern zum Laufen zu bringen).
Slebetman
3
@Dmitry Die Realität ist, dass das Nichtzulassen von selbstgeschlossenem Skript eine Einbahnstraße ist. Da verknüpftes , selbst geschlossenes <Skript> alle Browser beschädigt, sehen Benutzer einfach eine leere Seite - Spielekonsolen, Internet-TV, den IE 11 auf dem neuen Win7-PC des Unternehmens, Millionen von Java-Laufzeiten oder Milliarden von Smartphones. Können Sie die meisten WebView der meisten Sprachen auf den meisten Geräten aktualisieren? Wenn HTML5 versucht hätte, dass sie wie XHTML2 fehlgeschlagen wären.
Sheepy
6
sehr unterschätzte Antwort
Kamil Tomšík
2
Ein bisschen Korrektur: Tags, die in HTML als selbst geschlossen erscheinen, sind keine Tags mit optionalen End-Tags, sondern solche mit verbotenen End-Tags (leere oder ungültige Tags). Tags mit optional End - Tags, wie <p>oder <li>kann nicht sein ‚Selbst geschlossen‘ , da sie können Inhalte haben, so wie Code <p/>ist nichts mehr , dass ein (malformed) Start - Tag und den Inhalt , nachdem es, wenn es in diesem Elemente erlaubt ist würde darin enden.
Ilya Streltsyn
44

Internet Explorer 8 und frühere Versionen unterstützen keine XHTML-Analyse. Selbst wenn Sie eine XML-Deklaration und / oder einen XHTML-Doctype verwenden, analysiert der alte IE das Dokument immer noch als einfaches HTML. In einfachem HTML wird die selbstschließende Syntax nicht unterstützt. Der abschließende Schrägstrich wird einfach ignoriert. Sie müssen ein explizites schließendes Tag verwenden.

Selbst Browser mit Unterstützung für XHTML-Analyse wie IE 9 und höher analysieren das Dokument weiterhin als HTML, es sei denn, Sie stellen das Dokument mit einem XML-Inhaltstyp bereit. In diesem Fall zeigt der alte IE das Dokument überhaupt nicht an!

JacquesB
quelle
9
"IE unterstützt keine XHTML-Analyse." war zu dem Zeitpunkt, als dies geschrieben wurde, für IE-Versionen wahr, ist aber nicht mehr wahr.
EricLaw
@EricLaw können Sie klären, welche Version von IE dies behoben hat? (und alle spezifischen Bedingungen - zB gültiger Doctype erforderlich)
Scunliffe
2
@scunliffe IE9 war die erste Version mit voller Unterstützung für XHTML. blogs.msdn.com/b/ie/archive/2010/11/01/…
EricLaw
28

Die oben genannten Personen haben das Problem bereits ziemlich genau erklärt, aber eine Sache, die die Dinge klar machen könnte, ist, dass, obwohl die Benutzer <br/>und solche ständig in HTML-Dokumenten verwenden, jede /in einer solchen Position grundsätzlich ignoriert und nur verwendet wird, wenn versucht wird, dies zu machen etwas, das sowohl als XML als auch als HTML analysiert werden kann. Versuchen Sie es <p/>foo</p>zum Beispiel, und Sie erhalten einen regulären Absatz.

Marijn
quelle
22

Das selbstschließende Skript-Tag funktioniert nicht, da das Skript-Tag Inline-Code enthalten kann und HTML nicht intelligent genug ist, um diese Funktion basierend auf dem Vorhandensein eines Attributs zu aktivieren oder zu deaktivieren.

Auf der anderen Seite verfügt HTML über ein hervorragendes Tag, um Verweise auf externe Ressourcen aufzunehmen: das <link>Tag, und es kann sich selbst schließen. Es wird bereits verwendet, um Stylesheets, RSS- und Atom-Feeds, kanonische URIs und alle möglichen anderen Extras einzuschließen. Warum nicht JavaScript?

Wenn Sie möchten, dass das Skript-Tag in sich geschlossen ist, können Sie dies nicht wie gesagt tun, aber es gibt eine Alternative, wenn auch keine intelligente. Sie können das selbstschließende Link-Tag und den Link zu Ihrem JavaScript verwenden, indem Sie ihm eine Art Text / Javascript und rel als Skript geben, wie folgt:

<link type="text/javascript" rel ="script" href="/path/tp/javascript" />
defau1t
quelle
4
Ich mag das, warum ist es aber nicht "klug"?
Josh M.
5
Weil es ein vordefiniertes Skript-Tag gibt, mit dem genau das Laden eines Skripts ausgeführt werden kann. Warum sollten Sie die Dinge mit etwas anderem verwirren? Ein Hammer hämmert in die Nägel. Wäre es klug, einen Schuh zu benutzen?
Dave Lawrence
8
@daveL - Und wir haben <style>Tags, verwenden jedoch Link-Tags für externe CSS-Dateien. Definition des Link-Tags: "Das <link> -Tag definiert eine Verknüpfung zwischen einem Dokument und einer externen Ressource." Scheint vollkommen logisch, dass das Link-Tag für externes CSS oder JS verwendet wird ... dafür ist es ... für das Verknüpfen in externen Dateien. Hinweis: Ich spreche nicht von spec / browserübergreifend / etc, ich kommentiere nur die logische Natur der Verwendung von Link-Tags, um sowohl CSS als auch JS einzubringen ... es wäre tatsächlich sehr sinnvoll, wenn es so wäre . Ich bin mir nicht sicher, ob der Schuh [Analogie] passt.
Jimbo Jonny
20

Im Gegensatz zu XML und XHTML kennt HTML die selbstschließende Syntax nicht. Browser, die XHTML als HTML interpretieren, wissen nicht, dass das /Zeichen angibt, dass das Tag sich selbst schließen soll. Stattdessen interpretieren sie es wie ein leeres Attribut und der Parser denkt immer noch, dass das Tag 'offen' ist.

So wie <script defer>es behandelt wird <script defer="defer">, <script />wird es auch so behandelt <script /="/">.

rpetrich
quelle
33
So elegant diese Erklärung auch ist, sie ist tatsächlich falsch. Wenn es wahr wäre, gäbe es ein "/" -Attribut für das Skriptelement im DOM. Ich habe IE, Firefox und Opera überprüft und keines von ihnen enthält tatsächlich ein solches Attribut.
Alohci
11
/ ist kein gültiges Attributnamenzeichen, daher wird es verworfen. Ansonsten ist diese Erklärung ziemlich klar.
Hallvors - Wiederherstellung Monica
1
Tatsächlich interpretieren einige HTML-Parser (und insbesondere Validatoren) das /als Teil der NET-Konstruktion (Null End Tag).
IllidanS4 will Monica
18

Internet Explorer 8 und älter unterstützen nicht den richtigen MIME-Typ für XHTML application/xhtml+xml. Wenn Sie XHTML als bereitstellen text/html, was Sie für diese älteren Versionen von Internet Explorer benötigen, um etwas zu tun, wird es als HTML 4.01 interpretiert. Sie können die kurze Syntax nur für Elemente verwenden, bei denen das schließende Tag weggelassen werden kann. Siehe die HTML 4.01-Spezifikation .

Die XML-Kurzform wird als Attribut mit dem Namen / interpretiert, das (da es kein Gleichheitszeichen gibt) mit dem impliziten Wert "/" interpretiert wird. Dies ist in HTML 4.01 streng falsch - nicht deklarierte Attribute sind nicht zulässig - aber Browser ignorieren dies.

IE9 und höher unterstützen XHTML 5 mit application/xhtml+xml.

Mike Dimmick
quelle
IE 9 unterstützt XHTML und IE ist nicht mehr> 51%. Könnten Sie Ihre Antwort aktualisieren?
Damian Yerrick
5

Das liegt daran, dass SCRIPT TAG kein VOID ELEMENT ist.

In einem HTML-Dokument - VOID ELEMENTS nicht benötigen "Closing Tag"!

In xhtml ist alles generisch, daher müssen alle beendet werden, z. B. ein "schließendes Tag". Einschließlich br, eines einfachen Zeilenumbruchs als <br></br>oder seiner Kurzform <br /> .

Ein Skriptelement ist jedoch niemals ein ungültiges oder parametrisches Element, da das Skript-Tag vor allem eine Browseranweisung und keine Datenbeschreibungsdeklaration ist.

Grundsätzlich wird eine semantische Beendigungsanweisung, z. B. ein "schließendes Tag", nur zur Verarbeitung von Anweisungen benötigt, deren Semantik nicht durch ein nachfolgendes Tag beendet werden kann. Zum Beispiel:

<H1>Die Semantik kann nicht durch eine Folge beendet werden, <P>da sie nicht genug eigene Semantik enthält, um den vorherigen H1-Befehlssatz zu überschreiben und daher zu beenden. Obwohl es in der Lage sein wird, den Stream in eine neue Absatzzeile zu unterteilen, ist es nicht "stark genug", um die aktuelle Schriftgröße und Stilzeilenzeile, die über den Stream fließt, zu überschreiben , dh aus H1 austritt (weil P sie nicht hat) ).

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

Ein generisches No-Description- Termination-Tag wie < />hätte für jeden einzelnen Abfall der angetroffenen Kaskade ausgereicht, z. B.: Dies ist <H1>Title< />jedoch nicht immer der Fall, da wir auch in der Lage sein möchten, mehrere Zwischen- Tag- Tags des Stream: split zu "verschachteln" in Ströme, bevor sie in eine andere Kaskade gewickelt werden. Infolgedessen kann ein generischer Terminator, wie z. B. < />das Ziel einer zu terminierenden Eigenschaft nicht bestimmen. Zum Beispiel: <b>fett <i>fett-kursiv < /> kursiv </> normal. Würde zweifellos unsere Absicht nicht richtig verstehen und würde sie höchstwahrscheinlich als kühn fett-itallisch fett normal interpretieren .

Auf diese Weise wurde der Begriff eines Wrappers, dh eines Containers, geboren. (Diese Begriffe sind so ähnlich, dass es unmöglich ist, sie zu erkennen, und manchmal kann dasselbe Element beides haben. Es <H1>ist gleichzeitig Wrapper und Container. Während <B>nur ein semantischer Wrapper.) Wir brauchen einen einfachen Container ohne Semantik. Und natürlich kam die Erfindung eines DIV-Elements.

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

Da Sie mit CSS das native Pre- und After-BR-Verhalten eines neu erfundenen DIV leicht überschreiben können, wird es häufig als "Nichtstun-Container" bezeichnet. Welches ist natürlich falsch! DIVs sind Blockelemente und unterbrechen die Linie des Streams sowohl vor als auch nach der Endsignalisierung. Bald begann das WEB unter Seite DIV-itis zu leiden. Die meisten von ihnen sind es noch.

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

Plötzlich schienen alle HTML-Tags veraltet zu sein, sie wurden unkenntlich gemacht und ihrer ursprünglichen Bedeutung, Identität und ihres Zwecks beraubt. Irgendwie würden Sie den Eindruck gewinnen, dass sie nicht mehr benötigt werden. Sprichwort: Ein einziges Container-Wrapper-Tag würde für die gesamte Datenpräsentation ausreichen. Fügen Sie einfach die erforderlichen Attribute hinzu. Warum nicht stattdessen aussagekräftige Tags haben? Erfinde Tag-Namen, während du gehst, und lass das CSS sich um den Rest kümmern.

Auf diese Weise wurde xhtml geboren und natürlich der große Stumpfe, der von Neuankömmlingen so teuer bezahlt wurde und eine verzerrte Vorstellung davon, was was ist und was der verdammte Zweck von allem ist. W3C wechselte vom World Wide Web zu What Went Wrong, Genossen? !!

Der Zweck von HTML besteht darin, aussagekräftige Daten an den menschlichen Empfänger zu streamen .

Informationen liefern.

Der formale Teil dient nur dazu, die Klarheit der Informationsbereitstellung zu verbessern. xhtml berücksichtigt die Informationen nicht im geringsten. - Für sie sind die Informationen absolut irrelevant.

Das Wichtigste dabei ist, zu wissen und verstehen zu können, dass xhtml nicht nur eine Version von erweitertem HTML ist , xhtml ist ein völlig anderes Biest. Gründe; und deshalb ist es ratsam, sie getrennt zu halten.

Bekim Bacaj
quelle
3

Der Unterschied zwischen 'true XHTML', 'faux XHTML' und HTML sowie die Bedeutung des vom Server gesendeten MIME-Typs wurden hier bereits ausführlich beschrieben . Wenn Sie es jetzt ausprobieren möchten, finden Sie hier ein einfaches bearbeitbares Snippet mit Live-Vorschau, einschließlich eines selbstgeschlossenen Skript-Tags 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>

Sie sollten Hello, true XHTML. Nice to meet you!unten Textbereich sehen.

Für unfähige Browser können Sie den Inhalt des Textbereichs kopieren und als Datei mit der Erweiterung ( .xhtmloder .xht) speichern ( danke Alek für diesen Hinweis ).

myf
quelle