¿Por qué no funcionan los elementos de script de cierre automático?

1346

¿Cuál es la razón por la cual los navegadores no reconocen correctamente:

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

Solo esto se reconoce:

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

¿Esto rompe el concepto de soporte XHTML?

Nota: Esta declaración es correcta al menos para todos los IE (6-8 beta 2).

dimarzionista
fuente
12
Funciona en Chrome y Opera
corymathews
46
Algunas versiones recientes de Chrome parecen haber roto esto, las etiquetas de script de cierre automático ya no funcionan en Chrome
Adam Ness
13
No se trata solo de etiquetas de script. Tampoco creo que las etiquetas div de cierre automático funcionen.
DOK
66
A partir de julio de 2011, Chrome y Firefox tienen este problema. "No es un error, es una característica", realmente molesto.
Martin Konicek
44
La versión más general de esto fue solicitada dos días después: stackoverflow.com/questions/97522/…
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功

Respuestas:

481

La especificación XHTML 1 dice:

С.3. Minimización de elementos y contenido de elementos vacíos

Dada una instancia vacía de un elemento cuyo modelo de contenido no es EMPTY(por ejemplo, un título o párrafo vacío) no use la forma minimizada (por ejemplo, use <p> </p>y no <p />).

XHTML DTD especifica elementos de script como:

<!-- script statements, which may include CDATA sections -->
<!ELEMENT script (#PCDATA)>
escabeche
fuente
111
Aún así, "no" no es lo mismo que "no debes". Esta es una guía (por compatibilidad, como sugiere el título de la sección), no una regla.
Konrad Rudolph el
42
En realidad, no puedo encontrar ningún uso para esta restricción :) Parece completamente artificial.
squadette
22
Olavk dio la respuesta correcta. El Apéndice C de XHTML 1.0 no es la razón por la cual las cosas son como son, sino cómo solucionar las cosas como son.
hsivonen
32
No es una parte normativa de la especificación. Es solo un apéndice sobre cómo manejar los navegadores que no son compatibles con XHTML
Kornel
12
El problema <script />no es que la especificación no lo permita, sino que los navegadores no lo interpretan como "sopa sin etiqueta" si el tipo de contenido no es application / xhtml + xml. Ver: stackoverflow.com/questions/348736/… @shabunc: puede parecer que los navegadores lo entienden, pero lo que realmente está sucediendo es que está poniendo el contenido después de <p /> dentro del párrafo, debido a la interpretación de la cita de squadette que significa que desde < p> no está vacío, no puede cerrarse automáticamente. En XHTML 1.1, puede cerrarse automáticamente.
Joe
241

Para agregar a lo que Brad y squadette han dicho, la sintaxis XML de cierre automático en <script />realidad es XML correcto, pero para que funcione en la práctica, su servidor web también necesita enviar sus documentos como XML formado correctamente con un tipo MIME XML como application/xhtml+xmlen HTTP Encabezado de tipo de contenido (y no como text/html).

Sin embargo, el envío de un tipo MIME XML hará que sus páginas no sean analizadas por IE7, que solo le gusta text/html.

De w3 :

En resumen, 'application / xhtml + xml' DEBE usarse para los documentos de la familia XHTML, y el uso de 'text / html' DEBE limitarse a los documentos XHTML 1.0 compatibles con HTML. También se PUEDE usar 'application / xml' y 'text / xml', pero cuando sea apropiado, 'application / xhtml + xml' DEBE usarse en lugar de esos tipos de medios XML genéricos.

Hace unos meses me quedé desconcertado, y la única solución viable (compatible con FF3 + e IE7) era usar la <script></script>sintaxis anterior con text/html(sintaxis HTML + tipo mime HTML).

Si su servidor envía el text/htmltipo en sus encabezados HTTP, incluso con documentos XHTML formados de otra manera, FF3 + usará su modo de representación HTML, lo que significa que <script />no funcionará (esto es un cambio, Firefox era anteriormente menos estricto).

Esto sucederá independientemente de cualquier manipulación de http-equivmeta elementos, el prólogo XML o el tipo de documento dentro de su documento: Firefox se ramifica una vez que obtiene el text/htmlencabezado, eso determina si el analizador HTML o XML se ve dentro del documento y el analizador HTML no comprende <script />.

