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

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

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

Solo esto se reconoce:

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

¿Rompe esto el concepto de compatibilidad con XHTML?

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

preguntado el 16 de septiembre de 08 a las 04:09

Funciona en Chrome y Opera -

Alguna versión reciente de Chrome parece haber roto esto, las etiquetas de script de cierre automático ya no funcionan en Chrome -

No se trata solo de etiquetas de script. Tampoco creo que las etiquetas div de cierre automático funcionen. -

En julio de 2011, Chrome y Firefox tenían este problema. "No es un error, es una característica", realmente molesto. -

La versión más general de esto se preguntó dos días después: stackoverflow.com/questions/97522/… -

12 Respuestas

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 utilice la forma minimizada (por ejemplo, utilice <p> </p> y no <p />).

DTD XHTML especifica elementos de secuencia de comandos como:

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

Respondido 09 Abr '19, 04:04

Aún así, "no" no es lo mismo que "no debo". Esta es una guía (por compatibilidad, como sugiere el título de la sección), no una regla. - Konrad Rodolfo

En realidad, no puedo encontrar ningún uso para esta restricción :) Parece completamente artificial. - escudete

Olavk dio la respuesta correcta. El Apéndice C de XHTML 1.0 no es la razón por la que las cosas son como son, sino simplemente cómo solucionar las cosas como son. - hsivonen

No es una parte normativa de la especificación. Es solo un apéndice sobre cómo manejar los navegadores que no es compatible con XHTML - Cornell

El problema con <script /> no es que la especificación lo prohíba, sino que los navegadores no lo interpretan como "sopa sin etiquetas" si el tipo de contenido no es application / xhtml + xml. Ver: stackoverflow.com/questions/348736/… @shabunc: los navegadores pueden Aparecer entenderlo, pero lo que en realidad está sucediendo es poner el contenido después de la dentro el párrafo, debido a la interpretación de la cita de Squadette en el sentido de que desde no está vacío, no se puede cerrar automáticamente. En XHTML 1.1, puede ser autocierre. - Joe

Para agregar a lo que han dicho Brad y Squadette, la sintaxis XML de cierre automático <script /> Realmente is XML correcto, pero para que funcione en la práctica, su servidor web también necesita enviar sus documentos como XML correctamente formado con un XML mimetype como application/xhtml+xml en el encabezado HTTP Content-Type (y no as text/html).

Sin embargo, enviar un mimetype 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 documentos de la familia XHTML, y el uso de 'text / html' DEBE limitarse a documentos XHTML 1.0 compatibles con HTML. También PUEDEN usarse 'application / xml' y 'text / xml', pero siempre que sea apropiado, DEBERÍA usarse 'application / xhtml + xml' en lugar de esos tipos de medios XML genéricos.

Me desconcerté por esto hace unos meses, y la única solución viable (compatible con FF3 + e IE7) era usar el antiguo <script></script> sintaxis con text/html (Sintaxis HTML + tipo mime HTML).

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

Esto sucederá independientemente de cualquier manipulación http-equiv meta elementos, el prólogo XML o doctype dentro de su documento - Firefox se ramifica una vez que obtiene el text/html encabezado, que determina si el analizador HTML o XML busca dentro del documento, y el analizador HTML no comprende <script />.

Respondido 09 Abr '19, 04:04

¿Es correcto entonces concluir que si abandona el soporte para IE7, el envío de texto / xml le brindará un amplio soporte del navegador para ? - chris moschini

Entonces, en resumen, will work only if your MIME type of the page is xhtml/xml. For regular text/html pages, it won't work. AND if we do try to use "xhtml/xml" MIME type, it will break IE compatibility. To summarize, Keep Calm and Use ... Gracias Joe ;-) - Navin Israelí

Excelente explicación. Otro punto que vale la pena señalar es que Firefox también tendrá local .html archivos renderizados como una sopa de etiquetas independientemente de las metaetiquetas, por razones similares. Para los archivos XHTML, Firefox solo los renderizará en consecuencia si tienen un nombre .xhtml. - alecov

@ChrisMoschini. Probablemente, pero usa application/xhtml+xmlno, text/xml. - Trigonometría

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

Los analizadores de sopa de etiquetas 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 elaborado está siendo tratado como una sopa de etiquetas inspirada en SGML mal escrita a menos que lo envíe con un tipo XML mime. Por eso también ...

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

... es interpretado por el navegador como:

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

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

Respondido 13 Feb 20, 03:02

Soy curioso. ¿Por qué el navegador elige interpretarlo de esa manera? - Ahmed Aeón Axan

@AhmedAeonAxan: El P el elemento no puede contener DIV elementos (esto es HTML inválido), por lo que el navegador implícitamente cierra el P elemento (definido como "que se puede cerrar implícitamente") antes de la apertura DIV etiqueta. Sin embargo, los navegadores tienden a comportarse de manera diferente a este respecto (como pueden hacerlo con cualquier HTML no válido). - MrWhite

