¿Son válidas las etiquetas de cierre automático (no nulo) en HTML5?


670

Al validador del W3C no le gustan las etiquetas de cierre automático (las que terminan con "/> ") en elementos no vacíos . (Los elementos vacíos son aquellos que pueden no contener ningún contenido). ¿Siguen siendo válidos en HTML5?

Algunos ejemplos de elementos vacíos aceptados :

<br />
<img src="" />
<input type="text" name="username" />

Algunos ejemplos de elementos no vacíos rechazados :

<div id="myDiv" />
<span id="mySpan" />
<textarea id="someTextMessage" />

Nota:
El validador W3C en realidad acepta etiquetas de cierre automático nulas: el autor originalmente tuvo un problema debido a un error tipográfico simple (en \>lugar de />); sin embargo, las etiquetas de cierre automático no son 100% válidas en HTML5 en general, y las respuestas explican el tema de las etiquetas de cierre automático en varios tipos de HTML.


2
@Ben: oh, lo siento, creo que tienes razón. En este caso, no entendí bien la pregunta original, pensé que el OP quiere saber si las etiquetas de cierre automático son válidas en HTML5. Pero esto significa que acaba de hacer errores tipográficos en su código, o no sabía cómo escribir correctamente las etiquetas de cierre automático, lo que tiene sentido que el validador del W3C marque su código como no válido.
Sk8erPeter

16
Para ahorrar tiempo para futuros lectores: sí, la sintaxis en la pregunta es incorrecta y no, no debe cambiarla. El OP ha explicado explícita y justificadamente por qué . Dado que dio lugar a los errores de validación que provocaron esta pregunta, la sintaxis no debe corregirse.
Jordan Grey

2
¿ Siguen luchando sobre qué dirección deberían estar mirando los cortes? Venga.
BoltClock

3
@BoltClock Sí, sigue luchando. Chicos: si esta pregunta era sobre \>, debería cerrarse como una pregunta inútil de arreglar mi error tipográfico. Las respuestas a todas las direcciones />. La />versión es la única útil. Déjalo ser.
Gilles 'SO- deja de ser malvado'

1
Entonces la pregunta tiene que ser redactada nuevamente, porque el validador W3C en realidad acepta etiquetas de cierre automático. Es difícil reformular la pregunta de tal manera sin comprometer su integridad con respecto a la intención original. Por lo tanto, si queremos adherirnos a las reglas de SO, es posible que tengamos que sacrificar la claridad en preguntas como esta, a pesar de que parece que editar la pregunta es lo único sensato, por el bien mayor. promedio. Podríamos comenzar otra discusión sobre meta, si hay muchas otras preguntas sobre un tema similar.
osa

Respuestas:


1238
  • En HTML 4 , <foo /(sí, con no >en absoluto) significa <foo>(que conduce a <br />significado <br>>(es decir <br>&gt;) y <title/hello/significado <title>hello</title>). Esta es una regla SGML que los navegadores hicieron un trabajo de soporte muy pobre, y la especificación aconseja a los autores que eviten la sintaxis .

  • En XHTML , <foo />significa<foo></foo> . Esta es una regla XML que se aplica a todos los documentos XML. Dicho esto, XHTML a menudo se sirve como lo text/htmlque (históricamente al menos) es procesado por los navegadores que utilizan un analizador diferente al de los documentos servidos application/xhtml+xml. El W3C proporciona pautas de compatibilidad a seguir para XHTML como text/html. (Básicamente: utilice la sintaxis de etiqueta de cierre automático cuando el elemento se define como VACÍO (y la etiqueta final estaba prohibida en la especificación HTML)).

  • En HTML5 , el significado de <foo /> depende del tipo de elemento .

    • En los elementos HTML que se designan como elementos vacíos (esencialmente "Un elemento que existía antes de HTML5 y que tenía prohibido tener contenido"), las etiquetas finales simplemente están prohibidas. La barra diagonal al final de la etiqueta de inicio está permitida, pero no tiene sentido. Es solo el azúcar sintáctico para las personas (y los resaltadores de sintaxis) que son adictos al XML.
    • En otros elementos HTML, la barra diagonal es un error, pero la recuperación del error hará que los navegadores lo ignoren y traten la etiqueta como una etiqueta de inicio normal. Por lo general, esto terminará con una etiqueta final faltante que hará que los elementos posteriores sean hijos en lugar de hermanos.
    • Los elementos extraños (importados de aplicaciones XML como SVG) lo tratan como una sintaxis de cierre automático.

24
" ... que son adictos al XML ". Parece sugerir que el cumplimiento de XML es malo. Sin embargo, el resultado final en HTML5 parece ser que todavía tenemos que lidiar con paréntesis angulares de todos modos (es decir, algo con la mayoría de los inconvenientes de XML), mientras que hace que sea más difícil usar herramientas basadas en XML (por ejemplo, herramientas de plantilla o varios procesadores). ) Incluso desde un punto de vista generación, parecería que <object data="..." />y <img src="..."></src>no son OK, mientras que <object data="..."></object>y <img src="..." />son, lo que hace que sea más difícil para mantener la coherencia de la herramienta. Esto parece una situación de perder-perder.
Bruno

