Perché gli elementi di script con chiusura automatica non funzionano?

Qual è il motivo per cui i browser non riconoscono correttamente:

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

Solo questo è riconosciuto:

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

Questo rompe il concetto di supporto XHTML?

Nota: questa affermazione è corretta almeno per tutti gli IE (6-8 beta 2).

La specifica XHTML 1 dice:

С.3. Minimizzazione dell'elemento e contenuto dell'elemento vuoto

Data un'istanza vuota di un elemento il cui modello di contenuto non è EMPTY(ad esempio un titolo o un paragrafo vuoto) non utilizza il modulo ridotto a icona (ad es. Usa <p> </p>e non <p />).

XHTML DTD specifica gli elementi dello script come:

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

Per aggiungere a quello che Brad e squadette hanno detto, la sintassi XML chiusura automatica <script />in realtà è corretto XML, ma per farlo funzionare in pratica, il server web ha anche bisogno di inviare i documenti in formato XML correttamente formata con un mimetype XML come application/xhtml+xmlin HTTP Intestazione Content-Type (e non come text/html).

Tuttavia, l'invio di un mimetype XML farà sì che le tue pagine non vengano analizzate da IE7, che piace solo text/html.

Da w3 :

In sintesi, 'application / xhtml + xml' DOVREBBE essere utilizzato per i documenti della famiglia XHTML e l'uso di 'text / html' DOVREBBE essere limitato ai documenti XHTML 1.0 compatibili con HTML. Anche 'application / xml' e 'text / xml' POSSONO essere usati, ma ogni qualvolta appropriato, 'application / xhtml + xml' DOVREBBE essere usato piuttosto che quei tipi di media XML generici.

L'ho confuso qualche mese fa e l'unica soluzione praticabile (compatibile con FF3 + e IE7) era usare la vecchia <script></script>sintassi con text/html(sintassi HTML + mimetype HTML).

Se il tuo server invia il text/htmltipo nelle intestazioni HTTP, anche con documenti XHTML altrimenti formati correttamente, FF3 + utilizzerà la sua modalità di rendering HTML, il che significa che <script />non funzionerà (questa è una modifica, Firefox era in precedenza meno rigoroso).

Questo accadrà a prescindere da qualsiasi armeggiare con http-equivmeta elementi, il prologo XML o il doctype all'interno del tuo documento - Firefox si ramifica una volta ottenuta l' text/htmlintestazione, che determina se il parser HTML o XML appare all'interno del documento e il parser HTML non capisce <script />.

Nel caso in cui qualcuno fosse curioso, la ragione ultima è che HTML era originariamente un dialetto di SGML, che è lo strano fratello maggiore di XML. Nella terra SGML, gli elementi possono essere specificati nel DTD come autochiudenti (ad es. BR, HR, INPUT), implicitamente chiudibili (ad es. P, LI, TD) o esplicitamente chiudibili (ad es. TABELLA, DIV, SCRIPT). XML, ovviamente, non ha idea di questo.

I parser di tag-soup utilizzati dai browser moderni si sono evoluti da questo retaggio, sebbene il loro modello di analisi non sia più puro SGML. E, naturalmente, il tuo XHTML accuratamente realizzato viene trattato come un tag-soup di ispirazione SGML mal scritto, a meno che non lo invii con un tipo mime XML. Questo è anche il motivo per cui ...

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

... viene interpretato dal browser come:

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

... che è la ricetta per un adorabile bug oscuro che può metterti in crisi mentre cerchi di codificare contro il DOM.

Altri hanno risposto "come" e citato le specifiche. Ecco la vera storia del "perché no <script/>", dopo molte ore di ricerche di bug e mailing list.

HTML 4

HTML 4 si basa su SGML .

SGML ha alcuni shorttags , come <BR//, <B>text</>, <B/text/, o <OL<LI>item</LI</OL>. XML prende la prima forma, ridefinisce la fine come ">" (SGML è flessibile), in modo che diventi <BR/>.

Tuttavia, HTML non ha ridefinito, quindi <SCRIPT/> dovrebbe significare <SCRIPT>> .
(Sì, il '>' dovrebbe essere parte del contenuto, e il tag è ancora non è chiuso.)