joelhardi
fuente
3
¿Es correcto concluir que si deja de admitir IE7, el envío de texto / xml le proporcionará un amplio soporte de navegador para <script />?
Chris Moschini
77
En resumen, <script /> funcionará solo si su tipo MIME de la página es xhtml / xml. Para páginas de texto / html normales, no funcionará. Y si intentamos usar el tipo MIME "xhtml / xml", se romperá la compatibilidad con IE. Para resumir, mantenga la calma y use <script> ... </script> Gracias Joe ;-)
Navin Israni
1
Excelente explicación Otro punto que vale la pena notar es que Firefox también tendrá .htmlarchivos locales representados como una etiqueta de sopa, independientemente de las metaetiquetas, por razones similares. Para los archivos XHTML, Firefox solo los representará en consecuencia si se nombran .xhtml.
alecov
@ChrisMoschini. Probablemente, pero uso application/xhtml+xml, no text/xml.
TRiG
167

En caso de que alguien tenga curiosidad, la razón principal es que HTML fue originalmente un dialecto de SGML, que es el extraño hermano mayor de XML. En SGML-land, los elementos se pueden especificar en la DTD como de cierre automático (por ejemplo, BR, HR, INPUT), se pueden cerrar implícitamente (por ejemplo, P, LI, TD) o se pueden cerrar explícitamente (por ejemplo, TABLE, DIV, SCRIPT). XML, por supuesto, no tiene ningún concepto de esto.

Los analizadores de sopa de etiqueta utilizados por los navegadores modernos evolucionaron a partir de este legado, aunque su modelo de análisis ya no es SGML puro. Y, por supuesto, su XHTML cuidadosamente diseñado está siendo tratado como una sopa de etiqueta inspirada en SGML mal escrita a menos que la envíe con un tipo mime XML. Por eso también ...

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

... se interpreta por el navegador como:

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

... que es la receta para un encantador error oscuro que puede provocarle ataques mientras intenta codificar contra el DOM.

greim
fuente
44
Soy curioso. ¿Por qué el navegador elige interpretarlo de esa manera?
Ahmed Aeon Axan
32
@AhmedAeonAxan: el Pelemento no puede contener DIVelementos (esto es HTML no válido), por lo que el navegador cierra implícitamente el Pelemento (definido como "cerrable implícitamente") antes de la DIVetiqueta de apertura . Sin embargo, los navegadores tienden a comportarse de manera diferente a este respecto (como pueden hacerlo con cualquier HTML no válido).
MrWhite
55
@ColeJohnson No, esto no es etiqueta de sopa; greim está confundiendo la frontera entre HTML válido e inválido. La sopa de etiquetas es lo que obtienes cuando los autores no se preocupan por las reglas, porque los navegadores usan la corrección de errores. Por </p>otro lado, una etiqueta final que falta es parte de la definición de HTML.
Sr. Lister
3
@MrLister - Más o menos. "Tag soup" describe cómo se analiza HTML, no cómo se crea. Era un término usado para describir estrategias dispares que los navegadores usaban para dar sentido al HTML, y contrasta con el estricto análisis XML. El análisis XML solo está permitido para los tipos mime XML, pero dado que estos nunca lograron un uso generalizado, los navegadores recurrieron a varios esquemas de "sopa de etiquetas", incluso para documentos válidos.
greim
8
HTML5 en realidad estandarizó el análisis de 'etiqueta de sopa', incluida una forma consistente de manejar marcado no válido. Hasta entonces, los navegadores tenían que averiguar qué hacer con un marcado no válido por sí mismos, lo que causaba inconsistencias. El analizador HTML en los navegadores actuales es una de las piezas de software más avanzadas jamás escritas. Increíblemente rápido y puede manejar casi cualquier entrada, produciendo resultados consistentes.
Stijn de Witt
161

Otros han respondido "cómo" y citado especificaciones. Aquí está la verdadera historia de "por qué no <script/>", después de muchas horas de profundizar en informes de errores y listas de correo.


HTML 4

HTML 4 está basado en SGML .

SGML tiene algunas shorttags , tales como <BR//, <B>text</>, <B/text/, o <OL<LI>item</LI</OL>. XML toma la primera forma, redefine el final como ">" (SGML es flexible), para que se convierta <BR/>.