@ColeJohnson No, esto no es sopa de etiquetas; greim está confundiendo el límite entre HTML válido y no válido. La sopa de etiquetas es lo que se obtiene cuando los autores no se preocupan por las reglas, porque los navegadores utilizan la corrección de errores. Un desaparecido </p> Por otro lado, la etiqueta final es en realidad parte de la definición de HTML. - Señor lister

@MrLister - Más o menos. La "sopa de etiquetas" describe cómo se analiza HTML, no cómo se crea. Era un término utilizado para describir estrategias dispares que los navegadores utilizaban para dar sentido a HTML, y contrasta con el análisis estricto de XML. El análisis de XML solo está permitido para tipos XML mime, pero dado que estos nunca lograron un uso generalizado, los navegadores recurrieron a varios esquemas de "sopa de etiquetas", incluso para documentos válidos. - verde

HTML5 en realidad estandarizado el análisis de 'sopa de etiquetas', incluida una forma coherente de manejar el marcado no válido. Hasta entonces, los navegadores tenían que averiguar qué hacer con el marcado no válido por sí mismos, lo que provocaba inconsistencias. El analizador de 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

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


HTML 4

HTML 4 se basa en SGML.

SGML tiene algunos etiquetas cortas, Tales como <BR//, <B>text</>, <B/text/o <OL<LI>item</LI</OL>. XML toma la primera forma, redefine la terminación como ">" (SGML es flexible), por lo que se convierte en <BR/>.

Sin embargo, HTML no se perfeccionó, por lo que <SCRIPT/> debemos personalizado <SCRIPT>>.
(Sí, el '>' debería ser parte del contenido y la etiqueta todavía no cerrado.)

Obviamente, esto es incompatible con XHTML y detectarás romper muchos sitios (cuando los navegadores eran lo suficientemente maduros importar sobre este), asi que nadie implementó etiquetas cortas y la especificación advierte en contra de ellos.

Efectivamente, todas las etiquetas de terminación automática "en funcionamiento" son etiquetas con etiqueta de fin prohibida en analizadores que no cumplen técnicamente y, de hecho, no son válidas. Fue el W3C el que se le ocurrió este truco para ayudar con la transición a XHTML haciéndolo Compatible con HTML.

Y <script>La etiqueta final es no prohibido.

La etiqueta "Auto-finalizada" es un truco en HTML 4 y no tiene sentido.


HTML 5

HTML5 tiene cinco tipos de etiquetas y solo las etiquetas 'void' y 'extranjeras' son permitido ser de cierre automático.

Porque <script> no es nulo puede tienen contenido) y no es ajeno (como MathML o SVG), <script> no se puede cerrar por sí mismo, independientemente de cómo lo use.

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

HTML 5 pretende ser compatible con versiones anteriores con implementaciones de HTML 4 y XHTML 1. No se basa en SGML o XML; su sintaxis se ocupa principalmente de documentar y unir las implementaciones. (Esta es la razón por <br/> <hr/> etc. son HTML 5 válido a pesar de ser HTML4 no válido).

De cierre automático <script> es una de las etiquetas en las que las implementaciones solían diferir. Eso solía trabajar en Chrome, Safari, y Opera; que yo sepa, nunca funcionó en Internet Explorer o Firefox.

Esto fue discutido cuando HTML 5 se estaba redactando y fue rechazado porque rompe cada navegador compatibilidad. Es posible que las páginas web con etiquetas de script de cierre automático no se muestren correctamente (si es que lo hacen) en los navegadores antiguos. Había otras propuestas, pero tampoco pueden resolver el problema de compatibilidad.

Después de que se publicó el borrador, WebKit actualizó el analizador para que se ajustara.

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


XHTML 1 / XHTML 5

Cuándo democracia servido como XHTML, <script/> está realmente cerrado, ya que Otras respuestas Ha establecido.

Excepto eso la especificación dice it debemos han funcionado cuando se sirven como HTML:

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

¿Entonces qué pasó?

Soluciones preguntó Mozilla a deja que Firefox analice conformando documentos como XHTML independientemente del encabezado de contenido especificado (conocido como olfateo de contenido). Esto habría permitido scripts de cierre automático y rastreo de contenido. fue necesario de todos modos porque los proveedores de alojamiento web no eran lo suficientemente maduros para publicar el encabezado correcto; IE fue Bueno en eso.

Si primera guerra del navegador no terminó con IE 6, es posible que XHTML también haya estado en la lista. Pero terminó. Y IE 6 tiene un problema con XHTML. De hecho IE no fue compatible el tipo MIME correcto en absolutoforzando todos que se utilizará text/html para XHTML porque IE mantuvo mayor cuota de mercado durante toda una década.

