javascript - resueltos - ¿Por qué no funcionan las etiquetas de script de cierre automático?
que se puede hacer con javascript (11)
¿Cuál es la razón por la que los navegadores no reconocen correctamente?
<script src="foobar.js" /> <!-- self-closing script tag -->
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 los IE (6-8 beta 2).
Eso es porque SCRIPT TAG no es un ELEMENTO VACÍO.
En un documento HTML : ¡VOID ELEMENTS no necesita una "etiqueta de cierre" en absoluto!
En xhtml , todo es genérico, por lo tanto, todos necesitan una 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, ya que 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 las instrucciones cuya semántica no puede ser terminada por una etiqueta posterior. Por ejemplo:
<H1> semántica <H1> no puede ser terminada por una <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 la secuencia en una nueva línea de párrafo, no es "lo suficientemente fuerte" como para anular el tamaño de fuente y el estilo de la línea actual que se vierte en la secuencia , es decir, tiene 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 de terminación sin descripción genérica 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 intermediario múltiple de la secuencia: dividido en torrentes antes de envolver / caer en otra cascada. Como consecuencia, un terminador genérico como < /> no podría determinar el destino de una propiedad para terminar. Por ejemplo: <b> negrita <i> negrita-cursiva < /> cursiva </> normal. Sin duda, no lograría acertar nuestras intenciones y probablemente lo interpretaría como una negrita negrita, negrita y negrita .
Así es como nació la noción de una envoltura, es decir, 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, 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 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 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í 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 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 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 saber que xhtml no es solo una versión de HTML extendido , xhtml es una bestia completamente diferente; terreno arriba y por lo tanto es sabio mantenerlos separados.
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''.
Al igual que <script defer> se trata como <script defer="defer"> , <script /> se trata como <script /="/"> .
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, las etiquetas se pueden especificar en la DTD como de cierre automático (por ejemplo, BR, HR, INPUT), se pueden cerrar de manera implícita (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 utilizados 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 elaborado 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.
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 simple. 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 versiones posteriores , seguirán analizando el documento como HTML a menos que sirva el documento con un tipo de contenido XML. Pero en ese caso, el IE antiguo no mostrará el documento en absoluto.
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 cualquier cosa, se interpretará como HTML 4.01. Solo puede utilizar la sintaxis corta con cualquier elemento que permita omitir la etiqueta de cierre. Ver 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 admiten XHTML 5 servido con application/xhtml+xml .
La diferencia entre ''XHTML verdadero'', ''XHTML faux'' y HTML, así como la importancia del tipo MIME enviado por el servidor, 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ías ver Hello, true XHTML. Nice to meet you! Hello, true XHTML. Nice to meet you! por debajo de textarea.
Para navegadores incapaces, puede copiar el contenido del área de texto y guardarlo como un archivo con .xhtml (o .xht ) ( gracias Alek por esta sugerencia )
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 está
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 etiquetas de script como:
<!-- script statements, which may include CDATA sections -->
<!ELEMENT script (#PCDATA)>
La etiqueta de script de cierre automático no funcionará, ya que 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 ser de cierre automático. 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 hacer eso 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" />
La gente de arriba ya ha explicado bastante el problema, pero una cosa que podría aclarar las cosas es que, aunque la gente use ''<br/>'' y todo el tiempo en documentos HTML , cualquier ''/'' en tal posición es básicamente se ignora, y solo se usa cuando se trata de hacer algo analizable como XML y HTML . Prueba ''<p/>foo</p>'' , por ejemplo, y obtienes un párrafo regular.
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 está basado en SGML .
SGML tiene algunas shorttags , 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 no está cerrada.)
Obviamente, esto es incompatible con XHTML y romperá muchos sitios (para cuando los navegadores estuvieran lo suficientemente maduros como para preocuparse por esto ), por lo que nadie implementó las etiquetas rápidas y la especificación desaconseja .
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 HTML-compatible .
Y la etiqueta final de <script> 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 "nulas" y "extranjeras" pueden cerrarse automáticamente .
Debido a que <script> no es nulo ( 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 backward-compatible con backward-compatible de las 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 la que <br/> <hr/> etc. son válidos HTML 5 a pesar de ser HTML4 no válido).
El <script> cierre automático es una de las etiquetas donde las implementaciones solían diferir. Solía trabajar en Chrome, Safari y Opera ; que yo sepa, nunca funcionó en Internet Explorer o Firefox.
Esto se discutió cuando HTML 5 estaba siendo redactado y fue rechazado porque breaks compatibility browser . Las páginas web que cierran automáticamente la etiqueta de script pueden no mostrarse correctamente (si las hay) en los navegadores antiguos. Hubo otras propuestas , pero tampoco pueden resolver el problema de compatibilidad.
Después de que se publicara el borrador, WebKit actualizó el analizador para que estuviera en conformidad.
El <script> 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 se sirve como XHTML, <script/> está realmente cerrado, como han indicado otras respuestas .
Excepto que la especificación dice que debería haber funcionado cuando se sirvió 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ó?
La gente le pidió a Mozilla que dejara que Firefox analizara documentos conformes como XHTML independientemente del encabezado de contenido especificado (conocido como rastreo de contenido ). Esto hubiera permitido los scripts de cierre automático, y la detección del contenido era necesaria de todos modos porque los servidores de alojamiento web no eran lo suficientemente maduros para servir el encabezado correcto; IE era bueno en eso .
Si la primera guerra de navegadores no terminó con IE 6, XHTML también podría haber estado en la lista. Pero sí terminó. Y IE 6 tiene un problema con XHTML. De hecho, IE no era compatible con el tipo MIME correcto, lo que obligaba a todos a usar text/html para XHTML porque IE tenía una importante participación de mercado durante toda una década.
Y también la inhalación de contenido puede ser realmente mala y la gente dice que se debe detener .
Finalmente, resulta que el W3C no significa que XHTML sea sniffable : el documento es a la vez , HTML y XHTML, y reglas de Content-Type . Se puede decir que se mantuvieron firmes en "solo seguir nuestras especificaciones" e ignorar lo que era práctico . Un error que continued en las últimas versiones de XHTML.
De todos modos, esta decisión resolvió el asunto para Firefox. Pasaron 7 años antes de que naciera Chrome; No hubo otro navegador significativo. Así se decidió.
La especificación del doctype solo no desencadena el análisis XML debido a las siguientes especificaciones.
Para agregar a lo que han dicho Brad y squadette, la sintaxis XML de cierre automático <script /> realidad es XML correcta, pero para que funcione en la práctica, su servidor web también necesita enviar sus documentos como XML correctamente formado con un tipo MIM XML me gusta 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, a las 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 estar limitado 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é sobre 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 Mype).
Si su servidor envía el tipo de 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 manipulación con http-equiv metaetiquetas http-equiv , el prólogo XML o el tipo de documento dentro de su documento: Firefox se bifurca una vez que obtiene el encabezado de text/html , que determina si el analizador HTML o XML busca dentro del documento, y El analizador de HTML no entiende <script /> .