77
@Bruno: HTML es anterior a XML. Los esfuerzos para lograr que la gente se mude a XHTML fallaron. Con text/html, los navegadores no le dan ningún significado especial a la barra, por lo que incluirlo no tiene ningún propósito práctico. Solo está ahí para que se vea más como XML para las personas que no pueden dejar el hábito.
Quentin

66
@Quentin No estoy totalmente en desacuerdo. Es una pena que un equivalente XML válido no sea necesariamente HTML5 válido (por ejemplo, en <img ...></img>lugar de <img ...>o <img ... />). Dado que HTML5 es efectivamente menos estricto en general (posiblemente por qué XHTML falló), muy bien podría haber tolerado algo así <img ...></img>. Desafortunadamente, no es así, por lo que un generador de plantillas basado en XML necesita saber cómo distinguir la producción de elementos vacíos o elementos de cierre automático: ni siquiera puede tener una regla para decir escribir todos los elementos vacíos como <tag></tag>.
Bruno

3
XHTML falló antes de que HTML 5 estuviera incluso en el horizonte, y no puede tener elementos vacíos de forma larga porque la corrección de errores del navegador que precedió a XHTML haría cosas como tratar, </br>ya <br>que <br></br>sería un doble salto de línea. (y la compatibilidad con el marcado incorrecto del mundo real (como </br>) es uno de los objetivos de diseño de HTML 5).
Quentin

1
DESDE W3C: Elementos vacíos: área, base, br, col, incrustación, hr, img, input, keygen, link, meta, param, source, track, wbr "Los elementos vacíos solo tienen una etiqueta de inicio; las etiquetas finales no deben especificarse para elementos vacíos ". w3.org/TR/html5/syntax.html#void-elements
Fabio Nolasco

406

Como señaló Nikita Skvortsov, un div de cierre automático no se validará. Esto se debe a que un div es un elemento normal , no un elemento vacío .

De acuerdo con la especificación HTML5 , las etiquetas que no pueden tener ningún contenido (conocidas como elementos vacíos ) pueden cerrarse automáticamente *. Esto incluye las siguientes etiquetas:

area, base, br, col, embed, hr, img, input, 
keygen, link, meta, param, source, track, wbr

Sin embargo, "/" es completamente opcional en las etiquetas anteriores, por lo <img/>que no es diferente de <img>, pero <img></img>no es válido.

* Nota: los elementos extraños también pueden cerrarse automáticamente, pero no creo que esté dentro del alcance de esta respuesta.


1
Las Herramientas para desarrolladores de IE10 me dan "HTML1500: la etiqueta no puede cerrarse automáticamente. Use una etiqueta de cierre explícita". en la línea <meta charset = "UTF-8" /> ¿Alguna idea de por qué sería eso?
James en Indy el

Ok, descubrí que las etiquetas de cierre automático no deberían tener la barra inclinada (y al eliminarlo se corrige mi error). Cita: tiffanybbrown.com/2011/03/23/…
James en Indy

La especificación ha cambiado. Ahora, los elementos "anulados" o "de cierre automático" no deben incluir la barra diagonal, cuando se sirven como doctype HTML 5. Sin embargo, si se está sirviendo como XHTML, es posible que se requiera la barra diagonal de cierre (consulte los documentos en este caso). En el uso práctico, las páginas generalmente se mostrarán como se esperaba, incluso si /se ha incluido el cierre , pero esto no está garantizado (depende de que el navegador reescriba efectivamente el código para usted e lo interprete como lo desea). Además, si por alguna razón, se requiere que su página pase la validación HTML 5, es posible que no pase si cierra las etiquetas para los elementos vacíos.
SherylHohman

Con respecto al comentario de @ SherylHohman, no creo que la especificación haya cambiado (o si lo ha hecho, ha cambiado de nuevo). Consulte w3.org/TR/html5/syntax.html#start-tags (8.1.2.1.6): los elementos nulos (o extraños) aún pueden incluir la barra inclinada.
ChrisC

63

En la práctica, el uso de etiquetas de cierre automático en HTML debería funcionar como es de esperar. Pero si le preocupa escribir HTML5 válido , debe comprender cómo se comporta el uso de tales etiquetas dentro de los dos formularios de sintaxis diferentes que puede usar. HTML5 define una sintaxis HTML y una sintaxis XHTML, que son similares pero no idénticas. El que se use depende del tipo de medio enviado por el servidor web.