Y también olfatear contenido puede ser Muy mal y la gente dice debería ser detenido.

Finalmente, resulta que el W3C no quería que XHTML fuera sniffable: el documento es ambas, HTML y XHTML, y Content-Type reglas. Se puede decir que se mantuvieron firmes en "solo siga nuestras especificaciones" y ignorando lo que era práctico. Un error que continuado en versiones posteriores de XHTML.

De todos modos, esta decisión resolvió el asunto para Firefox. Pasaron 7 años antes de que Chrome nació; no había ningún otro navegador importante. Así se decidió.

Especificar el tipo de documento por sí solo no activa el análisis de XML debido a las siguientes especificaciones.

Respondido el 23 de Septiembre de 19 a las 11:09

@AndyE Cuando escribes con cierre automático , the major browsers at that time do not think it is closed, and will parse the subsequence html as javascript, causing valid HTML5 to break on these old browsers. Thus the proposal is rejected. This is explained in the linked HTML5 mailing list. - Sheepy

@AndyE: Lo que está describiendo es compatibilidad con versiones posteriores: la capacidad del código antiguo para funcionar con un nuevo compilador / intérprete / analizador. La compatibilidad con versiones anteriores es la capacidad de un código nuevo para trabajar con un compilador / intérprete / analizador antiguo. Así que 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 navegadores antiguos (y sí, es una tradición de programación web intentar hacer que el nuevo código funcione en navegadores antiguos tanto como sea posible) - dormilón

@Dmitry La realidad es que rechazar un guión autocerrado es una calle de sentido único. Como vinculado, auto cerrado will break todos navegadores, los usuarios simplemente verán una página en blanco: consolas de juegos, TV por Internet, el IE 11 en el Un nuevo PC corporativa Win7, millones de Tiempo de ejecución de Javao miles de millones de teléfonos inteligentes. ¿Puede actualizar la mayoría de WebView de la mayoría de los idiomas en la mayoría de los dispositivos? Si HTML5 lo hubiera intentado, habrían fallado como XHTML2. - Sheepy

respuesta muy subestimada - Kamil Tomšík

Un poco de corrección: las etiquetas que parecen funcionar como autocerradas en HTML no son las que tienen opcional etiquetas finales, pero las que tienen prohibidos etiquetas finales (etiquetas vacías o nulas). Etiquetas con opcional etiquetas finales, como <p> or <li>, no puede ser 'auto cerrado' ya que puede tener contenido, así que codifique como <p/> no es más que una etiqueta de inicio (mal formada) y el contenido posterior, si está permitido en este elemento, terminaría dentro de ella. - Ilya Streltsyn

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

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

Respondido el 05 de enero de 21 a las 17:01

"IE no admite el análisis de XHTML". era cierto para las versiones de IE en el momento en que se escribió esto, pero ya no es cierto. - EricLaw

@EricLaw ¿puede aclarar qué versión de IE solucionó esto? (y cualquier condición específica, por ejemplo, se requiere un tipo de documento válido) - scunliffe

@scunliffe IE9 fue la primera versión con soporte completo para XHTML. blogs.msdn.com/b/ie/archive/2010/11/01/… - EricLaw

Las personas anteriores ya han explicado bastante el problema, pero una cosa que podría aclarar las cosas es que, aunque la gente usa <br/> y tal todo el tiempo en documentos HTML, cualquier / en tal posición se ignora básicamente y solo se usa cuando se intenta hacer algo tanto analizable como XML y HTML. Intentar <p/>foo</p>, por ejemplo, y obtiene un párrafo normal.

contestado el 06 de mayo de 19 a las 15:05

La etiqueta de secuencia de comandos de cierre automático no funcionará, porque la etiqueta de secuencia de comandos 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: el <link> etiqueta, y puede ser de cierre automático. Ya se usa para incluir hojas de estilo, feeds RSS y Atom, URI canónicos y todo tipo de otros beneficios. ¿Por qué no JavaScript?

Si desea que la etiqueta de secuencia de comandos se adjunte a sí misma, 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="/es/path/tp/javascript" />

Respondido 22 Abr '14, 09:04

Me gusta eso, ¿por qué no es "inteligente"? - Josh M.

Porque hay una etiqueta de secuencia de comandos predefinida para realizar exactamente el trabajo de cargar una secuencia de comandos. ¿Por qué confundirías las cosas con otra cosa? Un martillo martilla en clavos. ¿Sería inteligente usar un zapato? - david lorenzo

@daveL - Y tenemos <style> etiquetas, pero utilice etiquetas de enlace para archivos CSS externos. Definición de etiqueta de enlace: "La etiqueta define un vínculo 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 es ... enlazar en archivos externos. nota No estoy hablando de especificaciones / navegación cruzada / etc., solo estoy comentando sobre la naturaleza lógica del uso de etiquetas de enlace para incorporar tanto CSS como JS ... en realidad tendría mucho sentido si fuera así. No estoy seguro de que el zapato [analogía] le quede bien. - jimbo jonny

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> es tratado como <script defer="defer">, <script /> es tratado como <script /="/">.

