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


1346

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).


12
Funziona in Chrome e Opera
corymathews il

46
Alcune versioni recenti di Chrome sembrano aver risolto questo problema, i tag di script con chiusura automatica non funzionano più in Chrome
Adam Ness,

13
Non sono solo tag di script. Non credo neanche che i tag div a chiusura automatica funzionino.
DOK,

6
A partire da luglio 2011, Chrome e Firefox hanno questo problema. "Non è un bug, è una caratteristica" - davvero fastidioso.
Martin Konicek,

4
La versione più generale di questo è stato chiesto due giorni dopo: stackoverflow.com/questions/97522/...
Ciro Santilli郝海东冠状病六四事件法轮功

Risposte:


481

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)>

111
Tuttavia, "non" non è lo stesso di "non deve". Questa è una linea guida (per compatibilità, come suggerito dal titolo della sezione), non una regola.
Konrad Rudolph,

42
In realtà, non riesco a trovare alcun uso per questa restrizione :) Sembra completamente artificiale.
Squadette,

22
La risposta giusta è stata data da Olavk. L'Appendice C di XHTML 1.0 non è il motivo per cui le cose sono come sono, ma solo come aggirare le cose come stanno.
hsivonen,

32
Non è una parte normativa delle specifiche. È solo un'appendice su come gestire i browser che non supportano XHTML
Kornel,

12
Il problema <script />non è che la specifica non lo consente, ma che i browser non lo interpretano come "non-tag-soup" se il tipo di contenuto non è application / xhtml + xml. Vedi: stackoverflow.com/questions/348736/... @shabunc: browser potrebbero apparire di capirlo, ma quello che succede è che sta mettendo il contenuto dopo il <p /> all'interno del paragrafo, a causa di interpretare citazione di squadette nel senso che dal < p> non è vuoto, non può essere autochiudente. In XHTML 1.1, può essere autochiudente.
Joe,

241

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 />.


3
È corretto quindi concludere che se si elimina il supporto per IE7, l'invio di text / xml ti offrirà un ampio supporto del browser per <script />?
Chris Moschini,

7
Quindi, in breve, <script /> funzionerà solo se il tuo tipo MIME della pagina è xhtml / xml. Per le normali pagine di testo / html, non funzionerà. E se proviamo a usare il tipo MIME "xhtml / xml", si romperà la compatibilità con IE. Per riassumere, Mantieni la calma e usa <script> ... </script> Grazie Joe ;-)
Navin Israni,

1
Spiegazione eccellente. Un altro punto degno di nota è che Firefox avrà anche il .htmlrendering di file locali come tag-soup indipendentemente dai meta-tag, per motivi simili. Per i file XHTML, Firefox li renderà di conseguenza solo se hanno un nome .xhtml.
alecov

@ChrisMoschini. Probabilmente, ma usa application/xhtml+xml, no text/xml.
TRiG

167

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.


4
Sono curioso. perché il browser sceglie di interpretarlo in quel modo?
Ahmed Aeon Axan,

32
@AhmedAeonAxan: L' Pelemento non può contenere DIVelementi (si tratta di HTML non valido), quindi il browser chiude implicitamente l' Pelemento (definito come "richiudibile implicitamente") prima del DIVtag di apertura . Tuttavia, i browser tendono a comportarsi diversamente in questo senso (come possono fare con qualsiasi HTML non valido).
MrWhite,

5
@ColeJohnson No, questo non è un tag soup; greim sta confondendo il confine tra HTML valido e non valido. La zuppa di tag è ciò che ottieni quando gli autori non si preoccupano delle regole, perché i browser utilizzano la correzione degli errori. Un </p>tag di fine mancante invece è in realtà parte della definizione di HTML!
Lister,

3
@MrLister - Sorta di. "Tag soup" descrive come viene analizzato l'HTML, non come è stato creato. Era un termine usato per descrivere diverse strategie utilizzate dai browser per dare un senso all'HTML, e si contrappone al rigoroso analisi XML. L'analisi XML è consentita solo per i tipi mime XML, ma poiché quelli non hanno mai raggiunto un uso diffuso, i browser sono tornati a vari schemi di "tag soup", anche per documenti altrimenti validi.
greim

8
HTML5 in realtà ha standardizzato l'analisi di "tag soup", incluso un modo coerente per gestire il markup non valido. Fino ad allora, i browser dovevano capire da soli cosa fare con il markup non valido, causando incoerenze. Il parser HTML nei browser attuali è uno dei software più avanzati mai scritti. Incredibilmente veloce e in grado di gestire quasi tutti gli input, producendo risultati coerenti.
Stijn de Witt,

