¿Escribir etiquetas de cierre automático para elementos no es tradicionalmente una mala práctica vacía?
https://stackoverflow.com/questions/348736
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
He notado que jQuery (o es Firefox) activará algunos de mis <span class="presentational"></span> into <span class="presentational" />
Ahora mi pregunta es, ¿está bien escribir mi marcado así? ¿Se ahogará algún navegador?
Personalmente, creo que parece más limpio hacer <span class="presentational" /> si va a estar vacío.
Solución
Supongo que su pregunta tiene que ver con la barra diagonal roja en los elementos de cierre automático cuando ve la fuente en Firefox. Si es así, te has topado con uno de los debates más vehementes, pero a la vez pasivos y agresivos en las guerras de creadores de navegadores vs. XHTML NO se trata solo del marcado de un documento. También se trata de cómo se deben entregar los documentos en la web.
Antes de comenzar; Estoy tratando de no tomar partido aquí.
La especificación XHTML 1.1 dice que un servidor web debe servir XHTML con un tipo de contenido de aplicación / xhtml + xml. Firefox está señalando esas barras diagonales como inválidas porque su documento se sirve como texto / html en lugar de aplicación / xhtml + xml. Tome estos dos ejemplos; marcado idéntico, uno servido como application / xhtml + xml, el otro como text / html.
http://alanstorm.com/testbed/xhtml-as-html.php
http://alanstorm.com/testbed/xhtml-as-xhtml.php
Firefox marca la barra diagonal final en la metaetiqueta como inválida para el documento servido con text / html, y válida para el documento servido con application / xhtml + xml.
Por qué esto es controvertido
Para un desarrollador de navegadores, el objetivo de XHTML es que puede tratar su documento como XML, lo que significa que si alguien le envía algo que no es válido, la especificación dice que no tiene que analizarlo. Por lo tanto, si un documento se sirve como application / xhtml + xml y tiene contenido mal formado, el desarrollador puede decir & Quot; no es mi problema & Quot ;. Puedes ver eso en acción aquí
http://alanstorm.com/testbed/xhtml-not-valid.php
Cuando un documento se sirve como texto / html, Firefox lo trata como un documento HTML antiguo y simple y utiliza el perdonador, lo arregla por usted, analizando rutinas
http://alanstorm.com/testbed/xhtml-not -valid-as-html.php
Entonces, para un fabricante de navegadores, XHTML servido como text / html es ridículo, porque nunca es tratado como XML por el motor de renderizado del navegador.
Hace un par de años, los desarrolladores web que buscaban ser más que monos de etiqueta (Descargo de responsabilidad: me incluyo como uno de ellos) comenzaron a buscar formas de desarrollar las mejores prácticas que no involucraban tres tablas anidadas, pero aún permitían un Experiencia de diseño convincente. Ellos / Nosotros nos aferramos a XHTML / CSS, porque el W3C dijo que este era el futuro, y la única otra opción era un mundo en el que un único proveedor (Microsoft) controlara la especificación de marcado de facto. El verdadero mal es ser el proveedor único , y no tanto Microsoft. Lo juro.
Entonces, ¿dónde está la controversia? Hay dos problemas con application / xhtml + xml. El primero es Internet Explorer. Hay un error / característica heredada en IE donde el contenido servido como aplicación / xhtml + xml le pedirá al usuario que descargue el documento. Si trató de visitar el xhtml-as-xhtml.php mencionado anteriormente con IE, es probable que eso haya sucedido. Esto significa que si desea utilizar application / xhtml + xml, debe oler el navegador para IE , verificar el encabezado Acepta y solo servir application / xhtml + xml a los navegadores que lo acepten. Esto no es tan trivial como parece acertar, y también fue en contra de " escriba una vez " principio por el que los desarrolladores web luchaban.
El segundo problema es la dureza de XML. Este es, una vez más, uno de esos problemas propensos a las llamas, pero hay algunas personas que piensan que una sola etiqueta incorrecta o un solo carácter mal codificado no debería hacer que un usuario no veang el documento que quieren. En otras palabras, sí, la especificación dice que debe dejar de procesar XML si no está bien formado, pero al usuario no le importa la especificación, le importa que el sitio web de su gato esté roto.
Agregar aún más gasolina al problema es que la especificación XHTML 1.0 (no 1.1) dice que los documentos XHTML pueden servirse como texto / html, suponiendo que ciertos directrices de compatibilidad . Cosas como la etiqueta img se cierra automáticamente y similares. La palabra clave aquí es may . En RFC speak , puede significar opcional. Firefox ha elegido NO tratar documentos servidos con un tipo de documento XHTML, sino un tipo de contenido de texto / html como XHTML. Sin embargo, el validador del W3C informará felizmente que estos documentos son válidos.
Dejaré al lector que reflexione sobre el asombro / horror simultáneo de una cultura que escribe un documento para definir lo que quieren decir con la palabra may .
Avanzando
Finalmente, esto es de lo que se trata HTML 5 . XHTML se convirtió en una patata política tan caliente que un grupo de personas que querían avanzar el lenguaje decidieron ir en otra dirección. Produjeron una especificación para HTML 5. Actualmente, esto se está resolviendo en el W3C, y se espera que termine en algún momento de la próxima década. Mientras tanto, los proveedores de navegadores seleccionan y eligen características de las especificaciones en progreso y las implementan.
Actualizaciones de los comentarios
En los comentarios, Alex señala que si vas a oler algo, deberías marcar Aceptar encabezado para ver si la aplicación / xhtml + xml es aceptada por el agente de usuario.
Esto es absolutamente correcto. En general, si va a oler, huela por la función, no por el navegador.
Otros consejos
Una adición a las otras respuestas: en IE, tener elementos como <span /> en su marcado causará todo tipo de problemas con los métodos de recorrido DOM en JavaScript . Eche un vistazo al siguiente documento XHTML:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Test</title>
<script type="text/javascript">
function show() {
var span = document.getElementById("span");
alert(span.innerHTML);
}
</script>
</head>
<body onload="show();">
<p id="p1">Paragraph containing some text followed by
an empty span<span id="span"/></p>
<p id="p2">Second paragraph just containing text</p>
</body>
</html>
La idea es que cuando se carga la página, el JavaScript obtendrá una referencia al espacio vacío y mostrará su contenido HTML. Esa será una cadena vacía, ¿verdad? No en IE no lo hará. En IE, obtienes todo el contenido después del intervalo en todo el documento:
</P>
<P id=p2>Second paragraph just containing text</P>
Además, el segundo <p> aparece en la colección childNodes del span. Ese mismo <=> también está en la colección <=> del cuerpo, lo que significa que un nodo puede tener múltiples padres . Estas no son terriblemente buenas noticias para los scripts que dependen de atravesar el DOM.
También he blogueado sobre esto .
Sí Es. Causará problemas en ciertos casos para los navegadores antiguos.
<script type='text/javascript' src='script.js' />
En este caso, el navegador antiguo podría no entender que la etiqueta <script> ha finalizado.
Sirvió como application / xhtml + xml, < span / > significa crear un elemento span sin contenido.
Sirvió como text / html, < span / > significa crear un elemento span donde el contenido del elemento siga esta etiqueta hasta que < / span > se encuentra una etiqueta u otra etiqueta (o EOF) que cierra implícitamente el elemento. es decir, en este caso < span / > significa lo mismo que < span > ;.
Aparte: HTML 5 define las serializaciones tanto HTML como XHTML, por lo que no afecta este problema de una forma u otra. Requiere, como XHTML 1.1, que XHTML se sirva como application / xhtml + xml, a diferencia de XHTML 1.0. Sin embargo, en efecto, esto no cambia nada, ya que todos los navegadores tratan cualquier versión de XHTML servida como texto / html como sopa de etiquetas.
También vale la pena señalar que una declaración <?xml ...?> antes de que el doctype ponga IE en modo peculiar.
Consulte la nota sobre el tema del grupo de trabajo XHMTL: http: // www.w3.org/TR/xhtml-media-types/
En resumen & # 8212; está bien si tu XHTML será tratado como XHTML. Si va a fingir que es HTML (lo que debe hacer si desea que Internet Explorer lo cargue (incluida la versión 8, la última en el momento de la escritura), entonces debe saltar a través de los aros).
Los aros son lo suficientemente molestos que recomendaría que la mayoría de la gente se adhiera a HTML 4.01.
En general, no es un problema usar la taquigrafía para elementos vacíos, pero hay algunas excepciones en las que puede causar problemas.
<script> es importante y debe cerrarse con </script> para evitar problemas.
Otro es <meta> que funciona mucho mejor con las arañas escritas como <meta></meta> en lugar de <meta />
No es exactamente la pregunta, pero está relacionada, en términos de formato, las versiones de IE tienen problemas con elementos vacíos como <div></div> o <div />. En este caso, se requiere <div> </div> para mantener el formato.
Debería decirse explícitamente que no hay etiquetas de cierre automático en HTML, por lo que cada vez que un navegador decida tratar su XHTML como HTML, no reconocerá que la etiqueta está cerrada. No es un problema para las etiquetas que no tienen que cerrarse en HTML, como <img>, pero obviamente son malas con etiquetas como <span>.