Respondido 27 Jul 15, 12:07

Por elegante que sea esta explicación, de hecho es incorrecta. Si fuera cierto, habría un atributo "/" para el elemento de secuencia de comandos en el DOM. He comprobado IE, Firefox y Opera, y ninguno de ellos contiene ese atributo. - Alohci

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

En realidad, algunos analizadores HTML (y especialmente validadores) pueden interpretar el / como parte de la construcción NET (Null End Tag). - IS4

Internet Explorer 8 y versiones anteriores no admiten el tipo MIME adecuado para XHTML, application/xhtml+xml. Si está sirviendo XHTML como text/html, que tiene que 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. Ver el Especificación HTML 4.01.

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

IE9 y posterior soporte XHTML 5 servido con application/xhtml+xml.

Respondido el 05 de enero de 21 a las 17:01

IE 9 es compatible con XHTML e IE ya no es> 51%. ¿Podrías actualizar tu respuesta? - Damián Yerrick

Eso es porque SCRIPT TAG no es un ELEMENTO VACÍO.

En una Documento HTML - ELEMENTOS ANULADOS no ¡Necesita una "etiqueta de cierre" en absoluto!

In 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 script nunca es un elemento vacío o paramétrico, porque etiqueta de script antes que nada, es una instrucción del navegador, no una declaración de descripción de datos.

Básicamente, una instrucción de terminación semántica, por ejemplo, una "etiqueta de cierre" sólo se necesita para procesar instrucciones cuya semántica no puede terminar con 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 podrá romper el corriente en una nueva línea de párrafo, no es "lo suficientemente fuerte" para anular el tamaño de fuente actual y el estilo de la altura de la línea derramando corriente abajo, es decir, con fugas de H1 (porque P no lo tiene).

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

Un genérico Sin descripción etiqueta de terminación como < />, habría sido suficiente 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 del Stream: dividir en torrents antes de envolver / caer en otra cascada. Como consecuencia, un terminador genérico como < /> no sería capaz de determinar el destino de una propiedad para terminar. Por ejemplo: <b> <i>negrita cursiva < /> itálico </>normal. Indudablemente fallaría en lograr nuestra intención correcta y lo más probable es que la interprete como negrita-itálica Normal.

Así es como el noción de una envoltura, es decir, nació un 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 una envoltura semántica). Necesitaremos un contenedor simple, sin semántica. Y, por supuesto, llegó la invención de un elemento DIV.

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

Debido a que con CSS puede anular fácilmente el comportamiento de BR nativo antes y después de un DIV recién inventado, a menudo se lo conoce como un "contenedor de no hacer nada". ¡Lo cual es, naturalmente, incorrecto! Los DIV son elementos de bloque y, de forma nativa, romperán la línea del flujo antes y después de la señalización de finalización. 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 para anular y redefinir completamente el comportamiento nativo de cualquier etiqueta HTML, de alguna manera logró confundir y difuminar todo el significado de la existencia de 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, daría la impresión de que ya no los necesita. Decir: Una sola etiqueta de envoltura de contenedor sería suficiente para toda la presentación de datos. Simplemente agregue los atributos requeridos. ¿Por qué no tener etiquetas significativas en su lugar? Invente nombres de etiquetas sobre la marcha y deje que el CSS se preocupe por el resto.

Así 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 para transmitir datos significativos para el receptor humano.

Para entregar información.

La parte formal está ahí solo para ayudar a la claridad de la entrega de información. xhtml no le da la menor consideración a la información. - Para él, la información es absolutamente irrelevante.

Lo más importante en la materia es saber y poder entender que xhtml no es solo una versión de HTML extendido, xhtml es una bestia completamente diferente; fundamento y por lo tanto es aconsejable mantenerlos separados.

Respondido el 09 de diciembre de 17 a las 01:12

La diferencia entre "XHTML verdadero", "XHTML falso" y HTML, así como la importancia del tipo MIME enviado por el servidor, se ha ya descrito aquí bien. Si desea probarlo ahora mismo, aquí hay un fragmento editable simple con vista previa en vivo que incluye una etiqueta de script autocerrada 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 Hello, true XHTML. Nice to meet you! debajo de textarea.

Para los 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 pista).

Respondido 27 Abr '18, 11:04

La respuesta simplemente moderna es porque la etiqueta se denota como obligatoria de esa manera

Omisión de etiqueta Ninguna, tanto la etiqueta inicial como la final son obligatorias.

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

respondido 10 nov., 19:14

No es la respuesta que estás buscando? Examinar otras preguntas etiquetadas or haz tu propia pregunta.