¿Cuál es la razón por la cual los navegadores no reconocen correctamente:
<script src="foobar.js" /> <!-- self-closing script element -->
Solo esto se reconoce:
<script src="foobar.js"></script>
¿Esto rompe el concepto de soporte XHTML?
Nota: Esta declaración es correcta al menos para todos los IE (6-8 beta 2).
javascript
html
internet-explorer
xhtml
dimarzionista
fuente
fuente
Respuestas:
La especificación XHTML 1 dice:
С.3. Minimización de elementos y contenido de elementos vacíos
XHTML DTD especifica elementos de script como:
fuente
<script />
no es que la especificación no lo permita, sino que los navegadores no lo interpretan como "sopa sin etiqueta" si el tipo de contenido no es application / xhtml + xml. Ver: stackoverflow.com/questions/348736/… @shabunc: puede parecer que los navegadores lo entienden, pero lo que realmente está sucediendo es que está poniendo el contenido después de <p /> dentro del párrafo, debido a la interpretación de la cita de squadette que significa que desde < p> no está vacío, no puede cerrarse automáticamente. En XHTML 1.1, puede cerrarse automáticamente.Para agregar a lo que Brad y squadette han dicho, la sintaxis XML de cierre automático en
<script />
realidad es XML correcto, pero para que funcione en la práctica, su servidor web también necesita enviar sus documentos como XML formado correctamente con un tipo MIME XML comoapplication/xhtml+xml
en HTTP Encabezado de tipo de contenido (y no comotext/html
).Sin embargo, el envío de un tipo MIME XML hará que sus páginas no sean analizadas por IE7, que solo le gusta
text/html
.De w3 :
Hace unos meses me quedé desconcertado, y la única solución viable (compatible con FF3 + e IE7) era usar la
<script></script>
sintaxis anterior context/html
(sintaxis HTML + tipo mime HTML).Si su servidor envía el
text/html
tipo 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 de
http-equiv
meta elementos, el prólogo XML o el tipo de documento dentro de su documento: Firefox se ramifica una vez que obtiene eltext/html
encabezado, eso determina si el analizador HTML o XML se ve dentro del documento y el analizador HTML no comprende<script />
.fuente
.html
archivos locales representados como una etiqueta de sopa, independientemente de las metaetiquetas, por razones similares. Para los archivos XHTML, Firefox solo los representará en consecuencia si se nombran.xhtml
.application/xhtml+xml
, notext/xml
.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, INPUT), 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 etiqueta 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 diseñado está siendo tratado como una sopa de etiqueta inspirada en SGML mal escrita a menos que la envíe con un tipo mime XML. Por eso también ...
... se interpreta por el navegador como:
... que es la receta para un encantador error oscuro que puede provocarle ataques mientras intenta codificar contra el DOM.
fuente
P
elemento no puede contenerDIV
elementos (esto es HTML no válido), por lo que el navegador cierra implícitamente elP
elemento (definido como "cerrable implícitamente") antes de laDIV
etiqueta de apertura . Sin embargo, los navegadores tienden a comportarse de manera diferente a este respecto (como pueden hacerlo con cualquier HTML no válido).</p>
otro lado, una etiqueta final que falta es parte de la definición de HTML.Otros han respondido "cómo" y citado especificaciones. Aquí está la verdadera historia de "por qué no
<script/>
", después de muchas horas de profundizar en informes de errores y listas de correo.HTML 4
HTML 4 está basado en SGML .
SGML tiene algunas shorttags , tales como
<BR//
,<B>text</>
,<B/text/
, o<OL<LI>item</LI</OL>
. XML toma la primera forma, redefine el final como ">" (SGML es flexible), para que se convierta<BR/>
.Sin embargo, el HTML no se redefinió, por lo que
<SCRIPT/>
debería significar<SCRIPT>>
.(Sí, el '>' debería ser parte del contenido y la etiqueta aún no está cerrada).
Obviamente, esto es incompatible con XHTML y será romper muchos sitios (por los navegadores de tiempo eran lo suficientemente maduro para cuidar de esto ), por lo que nadie se implementó shorttags y la especificación informa en contra de ellos .
Efectivamente, todas las etiquetas auto-terminadas 'que funcionan' son etiquetas con etiqueta final prohibida en analizadores técnicamente no conformes y de hecho no son válidas. Fue W3C el que creó este truco para ayudar a la transición a XHTML al hacerlo compatible con HTML .
Y
<script>
la etiqueta final no está prohibida .La etiqueta "Self-ending" es un hack en HTML 4 y no tiene sentido.
HTML 5
HTML5 tiene cinco tipos de etiquetas y solo las etiquetas 'anuladas' y 'foráneas' pueden cerrarse automáticamente .
Debido a
<script>
que no es nulo ( puede tener 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 como extranjero, hacer un caso especial o algo así?
HTML 5 pretende ser retrocompatible con implementaciones de HTML 4 y XHTML 1. No está basado en SGML o XML; Su sintaxis se refiere principalmente a documentar y unir las implementaciones. (Es por eso que
<br/>
<hr/>
etc. son válidos HTML 5 a pesar de ser HTML4 inválido).El cierre automático
<script>
es una de las etiquetas donde las implementaciones solían diferir. Se utiliza para el trabajo en Chrome, Safari , y Opera ; Que yo sepa, nunca funcionó en Internet Explorer o Firefox.Esto se discutió cuando se redactó HTML 5 y se rechazó porque rompe la compatibilidad del navegador . Las páginas web que cierran automáticamente la etiqueta de script pueden no mostrarse correctamente (si es que lo hacen) en navegadores antiguos. Hubo otras propuestas , pero tampoco pueden resolver el problema de compatibilidad.
Después de que se lanzó el borrador, WebKit actualizó el analizador para que cumpla con los requisitos.
El cierre automático
<script>
no ocurre en HTML 5 debido a la compatibilidad con HTML 4 y XHTML 1.XHTML 1 / XHTML 5
Cuando realmente sirvió como XHTML,
<script/>
está realmente cerrado, como han dicho otras respuestas .Excepto que la especificación dice que debería haber funcionado cuando se sirvió como HTML:
¿Entonces qué pasó?
La gente le pidió a Mozilla que permitiera que Firefox analizara documentos conformes como XHTML independientemente del encabezado de contenido especificado (conocido como análisis de contenido ). Esto habría permitido secuencias de comandos de cierre automático, y el rastreo de contenido era necesario de todos modos porque los proveedores de alojamiento web no eran lo suficientemente maduros para servir el encabezado correcto; IE fue bueno en eso .
Si la primera guerra del navegador no terminó con IE 6, XHTML también podría haber estado en la lista. Pero terminó. E IE 6 tiene un problema con XHTML. De hecho IE no soporta el tipo MIME correcto en absoluto , lo que obliga a todos a utilizar
text/html
para XHTML porque el IE celebró cuota de mercado importante para toda una década.Y también la detección de contenido puede ser realmente mala y la gente dice que debería detenerse .
Finalmente, resulta que el W3C no significaba que XHTML fuera sniffable : el documento es ambos , HTML y XHTML, y
Content-Type
reglas. Se puede decir que se mantuvieron firmes en "solo seguir nuestras especificaciones" e ignorando lo que era práctico . Un error que continuó en versiones posteriores de XHTML.De todos modos, esta decisión resolvió el asunto para Firefox. Pasaron 7 años antes de que Chrome naciera ; No había otro navegador significativo. Así se decidió.
Especificar el doctype solo no activa el análisis XML debido a las siguientes especificaciones.
fuente
<p>
o<li>
, no pueden 'cerrarse automáticamente' ya que pueden tener contenido, por lo que el código como<p/>
no es más que una etiqueta de inicio (malformada) y el contenido después, si está permitido en este elemento , terminaría en su interior.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 sin formato. Y en HTML simple, la sintaxis de cierre automático no es compatible. Simplemente se ignora la barra inclinada final, debe usar una etiqueta de cierre explícita.
Incluso los navegadores con soporte para 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!
fuente
Las personas de arriba ya han explicado 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 persona/
en esa posición básicamente se ignora, y solo se usa cuando se intenta algo analizable como XML y HTML. Intenta<p/>foo</p>
, por ejemplo, y obtienes un párrafo regular.fuente
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.
Si desea 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:
fuente
<style>
etiquetas, pero usamos etiquetas de enlace para archivos CSS externos. Definición de etiqueta de enlace: "La etiqueta <link> define un enlace 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 sirve ... vincular archivos externos. tenga en cuenta que no estoy hablando de especificaciones / cross-browserness / etc, solo estoy comentando sobre la naturaleza lógica del uso de etiquetas de enlace para incorporar CSS y JS ... en realidad tendría mucho sentido si fuera así . No estoy seguro de que el zapato [analogía] se ajuste.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>
se trata como<script defer="defer">
,<script />
se trata como<script /="/">
.fuente
/
como parte de la construcción de NET (etiqueta de finalización nula).Internet Explorer 8 y anteriores no admiten el tipo MIME adecuado para XHTML,
application/xhtml+xml
. Si está sirviendo XHTML comotext/html
, lo que debe 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. Consulte la especificación HTML 4.01 .La 'forma corta' XML se interpreta como un atributo llamado /, que (porque 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 atributos no declarados, pero los navegadores lo ignorarán.
IE9 y versiones posteriores son compatibles con XHTML 5 servido
application/xhtml+xml
.fuente
Eso es porque SCRIPT TAG no es un ELEMENTO ANULADO.
En un documento HTML - ¡ELEMENTOS ANULADOS no necesitan 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 vacío o paramétrico, porque 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 instrucciones cuya semántica no puede ser terminada por 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 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 actual y la altura de línea del estilo que fluye por la secuencia , es decir, se filtra desde 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 genérica sin descripción
< />
, como , habría bastado 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 Stream: split en torrentes antes de envolver / caer en otra cascada. Como consecuencia, un terminador genérico como el< />
que no podría determinar el objetivo de una propiedad para terminar. Por ejemplo:<b>
negrita<i>
negrita-cursiva< />
cursiva</>
normal. Indudablemente, fallaría en acertar nuestra intención y probablemente la interpretaría como negrita negrita-itálica negrita normal.Así es como nació la noción de envoltura, es decir, 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 es un envoltorio semántico). Necesitaremos un contenedor simple, sin semántica. Y, por supuesto, surgió la invención de un elemento DIV.El elemento DIV es en realidad un contenedor 2BR. Por supuesto, la llegada de CSS hizo que 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 nativo previo y posterior de BR de un DIV recién inventado, 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 tanto antes como 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 de anular y redefinir completamente el comportamiento nativo de cualquier etiqueta HTML, de alguna manera logró confundir y difuminar todo el significado de la existencia 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ás la impresión de que ya no son necesarios. Dicho: una sola etiqueta contenedor-envoltorio sería suficiente para toda la presentación de datos. Simplemente agregue 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, 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 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 más mínima consideración a la información. - Para ello, la información es absolutamente irrelevante.
Lo más importante en el asunto es saber y poder entender que xhtml no es solo una versión de un HTML extendido , xhtml es una bestia completamente diferente; molido y por lo tanto es sabio mantenerlos separados.
fuente
La diferencia entre 'verdadero XHTML', 'falso XHTML' y HTML, así como la importancia del tipo MIME enviado por el servidor, ya se han descrito aquí bien . Si desea probarlo ahora, aquí hay un fragmento editable simple con vista previa en vivo que incluye una etiqueta de script de cierre automático para navegadores capaces:
Debería ver a
Hello, true XHTML. Nice to meet you!
continuación el área de texto.Para 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 sugerencia ).fuente
La respuesta simplemente moderna es porque la etiqueta se denota como obligatoria de esa manera
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script
fuente