it-swarm-es.tech

¿Por qué no funcionan los elementos de script 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 -->

Sólo esto se reconoce:

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

¿Esto rompe el concepto de soporte de XHTML?

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

1235
dimarzionist

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

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

Sin embargo, el envío de un mimetype XML hará que IE7 no analice sus páginas, que solo le gusta text/html.

Desde w3 :

En resumen, 'application/xhtml + xml' DEBERÍA usarse para documentos de la familia XHTML, y el uso de 'text/html' DEBE limitarse a documentos XHTML 1.0 compatibles con HTML. "application/xml" y "text/xml" también PUEDEN usarse, pero siempre que sea apropiado, "application/xhtml + xml" DEBE usarse 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) fue usar la antigua sintaxis <script></script> con text/html (sintaxis HTML + HTML mimetype).

Si su servidor envía el tipo text/html 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 complicación con los meta elementos http-equiv, el prólogo XML o el tipo de documento dentro de su documento: Firefox se bifurca una vez que obtiene el encabezado text/html, que determina si el analizador HTML o XML busca dentro del documento, y el analizador HTML no entender <script />.

224
joelhardi

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, ENTRADA), 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 etiquetas usados ​​por los navegadores modernos evolucionaron fuera de este legado, aunque su modelo de análisis ya no es SGML puro. Y, por supuesto, su XHTML cuidadosamente diseñado se trata como una sopa de etiquetas inspirada en SGML mal escrita, a menos que la envíe con un tipo de mime XML. Esta es también la razón por la que ...

<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 hacerte un ataque mientras intentas codificar contra el DOM.

149
greim

Otros han respondido "cómo" y han citado espec. 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 shorttags , como <BR//, <B>text</>, <B/text/ o <OL<LI>item</LI</OL>. XML toma la primera forma, redefine el final como ">" (SGML es flexible), por lo que se convierte en <BR/>.

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

Obviamente, esto es incompatible con XHTML y will romperá muchos sitios (en el momento en que los navegadores estaban lo suficientemente maduros para cuidarsobre esto ), así que nadie implementó shorttags y el especificación aconseja contra ellos .

Efectivamente, todas las etiquetas de "finalización automática" son etiquetas con etiqueta de final opcional en analizadores técnicamente no conformes y, de hecho, son inválidas. Fue W3C el que creó este truco para ayudar a la transición a XHTML haciéndolo compatible con HTML .

Y la etiqueta final de <script> es no es opcional .

La etiqueta de "finalización automática" es un truco en HTML 4 y no tiene sentido.


HTML 5

HTML5 tiene cinco tipos de etiquetas y solo las etiquetas 'void' y 'foreign' son se permite que se cierre automáticamente .

Debido a que <script> no es nulo (tiene puede tener contenido) y no es ajeno (como MathML o SVG), <script> no puede cerrarse automáticamente, 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. es por eso que <br/><hr/> etc. son HTML válido 5 a pesar de no ser HTML4 válido).

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

Esto fue discutido cuando HTML 5 estaba siendo redactado y fue rechazado porque se rompebrowsercompatibilidad .) Las páginas que la etiqueta de script de cierre automático puede no mostrarse correctamente (en todo caso) en 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 estar en conformidad.

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


XHTML 1/XHTML 5

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

Excepto que la especificación dice it debería ha funcionado cuando se sirve como HTML:

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

¿Entonces qué pasó?

Personas se le preguntó a Mozilla a deje que Firefox analice que se ajuste a los documentos como XHTML independientemente del encabezado de contenido especificado (conocido como content sniffing )). , y el contenido olfateando era necesario de todos modos porque los hosters web no eran lo suficientemente maduros para servir el encabezado correcto; IE era bueno en eso .

Si el primera guerra del navegador no terminó con IE 6, XHTML también puede haber estado en la lista. Pero terminó. Y IE 6 tiene un problema con XHTML. De hecho IE no admitió el tipo MIME correcto en absoluto , forzando todos para usar text/html para XHTML porque IE tuvo una mayor participación de mercado durante toda una década.

Y también el contenido sniffing puede sermuy mal y la gente dice debe detenerse .