161

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.


1
@AndyE Quando scrivi <script> a chiusura automatica, i principali browser in quel momento non pensano che sia chiuso e analizzeranno l'html di sottosequenza come javascript, causando l'interruzione di HTML5 valido su questi vecchi browser. Pertanto la proposta è respinta. Questo è spiegato nella mailing list HTML5 collegata.
Sheepy,

2
@AndyE: Quello che stai descrivendo è la compatibilità diretta: la capacità del vecchio codice di funzionare con il nuovo compilatore / interprete / parser. La compatibilità con le versioni precedenti è la capacità del nuovo codice di funzionare con il vecchio compilatore / interprete / parser. Quindi sì, la compatibilità con le versioni precedenti era il problema, altrimenti le pagine scritte con le nuove specifiche in mente non funzionerebbero nei vecchi browser (e sì, è una tradizione di programmazione Web cercare di far funzionare il nuovo codice nei vecchi browser il più possibile).
Slebetman,

3
@Dmitry La realtà è che vietare la sceneggiatura chiusa è una strada a senso unico. Come legata , auto-chiuso <script> si romperà tutti i browser, gli utenti dovranno semplicemente vedere pagina vuota - console per videogiochi, Internet TV, IE 11 sul nuovo Win7 PC aziendale, milioni di runtime Java , o miliardi di smartphone. Puoi aggiornare la maggior parte di WebView della maggior parte delle lingue sulla maggior parte dei dispositivi? Se HTML5 avesse provato che avrebbero fallito come XHTML2.
Sheepy,

6
risposta molto sottovalutata
Kamil Tomšík,

2
Un po 'di correzione: i tag che sembrano funzionare da soli in HTML non sono quelli con tag di fine opzionali , ma quelli con tag di fine vietati (vuoti o vuoti, tag). I tag con tag di fine opzionali , come <p>o <li>, non possono essere "chiusi automaticamente" poiché possono avere contenuti, quindi il codice come <p/>non è altro che un tag di avvio (non valido) e il contenuto dopo di esso, se consentito in questo elemento , finirebbe al suo interno.
Ilya Streltsyn,

44

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!


9
"IE non supporta l'analisi XHTML." era vero per le versioni di IE al momento in cui è stato scritto, ma non è più vero.
EricLaw,

@EricLaw puoi chiarire quale versione di IE ha risolto questo problema? (ed eventuali condizioni specifiche - ad es. è richiesto un documento valido)
scunliffe

2
@scunliffe IE9 è stata la prima versione con pieno supporto per XHTML. blogs.msdn.com/b/ie/archive/2010/11/01/…
EricLaw,

28

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.


22

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" />

4
Mi piace, perché non è "intelligente", però?
Josh M.,

5
Perché esiste un tag di script predefinito per eseguire esattamente il lavoro di caricamento di uno script. Perché confondere le cose usando qualcos'altro? Un martello martella con le unghie .. Sarebbe intelligente usare una scarpa?
Dave Lawrence,

8
@daveL - E abbiamo <style>tag, ma utilizziamo tag link per file CSS esterni. Definizione del tag di collegamento: "Il tag <link> definisce un collegamento tra un documento e una risorsa esterna." Sembra perfettamente logico che il tag di collegamento venga utilizzato per CSS esterno o JS ... ecco a cosa serve ... il collegamento in file esterni. nota non sto parlando di spec / cross-browser / etc, sto solo commentando la natura logica dell'uso di tag di collegamento per portare sia CSS che JS ... in realtà avrebbe molto senso se fosse così . Non sono sicuro che la scarpa [analogia] si adatti.
Jimbo Jonny,

20

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 /="/">.


33
Per quanto elegante sia questa spiegazione, in realtà è sbagliata. Se fosse vero, ci sarebbe un attributo "/" per l'elemento di script nel DOM. Ho controllato IE, Firefox e Opera, e nessuno di loro in realtà contiene un tale attributo.
Alohci,

11
/ non è un carattere nome attributo valido, quindi viene scartato. Altrimenti questa spiegazione è abbastanza chiara.
hallvors - ripristina Monica il

1
In realtà, alcuni parser HTML (e in particolare i validatori) possono interpretare /come parte della costruzione NET (Null End Tag).
IllidanS4 vuole che Monica torni il

18

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.


Internet Explorer 9 supporta XHTML e Internet Explorer non è più> 51%. Potresti aggiornare la tua risposta?
Damian Yerrick,

5

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.


3

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 ).


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.