Ovviamente, questo non è compatibile con XHTML e si romperà molti siti (dai browser tempo erano abbastanza maturi per prendersi cura di questo ), in modo da nessuno implementato shorttags e la specifica consiglia contro di loro .

In effetti, tutti i tag auto-funzionanti "funzionanti" sono tag con tag finale vietato su parser tecnicamente non conformi e in realtà non sono validi. È stato W3C a inventare questo hack per aiutare il passaggio a XHTML rendendolo compatibile con HTML .

E <script>il tag di fine non è proibito .

Il tag "auto-terminante" è un hack in HTML 4 ed è insignificante.

HTML 5

HTML5 ha cinque tipi di tag e solo i tag "vuoto" e "estraneo" possono essere chiusi automaticamente .

Poiché <script>non è nullo ( può avere contenuto) e non è estraneo (come MathML o SVG), <script>non può essere chiuso automaticamente, indipendentemente da come lo si utilizza.

Ma perché? Non possono considerarlo come straniero, fare un caso speciale o qualcosa del genere?

HTML 5 mira a essere retrocompatibile con le implementazioni di HTML 4 e XHTML 1. Non si basa su SGML o XML; la sua sintassi riguarda principalmente la documentazione e l'unione delle implementazioni. (Ecco perché <br/> <hr/>ecc. Sono HTML 5 validi nonostante siano HTML4 non validi.)

L'auto-chiusura <script>è uno dei tag in cui le implementazioni differivano. E ' abituato a lavorare in Chrome, Safari , e Opera ; per quanto ne so, non ha mai funzionato in Internet Explorer o Firefox.

Questo è stato discusso quando l'HTML 5 veniva redatto e rifiutato perché interrompeva la compatibilità del browser . Le pagine Web che tag di script con chiusura automatica potrebbero non essere visualizzate correttamente (se non del tutto) nei vecchi browser. C'erano altre proposte , ma non sono in grado di risolvere il problema di compatibilità.

Dopo il rilascio della bozza, WebKit ha aggiornato il parser per renderlo conforme.

L'auto-chiusura <script>non avviene in HTML 5 a causa della retrocompatibilità con HTML 4 e XHTML 1.

XHTML 1 / XHTML 5

Se realmente servito come XHTML, <script/>è davvero chiuso, come hanno affermato altre risposte .

Tranne che le specifiche dicono che avrebbe dovuto funzionare se servito come HTML:

I documenti XHTML ... possono essere etichettati con il tipo di supporto Internet "text / html" [RFC2854], poiché sono compatibili con la maggior parte dei browser HTML.

Allora, cos'è successo?

Le persone hanno chiesto a Mozilla di consentire a Firefox di analizzare i documenti conformi come XHTML indipendentemente dall'intestazione del contenuto specificata (nota come sniffing del contenuto ). Ciò avrebbe permesso gli script a chiusura automatica e lo sniffing dei contenuti era comunque necessario perché gli hoster web non erano abbastanza maturi per servire l'intestazione corretta; IE è stato bravo a farlo .

Se la prima guerra del browser non si è conclusa con IE 6, anche XHTML potrebbe essere stato nell'elenco. Ma è finita. E IE 6 ha un problema con XHTML. Infatti IE non supporta il tipo MIME corretto a tutti , costringendo tutti ad utilizzare text/htmlper XHTML perché IE tenuto importante quota di mercato per un intero decennio.

E anche lo sniffing dei contenuti può essere davvero negativo e la gente dice che dovrebbe essere fermato .

Infine, si scopre che il W3C non voleva che XHTML fosse sniffabile : il documento è sia HTML che XHTML e Content-Typeregole. Si può dire che stessero fermi sul "solo seguire le nostre specifiche" e ignorando ciò che era pratico . Un errore che è continuato nelle successive versioni XHTML.

Comunque, questa decisione risolse la questione per Firefox. Sono trascorsi 7 anni dalla nascita di Chrome ; non c'erano altri browser significativi. Così è stato deciso.

La specifica del solo tipo di documento non attiva l'analisi XML a causa delle seguenti specifiche.

