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

Question

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

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

Sólo se reconoce esto:

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

¿Esto rompe el concepto de soporte XHTML?

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

Answer 1

La especificación XHTML 1 dice:

C.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,usar <p> </p> y no <p />).

DTD XHTML especifica elementos del script como:

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

Answer 2

Para agregar a lo que Brad y Squadette han dicho, la sintaxis XML de cierre automático <script /> de hecho es 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 tipo MIME XML como application/xhtml+xml en el encabezado HTTP Content-Type (y no como text/html).

Sin embargo, enviar un tipo MIME XML hará que IE7 no analice sus páginas, a lo que sólo le gusta text/html.

De w3:

En resumen, 'Application/XHTML+XML' debe usarse para documentos familiares XHTML, y el uso de 'Text/HTML' debe limitarse a documentos XHTML 1.0 compatibles con HTML.'Aplicación/XML' y 'Text/XML' también se pueden usar, pero siempre que sea apropiado, se debe usar 'Aplicación/XHTML+XML' en lugar de esos tipos genéricos de medios XML.

Me pregunté sobre esto hace unos meses, y la única solución viable (compatible con FF3+ e IE7) era usar la antigua <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 formados correctamente, FF3+ usará su modo de representación HTML, lo que significa que <script /> no funcionará (esto es un cambio, Firefox anteriormente era menos estricto).

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

Answer 3

En caso de que alguien tenga curiosidad, la razón principal 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 la DTD como de cierre automático (p. ej.BR, HR, INPUT), implícitamente cerrables (p. ej.P, LI, TD), o explícitamente cerrables (p. ej.TABLA, DIV, GUIÓN).XML, por supuesto, no tiene idea 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 se trata como una sopa de etiquetas inspirada en SGML mal escrita, a menos que lo envíe con un tipo mime XML.Por eso también...

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

...el navegador lo interpreta como:

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

...que es la receta para un error encantador y oscuro que puede hacerte sufrir mientras intentas codificar en contra del DOM.

Answer 4

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.

---

HTML4

HTML 4 se basa en SGML.

SGML tiene algunos etiquetas cortas, 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), de modo que se convierte en <BR/>.

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

Obviamente, esto es incompatible con XHTML y voluntad romper muchos sitios (cuando los navegadores fueron lo suficientemente maduros) importar sobre esto), entonces nadie implementó etiquetas cortas y la especificación desaconsejalos.

Efectivamente, todas las etiquetas autofinalizadas que "funcionan" son etiquetas con una etiqueta final opcional en analizadores técnicamente no conformes y, de hecho, no son válidas.Fue el W3C el que se le ocurrió este truco para ayudar en la transición a XHTML haciéndolo compatible con HTML.

Y <script>La etiqueta final es no opcional.

La etiqueta "autofinalizada" es un truco en HTML 4 y no tiene sentido.

---

HTML5

HTML5 tiene cinco tipos de etiquetas y sólo se incluyen las etiquetas 'nula' y 'extranjera'. permitido cerrarse solo.

Porque <script> no es nulo (es puede tiene 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 extraño, hacer un caso especial o algo así?

HTML 5 pretende ser compatible con versiones anteriores con implementaciones de HTML 4 y XHTML 1.No está basado 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 no ser HTML4 válido.)

De cierre automático <script> es una de las etiquetas donde las implementaciones solían diferir.Él solía funcionar en Chrome, Safari, y ópera;Que yo sepa, nunca funcionó en Internet Explorer o Firefox.

esto fue discutido cuando se estaba redactando HTML 5 y fue rechazado porque se rompe 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 navegadores antiguos.Había otras propuestas, pero tampoco pueden solucionar el problema de compatibilidad.

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

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

---

XHTML 1/XHTML 5

Cuando en realidad servido como XHTML, <script/> está realmente cerrado, ya que Otras respuestas Ha establecido.

Excepto eso la especificación dice él debería han funcionado cuando se sirve como HTML:

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ó?

Gente preguntó Mozilla a deja que Firefox analice documentos conformes como HTML independientemente del encabezado de contenido especificado (conocido como oler contenido).Esto habría permitido el cierre automático de scripts y el rastreo de contenido. fue necesario de todos modos, porque los proveedores de alojamiento web no eran lo suficientemente maduros para ofrecer el encabezado correcto;Es decir, fue Bueno en eso.

Si el primera guerra de navegadores no terminó con IE 6, es posible que XHTML también haya estado en la lista.Pero terminó.y es decir 6 tiene un problema con XHTML.De hecho, es decir no apoyó el tipo MIME correcto en absoluto, forzando todos usar text/html para XHTML porque IE tenía una importante 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 decir que XHTML fuera olfateable:el documento es ambos, HTML y XHTML, y Content-Type normas.Se puede decir que se mantuvieron firmes en "simplemente seguir nuestras especificaciones" y ignorando lo que era práctico.Un error que continuado en versiones XHTML posteriores.

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