Sin embargo, el HTML no se redefinió, por lo que <SCRIPT/> debería significar <SCRIPT>> .
(Sí, el '>' debería ser parte del contenido y la etiqueta aún no está cerrada).

Obviamente, esto es incompatible con XHTML y será romper muchos sitios (por los navegadores de tiempo eran lo suficientemente maduro para cuidar de esto ), por lo que nadie se implementó shorttags y la especificación informa en contra de ellos .

Efectivamente, todas las etiquetas auto-terminadas 'que funcionan' son etiquetas con etiqueta final prohibida en analizadores técnicamente no conformes y de hecho no son válidas. Fue W3C el que creó este truco para ayudar a la transición a XHTML al hacerlo compatible con HTML .

Y <script>la etiqueta final no está prohibida .

La etiqueta "Self-ending" es un hack en HTML 4 y no tiene sentido.


HTML 5

HTML5 tiene cinco tipos de etiquetas y solo las etiquetas 'anuladas' y 'foráneas' pueden cerrarse automáticamente .

Debido a <script>que no es nulo ( puede tener contenido) y no es extraño (como MathML o SVG), <script>no se puede cerrar automáticamente, independientemente de cómo lo use.

¿Pero por qué? ¿No pueden considerarlo como extranjero, hacer un caso especial o algo así?

HTML 5 pretende ser retrocompatible con implementaciones de HTML 4 y XHTML 1. No está basado en SGML o XML; Su sintaxis se refiere principalmente a documentar y unir las implementaciones. (Es por eso que <br/> <hr/>etc. son válidos HTML 5 a pesar de ser HTML4 inválido).

El cierre automático <script>es una de las etiquetas donde las implementaciones solían diferir. Se utiliza para el trabajo en Chrome, Safari , y Opera ; Que yo sepa, nunca funcionó en Internet Explorer o Firefox.

Esto se discutió cuando se redactó HTML 5 y se rechazó porque rompe la compatibilidad del navegador . Las páginas web que cierran automáticamente la etiqueta de script pueden no mostrarse correctamente (si es que lo hacen) en navegadores antiguos. Hubo otras propuestas , pero tampoco pueden resolver el problema de compatibilidad.

Después de que se lanzó el borrador, WebKit actualizó el analizador para que cumpla con los requisitos.

El cierre automático <script>no ocurre en HTML 5 debido a la compatibilidad con HTML 4 y XHTML 1.


XHTML 1 / XHTML 5

Cuando realmente sirvió como XHTML, <script/>está realmente cerrado, como han dicho otras respuestas .

Excepto que la especificación dice que debería haber funcionado cuando se sirvió como HTML:

Los documentos XHTML ... pueden etiquetarse con el tipo de medio de Internet "text / html" [RFC2854], ya que son compatibles con la mayoría de los navegadores HTML.

¿Entonces qué pasó?

La gente le pidió a Mozilla que permitiera que Firefox analizara documentos conformes como XHTML independientemente del encabezado de contenido especificado (conocido como análisis de contenido ). Esto habría permitido secuencias de comandos de cierre automático, y el rastreo de contenido era necesario de todos modos porque los proveedores de alojamiento web no eran lo suficientemente maduros para servir el encabezado correcto; IE fue bueno en eso .

Si la primera guerra del navegador no terminó con IE 6, XHTML también podría haber estado en la lista. Pero terminó. E IE 6 tiene un problema con XHTML. De hecho IE no soporta el tipo MIME correcto en absoluto , lo que obliga a todos a utilizar text/htmlpara XHTML porque el IE celebró cuota de mercado importante para toda una década.

Y también la detección de contenido puede ser realmente mala y la gente dice que debería detenerse .

Finalmente, resulta que el W3C no significaba que XHTML fuera sniffable : el documento es ambos , HTML y XHTML, y Content-Typereglas. Se puede decir que se mantuvieron firmes en "solo seguir nuestras especificaciones" e ignorando lo que era práctico . Un error que continuó en versiones posteriores de XHTML.

De todos modos, esta decisión resolvió el asunto para Firefox. Pasaron 7 años antes de que Chrome naciera ; No había otro navegador significativo. Así se decidió.

Especificar el doctype solo no activa el análisis XML debido a las siguientes especificaciones.