Lo más probable es que sus páginas se sirvan como text/html, lo que sigue la sintaxis HTML más indulgente. En estos casos, HTML5 permite que ciertas etiquetas de inicio tengan una opción / antes de que finalice>. En estos casos, el / es opcional y se ignora, de modo <hr>y <hr />son idénticos. La especificación HTML llama a estos "elementos nulos" y proporciona una lista de elementos válidos. Estrictamente hablando, el / opcional solo es válido dentro de las etiquetas de inicio de estos elementos vacíos; por ejemplo, <br />y <hr />son válidos HTML5, pero <p />no lo son.

La especificación HTML5 hace una clara distinción entre lo que es correcto para los autores HTML y para los desarrolladores de navegadores web, y se requiere que el segundo grupo acepte todo tipo de sintaxis "heredada" no válida. En este caso, significa que los navegadores compatibles con HTML5 aceptarán etiquetas ilegales de cierre automático, como me gusta <p />, y las representarán como probablemente espera. Pero para un autor, esa página no sería HTML5 válida. (Que es más importante, el árbol DOM que se obtiene de utilizar este tipo de sintaxis ilegal puede verse seriamente la pata; auto-cerrado <span />etiquetas, por ejemplo, tienden a echar las cosas mucho ).

(En el caso inusual de que su servidor sepa cómo enviar archivos XHTML como un tipo XML MIME, la página debe cumplir con la sintaxis XHTML DTD y XML. Eso significa que se requieren etiquetas de cierre automático para los elementos definidos como tales).


31
<p /> se tratará como una etiqueta de apertura, no como una etiqueta de cierre automático. Eso significa que todo el resto del documento se tratará como si estuviera dentro del elemento P. Eso no es lo que "probablemente espero", y producirá un desastre en cualquier página no trivial.
mhsmith

12

HTML5 básicamente se comporta como si la barra diagonal final no estuviera allí. No existe una etiqueta de cierre automático en la sintaxis HTML5.

  • Las etiquetas de cierre automático en elementos no vacíos como <p/>, <div/>no funcionarán en absoluto. La barra diagonal final se ignorará y se tratará como etiquetas de apertura. Es probable que esto conduzca a problemas de anidación.

    Esto es cierto independientemente de si hay espacios en blanco frente a la barra inclinada: <p />y <div />tampoco funcionará por la misma razón.

  • Etiquetas de cierre automático en vacío elementos como <br/>o <img src="" alt=""/> va a trabajar, pero sólo porque la barra final es ignorado, y en este caso lo que sucede a resultar en un comportamiento correcto.

El resultado es que todo lo que funcionó en su antiguo "XHTML 1.0 servido como texto / html" continuará funcionando como lo hacía antes: las barras inclinadas en etiquetas no vacías tampoco fueron aceptadas allí, mientras que la barra inclinada en elementos vacíos funcionó.

Una nota más: es posible representar un documento HTML5 como XML, y esto a veces se denomina "XHTML 5.0". En este caso, se aplicarán las reglas de XML y siempre se manejarán las etiquetas de cierre automático. Siempre necesitaría ser servido con un tipo mime XML.


5

Las etiquetas de cierre automático son válidas en HTML5, pero no son obligatorias.

<br>y <br />ambos están bien.


12
De acuerdo con las especificaciones HTML5, la sintaxis de cierre automático ( />) no se puede usar en un elemento HTML no vacío.
naXa

3
La pregunta era sobre etiquetas de cierre automático en elementos no vacíos , como <p/>o <div/>.
thomasrutter

2
Inicialmente, la pregunta no era específicamente sobre elementos no nulos. Era más bien, ¿puedes usarlo <... />como en XHTML o tienes que eliminarlo /en HTML5? La pregunta fue cambiada varias veces después.
Nick

De cualquier manera, la respuesta es que se ignorará la barra oblicua, lo que romperá elementos no declarados como nulos, pero será compatible con elementos nulos.
thomasrutter

4

Sería muy cuidadoso con las etiquetas de cierre automático, ya que este ejemplo demuestra:

var a = '<span/><span/>';
var d = document.createElement('div');
d.innerHTML = a
console.log(d.innerHTML) // "<span><span></span></span>"

Mi instinto habría sido <span></span><span></span>en su lugar


2
Esto se describe en la respuesta aceptada:On other [than void] HTML elements, the slash is an error, but error recovery will cause browsers to ignore it and treat the tag as a regular start tag. This will usually end up with a missing end tag causing subsequent elements to be children instead of siblings.
Palec

-1

Sin embargo, solo para el registro, esto no es válido:

<address class="vcard">
  <svg viewBox="0 0 800 400">
    <rect width="800" height="400" fill="#000">
  </svg>
</address>

Y una barra aquí lo haría válido nuevamente:

    <rect width="800" height="400" fill="#000"/>

1
Eso es porque svg está escrito en xml, no en html. Utiliza diferentes reglas de análisis
Electric Coffee
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.