Pregunta ¿Por qué no funcionan las etiquetas 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 tag -->

Solo esto es reconocido:

<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).


1155
2017-09-16 06:52


origen


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 use el formulario minimizado (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)>

419
2017-09-16 07:08



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

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

De w3:

En resumen, 'application / xhtml + xml'   DEBE ser utilizado para la familia XHTML   documentos y el uso de 'text / html'   DEBERÍA estar limitado a HTML compatible   Documentos XHTML 1.0. 'application / xml'   y 'text / xml' PUEDE también ser utilizado, pero   cuando sea apropiado,   'application / xhtml + xml' DEBE ser utilizado   en lugar de esos medios XML genéricos   tipos.

Me sorprendió esto hace unos meses, y la única solución factible (compatible con FF3 + e IE7) era usar el viejo <script></script> sintaxis con text/html (Sintaxis HTML + tipo mimet HTML).

Si su servidor envía el text/html escriba 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 anteriormente era menos estricto).

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


211
2017-09-16 08:14



En caso de que alguien tenga curiosidad, la razón última es que HTML era originalmente un dialecto de SGML, que es el extraño hermano mayor de XML. En SGML-land, las etiquetas pueden especificarse en la DTD como autocierre (por ejemplo, BR, HR, ENTRADA), implícitamente cerrable (por ejemplo, P, LI, TD), o pueden cerrarse 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 a partir de este legado, aunque su modelo de análisis ya no es puro SGML. Y, por supuesto, su XHTML cuidadosamente diseñado está siendo tratado como una sopa de etiquetas inspirada en SGML mal escrita a menos que lo envíe con un tipo de mimo XML. Esto también es por qué ...

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

... es interpretado por el navegador como:

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

... que es la receta de un encantador y oscuro error que puede provocar ataques mientras intentas codificar contra el DOM.


140
2017-07-25 02:52



Otros han respondido "cómo" y las especificaciones citadas. Aquí está la historia real 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, 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 reescribió, entonces <SCRIPT/>  debería media  <SCRIPT>>.
(Sí, el '>' debe ser parte del contenido, y la etiqueta aún está no cerrado.)

Obviamente, esto es incompatible con XHTML y será romper muchos sitios (en el momento en que los navegadores eran lo suficientemente maduros importar  sobre esto), asi que nadie implementó shorttags y la especificación aconseja contra ellos.

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

Y <script>La etiqueta final es no opcional.

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


HTML 5

HTML5 tiene cinco tipos de etiquetas y solo etiquetas 'vacías' y 'extranjeras' son permitido ser de cierre automático.

Porque <script> no es nulo ( mayo tener contenido) y no es extranjero (como MathML o SVG), <script> no se puede cerrar automáticamente, independientemente de cómo lo use.

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

HTML 5 tiene como objetivo 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 válido 5 a pesar de ser HTML4 no válido.)

De cierre automático <script> es una de las etiquetas donde las implementaciones solían ser diferentes. 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 estaba siendo redactado y fue rechazado porque descansos  navegador  compatibilidad. Es posible que las páginas web que cierran automáticamente la etiqueta del script no se muestren correctamente (si es que lo hacen) en navegadores antiguos. Había otras propuestas, pero tampoco pueden resolver el problema de compatibilidad.

Después de que se lanzó el borrador, WebKit actualizó el analizador para que fuera conforme.

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

Cuando De Verdad servido como XHTML, <script/> está realmente cerrado, como Otras respuestas Ha establecido.

Excepto eso la especificación dice eso debería funcionó cuando se sirvió como HTML:

Los documentos XHTML ... pueden estar etiquetados 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 XHTML independientemente del encabezado de contenido especificado (conocido como sniffing de contenido) Esto hubiera permitido secuencias de comandos de cierre automático y olfateo de contenido fue necesario de todos modos porque los web hosters no fueron lo suficientemente maduros para servir el encabezado correcto; IE fue Bueno en eso.

Si el primera guerra de navegadores no terminó con IE 6, XHTML puede haber estado en la lista también. Pero terminó. Y IE 6 tiene un problema con XHTML. De hecho, IE no fue compatible el tipo MIME correcto en absolutoforzando todo el mundo usar text/html para XHTML porque IE tenía una gran cuota de mercado por una década completa.

Y también contenido sniffing puede ser  Muy mal y la gente dice debe ser detenido.