Internet Explorer 8 e precedenti non supportano l'analisi XHTML. Anche se si utilizza una dichiarazione XML e / o un doctype XHTML, IE precedente analizza comunque il documento come semplice HTML. E in HTML semplice, la sintassi a chiusura automatica non è supportata. La barra finale è appena ignorata, devi usare un tag di chiusura esplicito.

Anche i browser con supporto per l'analisi XHTML, come IE 9 e versioni successive , analizzeranno comunque il documento come HTML a meno che non si offra il documento con un tipo di contenuto XML. Ma in quel caso il vecchio IE non visualizzerà affatto il documento!

Le persone sopra hanno già praticamente spiegato il problema, ma una cosa che potrebbe chiarire le cose è che, sebbene le persone usino <br/>e tutto il tempo nei documenti HTML, qualsiasi /in tale posizione viene sostanzialmente ignorato e usato solo quando si cerca di rendere qualcosa di analizzabile come XML e HTML. Prova <p/>foo</p>, per esempio, e ottieni un paragrafo regolare.

Il tag di script a chiusura automatica non funzionerà, poiché il tag di script può contenere codice incorporato e HTML non è abbastanza intelligente da attivare o disattivare quella funzione in base alla presenza di un attributo.

D'altra parte, HTML ha un tag eccellente per includere riferimenti a risorse esterne: il <link>tag, e può essere autochiudente. È già utilizzato per includere fogli di stile, feed RSS e Atom, URI canonici e tutti i tipi di altre chicche. Perché non JavaScript?

Se vuoi che il tag dello script sia chiuso da solo, non puoi farlo come ho detto, ma esiste un'alternativa, sebbene non intelligente. Puoi usare il tag di collegamento a chiusura automatica e collegarti al tuo JavaScript assegnandogli un tipo di testo / javascript e rel come script, qualcosa di simile al seguente:

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

A differenza di XML e XHTML, HTML non ha conoscenza della sintassi a chiusura automatica. I browser che interpretano XHTML come HTML non sanno che il /carattere indica che il tag dovrebbe essere autochiudente; invece lo interpretano come un attributo vuoto e il parser pensa ancora che il tag sia "aperto".

Proprio come <script defer>viene trattato come <script defer="defer">, <script />viene trattato come <script /="/">.

Internet Explorer 8 e meno recenti non supportano il tipo MIME corretto per XHTML, application/xhtml+xml. Se stai offrendo XHTML come text/html, cosa che devi fare per queste versioni precedenti di Internet Explorer per fare qualcosa, verrà interpretato come HTML 4.01. È possibile utilizzare la sintassi breve solo con qualsiasi elemento che consenta di omettere il tag di chiusura. Vedi le specifiche HTML 4.01 .

La "forma abbreviata" XML viene interpretata come un attributo chiamato /, che (poiché non esiste un segno di uguale) viene interpretato come avente un valore implicito di "/". Ciò è strettamente sbagliato in HTML 4.01 - gli attributi non dichiarati non sono consentiti - ma i browser lo ignoreranno.

IE9 e versioni successive supportano XHTML 5 servito con application/xhtml+xml.

Questo perché SCRIPT TAG non è un ELEMENTO VUOTO.

In un documento HTML - VOID ELEMENTS non necessita affatto di un "tag di chiusura"!

In xhtml , tutto è generico, quindi hanno tutti bisogno di terminazione, ad esempio un "tag di chiusura"; Compreso br, una semplice interruzione di riga, come <br></br>o la sua stenografia <br /> .

Tuttavia, un elemento Script non è mai un vuoto o un elemento parametrico, poiché il tag script prima di ogni altra cosa è un'istruzione del browser, non una dichiarazione di descrizione dei dati.

Principalmente, un'istruzione di terminazione semantica, ad esempio, un "tag di chiusura" è necessaria solo per l'elaborazione di istruzioni la cui semantica non può essere terminata da un tag successivo. Per esempio:

<H1>la semantica non può essere terminata da uno dei seguenti <P>perché non contiene abbastanza della propria semantica per sovrascrivere e quindi terminare il precedente set di istruzioni H1. Anche se sarà in grado di suddividere lo stream in una nuova riga di paragrafo, non è "abbastanza forte" per sovrascrivere l'attuale dimensione del font e lo stile della linea di altezza che scorre lungo lo stream , ovvero che fuoriesce da H1 (perché P non ce l'ha ).

