xml - cierre - etiquetas html

¿Escribir etiquetas de cierre automático para elementos que tradicionalmente no son una mala práctica?

Question

Me he dado cuenta de que jQuery (o es Firefox) convertirá algunos de mis <span class="presentational"></span> into <span class="presentational" />

Ahora mi pregunta es, ¿está bien escribir mi marcado así? ¿Los navegadores se atragantarán con él?

Personalmente, creo que parece más limpio hacer <span class="presentational" /> si va a estar vacío.

Answer 1

Debería indicarse explícitamente que no hay etiquetas autobloqueables 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> .

Answer 2

En general, no es un problema usar la abreviatura de elementos vacíos, pero existen 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 arañas escritas como <meta></meta> lugar de <meta />

No es exactamente la pregunta, pero relacionada, en términos de formato, las versiones de IE tienen problemas solo con elementos vacíos como <div></div> o <div /> . En este caso, se requiere <div>&nbsp;</div> para mantener el formato.

Answer 3

Sí. Es. En algunos casos, ocasionará problemas para navegadores antiguos.

<script type=''text/javascript'' src=''script.js'' />

En este caso, es posible que el navegador anterior no comprenda que la etiqueta <script> ha finalizado.

Answer 4

Servido como application / xhtml + xml, <span /> significa crear un elemento span sin contenido.

Servido como text / html, <span /> significa crear un elemento span donde el contenido del elemento sigue esta etiqueta hasta que se encuentra la etiqueta </ ​​span>, o se encuentra 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 de HTML como de 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. En efecto, esto no cambia nada ya que todos los navegadores tratan cualquier versión de XHTML servida como text / html como sopa de etiqueta.

Answer 5

Supongo que su pregunta tiene que ver con la barra inclinada roja en los elementos de cierre automático cuando visualiza la fuente en Firefox. Si es así, te has tropezado con uno de los debates agresivos pasivos más vehementes, pero simultáneamente en el navegador frente a las guerras de desarrolladores web. XHTML NO es solo sobre el marcado de un documento. También se trata de cómo los documentos deben ser servidos 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 / xhtml + xml. Firefox señala las barras diagonales como no válidas porque su documento se sirve como texto / html en lugar de application / xhtml + xml. Toma 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 señala que la barra diagonal de la metaetiqueta no es válida para el documento servido con text / html y es válida para el documento servido con application / xhtml + xml.

Por qué esto es polémico

Para un desarrollador de navegador, el objetivo de XHTML es que pueda 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. Entonces, si un documento se sirve como application / xhtml + xml y tiene contenido no bien formado, el desarrollador puede decir "no es mi problema". 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 simple documento HTML antiguo y usa el perdón, lo arregla para usted, las rutinas de análisis

http://alanstorm.com/testbed/xhtml-not-valid-as-html.php

Por lo tanto, para un fabricante de navegadores, XHTML sirve como text / html, es ridículo, porque nunca es tratado como XML por el motor de renderizado del navegador.

Hace algunos años, los desarrolladores web que buscaban ser más que monos (Descargo de responsabilidad: me incluyo a mí mismo como uno de ellos) comenzaron a buscar formas de desarrollar mejores prácticas que no involucraran tres mesas anidadas, pero permitían una experiencia de diseño atractiva. . Ellos / Nos aferramos a XHTML / CSS, porque el W3C dijo que este era el futuro, y la única otra opción era un mundo donde un único proveedor (Microsoft) controlaba las especificaciones de marcado defacto. El verdadero mal es el único proveedor , 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 / función heredada en IE donde el contenido servido como application / xhtml + xml pedirá al usuario que descargue el documento. Si trataste de visitar el xhtml-as-xhtml.php mencionado anteriormente con IE, es probable que eso haya sucedido. Esto significa que si desea usar application / xhtml + xml, debe buscar en el navegador para IE , marcar 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 va en contra del principio de "escribir una vez" que los desarrolladores web estaban luchando.

El segundo problema es la dureza de XML. Este es, de nuevo, uno de esos problemas propensos a las llamas, pero hay algunas personas que piensan que una sola etiqueta incorrecta, o un solo carácter incorrectamente codificado, no debe dar como resultado que el usuario no vea el documento que desea. 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, les 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 se pueden servir como texto / html, suponiendo que se sigan ciertas pautas de compatibilidad . Cosas como la etiqueta img siendo cierre automático y cosas por el estilo. La palabra clave aquí es may . En lenguaje RFC , puede significa opcional. Firefox ha elegido NO tratar los documentos servidos con un doctype XHTML pero un tipo de contenido de texto / html como XHTML. Sin embargo, el validador W3C informará felizmente estos documentos como válidos.

Dejaré que el lector 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, de esto se trata todo el HTML 5 . XHTML se convirtió en un tema tan candente político que un grupo de personas que querían avanzar en el lenguaje decidieron ir en otra dirección. Produjeron una especificación para HTML 5. Esto está siendo descifrado 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 las características de las especificaciones en curso y las implementan.

Actualizaciones de los Comentarios

En los comentarios, señala que si va a olfatear algo, debe verificar el encabezado Aceptar para ver si application / xhtml + xml es aceptado por el agente de usuario.

Esto es absolutamente correcto. En general, si va a olfatear, busque la función, no para el navegador.

Answer 6

También vale la pena señalar que una declaración <?xml ...?> Antes del doctype arroja IE en el modo peculiar.

Answer 7

Una adición a las otras respuestas: en IE, tener elementos como <span /> en su margen de beneficio causará todo tipo de problemas con los métodos de cruce 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 tramo vacío y mostrará sus contenidos HTML. Esa será una cadena vacía, ¿verdad? No en IE no lo hará. En IE, obtienes todo el contenido después del lapso 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 childNodes . Ese mismo <p> también está en la colección childNodes del cuerpo, lo que significa que un nodo puede tener múltiples padres . Esta no es una buena noticia para las secuencias de comandos que se basan en atravesar el DOM.

También he blogueado sobre esto .

Answer 8

Ver la nota sobre el tema del grupo de trabajo XHMTL: http://www.w3.org/TR/xhtml-media-types/

En resumen, está bien si su XHTML va a ser tratado como XHTML. Si va a pretender que es HTML (lo que debe hacer si desea que se cargue con Internet Explorer (incluida la versión 8, la última al momento de escribir), entonces tiene que saltar a través de los aros).

Los aros son lo suficientemente molestos como para recomendar que la mayoría de las personas se apeguen a HTML 4.01.