La especificación del tipo de documento por sí sola no activa el análisis XML debido a las siguientes especificaciones.

Answer 5

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 antiguo IE aún analiza el documento como HTML simple.Y en HTML simple, la sintaxis de cierre automático no es compatible.La barra diagonal simplemente se ignora; debe utilizar una etiqueta de cierre explícita.

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

Answer 6

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

Answer 7

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 excelente etiqueta para incluir referencias a recursos externos:el <link> Etiqueta, y puede ser autodenominada.Ya se usa para incluir hojas de estilo, RSS y alimentos de átomos, URI canónicos y todo tipo de otras golosinas.¿Por qué no JavaScript?

Si desea que la etiqueta del script esté autocerrada, no puede hacerlo como dije, pero existe una alternativa, aunque no inteligente.Puede usar la etiqueta de enlace de cierre automático y vincular a su JavaScript dándole un tipo de texto/javascript y rel como script, algo como lo siguiente:

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

Answer 8

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

Tal como <script defer> es tratado como <script defer="defer">, <script /> es tratado como <script /="/">.

Answer 9

Internet Explorer 8 y versiones anteriores no admiten el tipo MIME adecuado para XHTML, application/xhtml+xml.Si estás sirviendo XHTML como text/html, que es necesario para que estas versiones anteriores de Internet Explorer hagan cualquier cosa, se interpretará como HTML 4.01.Sólo puede utilizar la sintaxis corta con cualquier elemento que permita omitir la etiqueta de cierre.Ver el Especificación HTML 4.01.

La 'forma abreviada' XML se interpreta como un atributo denominado /, que (debido a que no hay signo igual) se interpreta como si tuviera 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 posteriores soporte XHTML 5 servido con application/xhtml+xml.

Answer 10

Esto se debe a que SCRIPT TAG no es un ELEMENTO NULO.

en un Documento HTML - ELEMENTOS VACIOS no ¡Necesito una "etiqueta de cierre"!

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

Sin embargo, un Elemento Script nunca es un Elemento vacío o paramétrico, porque 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 terminarse con una etiqueta siguiente.Por ejemplo:

<H1> la semántica no puede ser terminada por un siguiente <P> porque no tiene suficiente semántica propia para anular y, por lo tanto, terminar el conjunto de instrucciones H1 anterior.Aunque será capaz de romper el arroyo en una nueva línea de párrafo, no es "lo suficientemente fuerte" como para anular el tamaño de fuente y el estilo actuales cayendo por la corriente, es decir, con fugas de H1 (porque P no lo tiene).

Así es como y por qué se inventó 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" múltiples etiquetados intermediarios del Stream:dividirse en torrentes antes de envolverse / caer en otra cascada.Como consecuencia, un terminador genérico como < /> No sería posible determinar el destino de un inmueble a extinguir.Por ejemplo: <b>atrevido <i>negrita cursiva < /> itálico </>normal.Sin duda no lograríamos acertar con nuestra intención y muy probablemente la interpretaríamos como atrevido negrita-cursiva atrevido normal.

Así es como el noción de un envoltorio, es decir, nació un contenedor.(Estas nociones son tan similares que es imposible discernirlas y en ocasiones un mismo elemento puede tener ambas. <H1> es a la vez envoltorio y contenedor.Mientras <B> sólo una envoltura semántica).Necesitaremos un contenedor simple y 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 de otra manera y causó una gran confusión con muchas consecuencias importantes, ¡indirectamente!

Debido a que con CSS se puede anular fácilmente el comportamiento BR nativo previo y posterior de un DIV recién inventado, a menudo se lo denomina "contenedor sin hacer nada".¡Lo cual es naturalmente incorrecto!Los DIV son elementos de bloque y de forma nativa romperán la línea de la transmisión tanto antes como después de la señalización final.Pronto la WEB empezó a sufrir de 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 desdibujar todo el significado de la existencia de HTML...

De repente, todas las etiquetas HTML parecían obsoletas, desfiguradas, despojadas de todo su significado, identidad y propósito originales.De alguna manera tendrías la impresión de que ya no son necesarios.Dicho:Una única etiqueta contenedor-envoltorio sería suficiente para toda la presentación de datos.Simplemente agregue los atributos requeridos.¿Por qué no tener etiquetas significativas?Inventa nombres de etiquetas sobre la marcha y deja que el CSS se encargue del resto.

Así nació xhtml y por supuesto el gran contundente, tan caro pagado 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 del HTML es para transmitir datos significativos para el receptor humano.

Para entregar Información.

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

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

Answer 11

Se ha definido la diferencia entre 'XHTML verdadero', 'XHTML falso' y HTML, así como la importancia del tipo MIME enviado por el servidor. ya esta bien descrito aqui.Si desea probarlo ahora mismo, aquí tiene un fragmento editable simple con vista previa en vivo que incluye una etiqueta de secuencia de comandos cerrada automáticamente para navegadores compatibles:

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 del área de texto.

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