Ecco come e perché è stata inventata la segnalazione "/" (terminazione).

Un tag di terminazione generico senza descrizione come < />, sarebbe bastato per ogni singola caduta dalla cascata incontrata, ad esempio: <H1>Title< />ma non è sempre così, perché vogliamo anche essere in grado di "annidare", tag intermedi multipli dello Stream: split in torrenti prima di avvolgere / cadere su un'altra cascata. Di conseguenza un terminatore generico come < />non sarebbe in grado di determinare la destinazione di una proprietà da terminare. Ad esempio: <b>grassetto <i>corsivo < /> corsivo </> normale. Indubbiamente non riuscirebbe a ottenere la nostra intenzione giusta e molto probabilmente la interpreterebbe come audace audace- normale audace normale.

È così che è nata l' idea di un involucro, cioè un contenitore. (Queste nozioni sono così simili che è impossibile discernere e talvolta lo stesso elemento può avere entrambe. <H1>È sia wrapper che container allo stesso tempo. Considerando <B>solo un wrapper semantico). Avremo bisogno di un contenitore semplice, senza semantica. E naturalmente è nata l'invenzione di un elemento DIV.

L'elemento DIV è in realtà un contenitore 2BR. Naturalmente l'avvento dei CSS ha reso l'intera situazione più strana di quanto non sarebbe stata altrimenti e ha causato una grande confusione con molte grandi conseguenze - indirettamente!

Poiché con CSS potresti facilmente ignorare il comportamento nativo pre e after BR di un DIV appena inventato, viene spesso definito "contenitore non fare nulla". Cioè, naturalmente sbagliato! I DIV sono elementi a blocchi e interrompono nativamente la linea del flusso sia prima che dopo la segnalazione di fine. Presto il WEB ha iniziato a soffrire della pagina DIV-itis. Molti di loro lo sono ancora.

L'avvento del CSS con la sua capacità di sovrascrivere e ridefinire completamente il comportamento nativo di qualsiasi tag HTML, in qualche modo è riuscito a confondere e confondere l'intero significato dell'esistenza HTML ...

All'improvviso tutti i tag HTML apparivano come obsoleti, venivano deturpati, spogliati di tutto il loro significato, identità e scopo originali. In qualche modo avresti l'impressione che non siano più necessari. Dire: un singolo tag wrapper contenitore sarebbe sufficiente per tutta la presentazione dei dati. Aggiungi solo gli attributi richiesti. Perché non avere invece tag significativi; Inventa i nomi dei tag mentre procedi e lascia che il CSS si preoccupi del resto.

Ecco come è nato xhtml e, naturalmente, il grande smussato, pagato così tanto dai nuovi arrivati ​​e da una visione distorta di ciò che è cosa, e qual è il maledetto scopo di tutto. Il W3C è passato dal World Wide Web a What Went Wrong, Comprades? !!

Lo scopo dell'HTML è trasmettere in streaming dati significativi al destinatario umano.

Per fornire informazioni.

La parte formale è lì solo per aiutare la chiarezza della consegna delle informazioni. xhtml non tiene in minima considerazione le informazioni. - Per esso, l'informazione è assolutamente irrilevante.

La cosa più importante in materia è sapere ed essere in grado di capire che xhtml non è solo una versione di un HTML esteso , xhtml è una bestia completamente diversa; motivi; e quindi è saggio tenerli separati.

La differenza tra "XHTML vero", "XHTML falso" e HTML, nonché l'importanza del tipo MIME inviato dal server era già stata descritta qui . Se vuoi provarlo subito, ecco un semplice frammento modificabile con anteprima dal vivo che include tag di script auto-chiuso per browser abilitati:

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>

Di Hello, true XHTML. Nice to meet you!seguito dovresti vedere textarea.

Per i browser incapaci è possibile copiare il contenuto dell'area di testo e salvarlo come file con .xhtml(o .xht) estensione ( grazie Alek per questo suggerimento ).

La risposta semplicemente moderna è perché il tag è indicato come obbligatorio in questo modo

Omissione tag Nessuno, sia il tag iniziale che quello finale sono obbligatori.

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