Sheepy
fuente
1
@AndyE Cuando escribe <script> de cierre automático, los principales navegadores en ese momento no creen que esté cerrado y analizarán la subsecuencia html como javascript, lo que provocará que HTML5 válido se rompa en estos navegadores antiguos. Por lo tanto, la propuesta es rechazada. Esto se explica en la lista de correo HTML5 vinculada.
Sheepy
2
@AndyE: Lo que está describiendo es la compatibilidad con versiones anteriores: la capacidad del código antiguo de trabajar con un nuevo compilador / intérprete / analizador. La compatibilidad con versiones anteriores es la capacidad del nuevo código para funcionar con el antiguo compilador / intérprete / analizador. Entonces, sí, el problema era la compatibilidad con versiones anteriores, ya que de lo contrario las páginas escritas con la nueva especificación en mente no funcionarían en los navegadores antiguos (y sí, es una tradición de la programación web tratar de hacer que el nuevo código funcione tanto como sea posible en los navegadores antiguos).
slebetman
3
@Dmitry La realidad es que no permitir el guión cerrado es una calle de sentido único. Como ligado , auto-cerrado <script> romperá todos los navegadores, los usuarios simplemente ver página en blanco - consolas de videojuegos, televisión por Internet, la IE 11 en el nuevo Win7 PC corporativa, millones de ejecución de Java , o mil millones de teléfonos inteligentes. ¿Se puede actualizar la mayoría de WebView de la mayoría de los idiomas en la mayoría de los dispositivos? Si HTML5 lo intentara, habrían fallado como XHTML2.
Sheepy
66
respuesta muy subestimada
Kamil Tomšík
2
Un poco de corrección: las etiquetas que parecen funcionar como de cierre automático en HTML no son las que tienen etiquetas finales opcionales , sino las que tienen etiquetas finales prohibidas (etiquetas vacías o nulas). Las etiquetas con etiquetas finales opcionales , como <p>o <li>, no pueden 'cerrarse automáticamente' ya que pueden tener contenido, por lo que el código como <p/>no es más que una etiqueta de inicio (malformada) y el contenido después, si está permitido en este elemento , terminaría en su interior.
Ilya Streltsyn
44

Internet Explorer 8 y versiones anteriores no admiten el análisis XHTML. Incluso si utiliza una declaración XML y / o un tipo de documento XHTML, el IE antiguo aún analiza el documento como HTML sin formato. Y en HTML simple, la sintaxis de cierre automático no es compatible. Simplemente se ignora la barra inclinada final, debe usar una etiqueta de cierre explícita.

Incluso los navegadores con soporte para el análisis XHTML, como IE 9 y posterior , seguirán analizando el documento como HTML a menos que sirva el documento con un tipo de contenido XML. ¡Pero en ese caso, el antiguo IE no mostrará el documento en absoluto!

JacquesB
fuente
99
"IE no admite el análisis XHTML". era cierto para las versiones de IE en el momento en que esto se escribió, pero ya no es cierto.
EricLaw
@EricLaw, ¿puedes aclarar qué versión de IE solucionó esto? (y cualquier condición específica, p. ej., se requiere un documento válido)
scunliffe
2
@scunliffe IE9 fue la primera versión con soporte completo para XHTML. blogs.msdn.com/b/ie/archive/2010/11/01/…
EricLaw
28

Las personas de arriba ya han explicado el problema, pero una cosa que podría aclarar las cosas es que, aunque la gente usa <br/>y todo el tiempo en documentos HTML, cualquier persona /en esa posición básicamente se ignora, y solo se usa cuando se intenta algo analizable como XML y HTML. Intenta <p/>foo</p>, por ejemplo, y obtienes un párrafo regular.

Marijn
fuente
22

La etiqueta de script de cierre automático no funcionará, porque la etiqueta de script puede contener código en línea y HTML no es lo suficientemente inteligente como para activar o desactivar esa función en función de la presencia de un atributo.

Por otro lado, HTML tiene una etiqueta excelente para incluir referencias a recursos externos: la <link>etiqueta, y puede cerrarse automáticamente. Ya se usa para incluir hojas de estilo, fuentes RSS y Atom, URI canónicos y todo tipo de otras cosas. ¿Por qué no JavaScript?