Finalmente, resulta que el W3C no significaba XHTML para ser olfateable: el documento es ambos, HTML y XHTML, y Content-Type reglas. Se puede decir que se mantuvieron firmes en "solo seguir 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 otro navegador significativo. Por lo tanto, fue decidido.

Especificar el tipo de documento solo no desencadena el análisis XML debido a las siguientes especificaciones.


123
2018-02-25 12:37



Internet Explorer 8 y versiones anteriores no son compatibles con el análisis XHTML. Incluso si usa una declaración XML y / o un doctype XHTML, el viejo IE todavía analiza el documento como HTML simple. Y en HTML sin formato, la sintaxis de cierre automático no es compatible. La barra inclinada final se ignora, debe usar una etiqueta de cierre explícita.

Incluso navegadores compatibles con el análisis XHTML, como IE 9 y posterior, aún analizará el documento como HTML a menos que sirva el documento con un tipo de contenido XML. ¡Pero en ese caso, el viejo IE no mostrará el documento en absoluto!


43
2017-09-16 08:00



Las personas de arriba ya explicaron bastante el problema, pero una cosa que podría aclarar las cosas es que, aunque la gente usa '&lt;br/>' y todo el tiempo en HTML documentos, cualquier '/' en tal posición se ignora básicamente, y solo se usa cuando se trata de hacer algo que sea parseable como XML y HTML. Tratar '&lt;p/>foo&lt;/p>', por ejemplo, y obtienes un párrafo regular.


25
2017-09-16 13:07



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: el <link>etiqueta, y puede ser   de cierre automático. Ya se usa para incluir hojas de estilo, RSS y Atom   alimentaciones, URIs canónicos y todo tipo de otras cosas. Por qué no   JavaScript?

Si quiere 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" />

23
2017-10-27 09:35



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 ser de cierre automático; en su lugar, lo interpretan como un atributo vacío y el analizador aún cree que la etiqueta es 'abierta'.

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


19
2017-09-16 07:10



Internet Explorer 8 y anteriores no son compatibles con el tipo MIME adecuado para XHTML, application/xhtml+xml. Si está sirviendo XHTML como text/html, lo cual tiene que hacer para que estas versiones anteriores de Internet Explorer hagan cualquier cosa, 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 corta' 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: 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.


18
2017-09-16 12:48



La diferencia entre 'XHTML verdadero', 'falso XHTML' y HTML, así como la importancia del tipo MIME enviado por el servidor había sido ya descrito aquí bien. Si desea probarlo ahora mismo, aquí tiene un fragmento de código editable simple con vista previa en vivo, que incluye la etiqueta de secuencia de comandos cerrada automáticamente para navegadores con capacidad:

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)


3
2017-11-22 00:25



Eso es porque SCRIPT TAG no es un ELEMENTO DE ANULACIÓN.

En una Documento HTML - ELEMENTOS DE ANULACIÓN no haga necesita una "etiqueta de cierre" en absoluto!

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 es taquigrafía  <br />.

Sin embargo, un elemento de guión nunca es un elemento vacío o paramétrico, porque etiqueta de script antes que nada, es una Instrucción de 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 las instrucciones de procesamiento, cuya semántica no puede ser terminada por una etiqueta siguiente. Por ejemplo:

<H1> la 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, finalizar 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 la línea de estilo-altura vertiendo por la corriente, es decir, fuga de H1 (porque P no la 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", el etiquetado intermedio múltiple del Stream: dividido en torrents 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>negrita  <i>negrita cursiva  < />  itálico  </>normal. Sin duda, no conseguiríamos nuestra intención correcta y probablemente la interpretaríamos como negrita bold-itallic negrita normal.

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

El elemento DIV es en realidad un contenedor de 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 puede anular fácilmente el comportamiento de pre y post BR de una DIV recién inventada, 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 antes y 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 para anular por completo y redefinir por completo 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, obtendrías la impresión de que ya no son necesarios. Diciendo: una sola etiqueta contenedor-envoltura 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 los nombres de las etiquetas a medida que avanzas y deja que CSS se preocupe por el resto.

Así es como nació xhtml y, por supuesto, el gran embotado, 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 esto. El W3C pasó de la World Wide Web a What Went Wrong, Camaradas? !!

El propósito de HTML es para transmitir datos significativos para el receptor humano.

Para entregar información.

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

Lo más importante en el asunto es saber y ser capaz de entender eso xhtml no es solo una versión de HTML extendido, xhtml es una bestia completamente diferente; tierra arriba; y por lo tanto es sabio mantenerlos separados. 


2
2017-08-17 22:54