Finalmente, resulta que el W3C no significa que XHTML sea sniffable : el documento es ambos, HTML y XHTML, y Content-Type. Se puede decir que se mantuvieron firmes en "solo siga nuestras especificaciones "y ignorando lo que era práctico . Un error que continúa en versiones posteriores de XHTML.

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

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

138
Sheepy

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

Incluso los navegadores compatibles con 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!

44
JacquesB

La gente de arriba ya ha explicado bastante 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 / en tal posición es básicamente ignorado, y solo se usa cuando se intenta Para hacer algo tanto analizable como XML y HTML. Intente <p/>foo</p>, por ejemplo, y obtendrá un párrafo regular.

26
Marijn

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 etiqueta <link>, y puede cerrarse automáticamente. Ya se utiliza para incluir hojas de estilo, feeds RSS y Atom, URI canónicas y todo tipo de otras cosas. ¿Por qué no JavaScript?

Si desea que la etiqueta de script se incluya por sí misma, no puede hacerlo como dije, pero hay una alternativa, aunque no una 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, como a continuación:

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

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 lugar de eso, lo interpretan como un atributo vacío y el analizador aún cree que la etiqueta está 'abierta'.

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

19
rpetrich

Internet Explorer 8 y versiones 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 utilizar la sintaxis corta con cualquier elemento que permita omitir la etiqueta de cierre. Consulte la Especificación HTML 4.01 .

La 'forma corta' de XML se interpreta como un atributo llamado /, que (debido a que 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 los atributos no declarados, pero los navegadores lo ignorarán.

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

18
Mike Dimmick

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

En un Documento HTML - ELEMENTOS VACÍOS no necesito ¡necesito 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 nulo 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 las instrucciones cuya semántica no puede ser terminada por una etiqueta subsiguiente. Por ejemplo:

<H1> semántica no puede ser terminada por un siguiente <P> porque no tiene suficiente de su propia semántica para anular y, por lo tanto, terminar el conjunto de instrucciones H1 anterior. Aunque será capaz de dividir el flujo en una nueva línea de párrafo, no es "lo suficientemente fuerte" como para anular el tamaño de fuente actual y el estilo de línea-altura derramando el flujo , 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).

Una etiqueta genérica sin descripción terminación como < />, hubiera 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 de la secuencia: se divide en torrentes antes de envolver/caer en otra cascada. Como consecuencia, un terminador genérico como < /> no podría determinar el objetivo de una propiedad para terminar. Por ejemplo: <b> bold <i> bold-italic < /> italic </>normal. Sin duda, no lograría acertar nuestra intención y probablemente la interpretaría como negrita negrita-itálica negrita normal.

Así es como nació la noción de una envoltura, es decir, el contenedor. (Estas nociones son tan similares que es imposible de discernir y, a veces, el mismo elemento puede tener ambas. <H1> es tanto una envoltura como un contenedor al mismo tiempo. Mientras que <B> solo es una envoltura semántica). Necesitaremos un contenedor plano, sin semántica. Y, por supuesto, vino 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 grandes consecuencias, ¡indirectamente!

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

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

De repente, todas las etiquetas HTML aparecieron como si estuvieran obsoletas, fueron borradas, despojadas de todo su significado, identidad y propósito original. De alguna manera, tendrías la impresión de que ya no son necesarios. Decir: Una sola etiqueta contenedor-contenedor sería suficiente para toda la presentación de datos. Solo agrega 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, tan caro para los recién llegados y una visión distorsionada de qué es qué y cuál es el maldito propósito de todo esto. ¡El W3C pasó de la World Wide Web a What Went Wrong, camaradas?

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

Para entregar la información.

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

Lo más importante en este asunto es saber y ser capaz de comprender que xhtml no es solo una versión de algún HTML extendido , xhtml es una bestia completamente diferente; terrenos arriba y por lo tanto es sabio mantenerlos separados.

5
Bekim Bacaj

La diferencia entre 'XHTML verdadero', 'XHTML faux' y HTML, así como la importancia del tipo MIME enviado por el servidor, ha sido ya se ha descrito bien aquí . Si desea probarlo ahora mismo, aquí hay un simple fragmento editable 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 Hello, true XHTML. Nice to meet you! debajo del área de texto.

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

2
myf