Si desea que la etiqueta del script esté encerrada, no puede hacer eso como dije, pero hay una alternativa, aunque no inteligente. Puede usar la etiqueta de enlace de cierre automático y el enlace a su JavaScript dándole un tipo de texto / javascript y rel como script, algo como a continuación:

<link type="text/javascript" rel ="script" href="/path/tp/javascript" />
defau1t
fuente
44
Me gusta eso, ¿por qué no es "inteligente"?
Josh M.
55
Debido a que hay una etiqueta de secuencia de comandos predefinida para realizar exactamente el trabajo de cargar una secuencia de comandos. ¿Por qué confundiría las cosas con otra cosa? Un martillo clava clavos. ¿Sería inteligente usar un zapato?
Dave Lawrence
8
@daveL - Y tenemos <style>etiquetas, pero usamos etiquetas de enlace para archivos CSS externos. Definición de etiqueta de enlace: "La etiqueta <link> define un enlace entre un documento y un recurso externo". Parece perfectamente lógico que la etiqueta de enlace se use para CSS o JS externos ... para eso sirve ... vincular archivos externos. tenga en cuenta que no estoy hablando de especificaciones / cross-browserness / etc, solo estoy comentando sobre la naturaleza lógica del uso de etiquetas de enlace para incorporar CSS y JS ... en realidad tendría mucho sentido si fuera así . No estoy seguro de que el zapato [analogía] se ajuste.
Jimbo Jonny
20

A diferencia de XML y XHTML, HTML no tiene conocimiento de la sintaxis de cierre automático. Los navegadores que interpretan XHTML como HTML no saben que el /carácter indica que la etiqueta debe cerrarse automáticamente; en su lugar, lo interpretan como un atributo vacío y el analizador todavía piensa que la etiqueta está "abierta".

Así como <script defer>se trata como <script defer="defer">, <script />se trata como <script /="/">.

rpetrich
fuente
33
Elegante como es esta explicación, de hecho está mal. Si fuera cierto, habría un atributo "/" para el elemento de script en el DOM. He comprobado IE, Firefox y Opera, y ninguno de ellos contiene ese atributo.
Alohci
11
/ no es un carácter de nombre de atributo válido, por lo que se descarta. De lo contrario, esta explicación es bastante clara.
Sabores - Restaurar Mónica
1
En realidad, algunos analizadores HTML (y especialmente los validadores) pueden interpretarlo /como parte de la construcción de NET (etiqueta de finalización nula).
IllidanS4 quiere que Monica regrese el
18

Internet Explorer 8 y anteriores no admiten el tipo MIME adecuado para XHTML, application/xhtml+xml. Si está sirviendo XHTML como text/html, lo que debe hacer para que estas versiones anteriores de Internet Explorer hagan algo, se interpretará como HTML 4.01. Solo puede usar la sintaxis corta con cualquier elemento que permita omitir la etiqueta de cierre. Consulte la especificación HTML 4.01 .

La 'forma corta' XML se interpreta como un atributo llamado /, que (porque no hay un signo igual) se interpreta como que tiene un valor implícito de "/". Esto es estrictamente incorrecto en HTML 4.01: no se permiten atributos no declarados, pero los navegadores lo ignorarán.

IE9 y versiones posteriores son compatibles con XHTML 5 servido application/xhtml+xml.

Mike Dimmick
fuente
IE 9 es compatible con XHTML e IE ya no es> 51%. ¿Podrías actualizar tu respuesta?
Damian Yerrick
5

Eso es porque SCRIPT TAG no es un ELEMENTO ANULADO.

En un documento HTML - ¡ELEMENTOS ANULADOS no necesitan una "etiqueta de cierre" en absoluto!

En xhtml , todo es genérico, por lo tanto, todos necesitan terminación, por ejemplo, una "etiqueta de cierre"; Incluyendo br, un simple salto de línea, como <br></br>o su taquigrafía <br /> .

Sin embargo, un elemento de secuencia de comandos nunca es un elemento vacío o paramétrico, porque la etiqueta de secuencia de comandos antes que nada, es una instrucción del navegador, no una declaración de descripción de datos.

Principalmente, una instrucción de terminación semántica, por ejemplo, una "etiqueta de cierre" solo es necesaria para procesar instrucciones cuya semántica no puede ser terminada por una etiqueta posterior. Por ejemplo:

<H1>la semántica no puede ser terminada por un siguiente <P>porque no tiene suficiente semántica para anular y, por lo tanto, terminar el conjunto de instrucciones H1 anterior. Aunque será capaz de dividir la secuencia en una nueva línea de párrafo, no es "lo suficientemente fuerte" como para anular el tamaño de fuente actual y la altura de línea del estilo que fluye por la secuencia , es decir, se filtra desde H1 (porque P no lo tiene) )

Así es como y por qué se ha inventado la señalización "/" (terminación).

Una etiqueta de terminación genérica sin descripción< /> , como , habría bastado para cualquier caída de la cascada encontrada, por ejemplo: <H1>Title< />pero ese no es siempre el caso, porque también queremos ser capaces de "anidar", etiquetado intermedio múltiple de Stream: split en torrentes antes de envolver / caer en otra cascada. Como consecuencia, un terminador genérico como el < />que no podría determinar el objetivo de una propiedad para terminar. Por ejemplo: <b>negrita <i>negrita-cursiva < /> cursiva </> normal. Indudablemente, fallaría en acertar nuestra intención y probablemente la interpretaría como negrita negrita-itálica negrita normal.

Así es como nació la noción de envoltura, es decir, contenedor. (Estas nociones son tan similares que es imposible discernir y, a veces, el mismo elemento puede tener ambos. <H1>Es envoltorio y contenedor al mismo tiempo. Mientras que <B>solo es un envoltorio semántico). Necesitaremos un contenedor simple, sin semántica. Y, por supuesto, surgió la invención de un elemento DIV.

El elemento DIV es en realidad un contenedor 2BR. Por supuesto, la llegada de CSS hizo que la situación fuera más extraña de lo que hubiera sido de otra manera y causó una gran confusión con muchas grandes consecuencias, ¡indirectamente!

Debido a que con CSS puede anular fácilmente el comportamiento nativo previo y posterior de BR de un DIV recién inventado, a menudo se lo denomina "contenedor de no hacer nada". Lo cual es, naturalmente, incorrecto! Los DIV son elementos de bloque y romperán de forma nativa la línea del flujo tanto antes como después de la señalización final. Pronto la WEB comenzó a sufrir de la página DIV-itis. La mayoría de ellos todavía lo son.

La llegada de CSS con su capacidad de anular y redefinir completamente el comportamiento nativo de cualquier etiqueta HTML, de alguna manera logró confundir y difuminar todo el significado de la existencia HTML ...

De repente, todas las etiquetas HTML aparecieron como obsoletas, fueron desfiguradas, despojadas de todo su significado, identidad y propósito originales. De alguna manera, obtendrás la impresión de que ya no son necesarios. Dicho: una sola etiqueta contenedor-envoltorio sería suficiente para toda la presentación de datos. Simplemente agregue los atributos requeridos. ¿Por qué no tener etiquetas significativas en su lugar? Inventa nombres de etiquetas a medida que avanzas y deja que el CSS se moleste con el resto.

Así es como nació xhtml y, por supuesto, el gran contundente, pagado tan caro por los recién llegados y una visión distorsionada de qué es qué y cuál es el maldito propósito de todo. El W3C pasó de la World Wide Web a ¿Qué salió mal, camaradas?

El propósito de HTML es transmitir datos significativos al destinatario humano.

Para entregar información.

La parte formal está ahí solo para ayudar a la claridad de la entrega de información. xhtml no da la más mínima consideración a la información. - Para ello, la información es absolutamente irrelevante.

Lo más importante en el asunto es saber y poder entender que xhtml no es solo una versión de un HTML extendido , xhtml es una bestia completamente diferente; molido y por lo tanto es sabio mantenerlos separados.

Bekim Bacaj
fuente
3

La diferencia entre 'verdadero XHTML', 'falso XHTML' y HTML, así como la importancia del tipo MIME enviado por el servidor, ya se han descrito aquí bien . Si desea probarlo ahora, aquí hay un fragmento editable simple con vista previa en vivo que incluye una etiqueta de script de cierre automático para navegadores capaces:

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>

Debería ver a Hello, true XHTML. Nice to meet you!continuación el área de texto.

Para navegadores incapaces, puede copiar el contenido del área de texto y guardarlo como un archivo con .xhtml(o .xht) extensión ( gracias Alek por esta sugerencia ).

mi f
fuente