HTML: ¿Incluir o excluir etiquetas de cierre opcionales?

149

Algunas etiquetas ^de cierre HTML ¹ son opcionales , es decir:

</HTML>
</HEAD>
</BODY>
</P>
</DT>
</DD>
</LI>
</OPTION>
</THEAD>
</TH>
</TBODY>
</TR>
</TD>
</TFOOT>
</COLGROUP>

Nota: No debe confundirse con las etiquetas de cierre que están prohibidas , es decir:

</IMG>
</INPUT>
</BR>
</HR>
</FRAME>
</AREA>
</BASE>
</BASEFONT>
</COL>
</ISINDEX>
</LINK>
</META>
</PARAM>

Nota: xhtml es diferente del HTML. xhtml es una forma de xml, que requiere que cada elemento tenga una etiqueta de cierre. Se puede prohibir una etiqueta de cierre en html, pero obligatoria en xhtml.

Son las etiquetas de cierre opcionales

idealmente incluido , pero los aceptaremos si los olvidó, o
idealmente no incluido, pero los aceptaremos si los coloca en

En otras palabras, debería I incluirlos, o mejor no incluirlos?

La especificación HTML 4.01 habla de que las etiquetas de elemento de cierre son opcionales , pero no dice si es preferible incluirlas o preferible no incluirlas.

Por otro lado, un artículo aleatorio sobre DevGuru dice :

La etiqueta final es opcional. Sin embargo, se recomienda que se incluya.

La razón por la que pregunto es porque usted sabe que es opcional por razones de compatibilidad; y los habrían hecho ( obligatorios | prohibidos ) si hubieran podido.

Dicho de otra manera: ¿Qué hizo HTML 1, 2, 3 con respecto a estas, ahora opcionales, etiquetas de cierre? ¿Qué hace HTML 5? Y qué debería yo hacer?

Nota

Se prohíbe que algunos elementos en HTML tengan etiquetas de cierre. Puede estar en desacuerdo con eso, pero esa es la especificación, y no está en discusión. Estoy preguntando acerca de las etiquetas de cierre opcionales , y cuál era la intención.

Notas al pie

¹ HTML 4.01

html html4

— Ian Boyd
fuente

44

Pregunta difícil ... algunas de las recomendaciones de w3c incluso incluyen ejemplos que hacen ambas cosas : w3.org/TR/html401/struct/global.html#id-and-class ¡ El primer ejemplo tiene </p>etiquetas de cierre y el segundo las omite!

— Richard JP Le Guen

Solo para aclarar: en el caso de las etiquetas prohibidas en HTML5, la solución válida "explícita" / XML es cerrarlas con un />, por ejemplo <meta charset="utf-8" />, ¿aunque <meta charset="utf-8">es un HTML5 válido?

— cboettig

@cboettig Sí. <meta charset="utf-8" />es inválido html, debe serlo <meta charset="utf-8">. Por otro lado, no<meta charset="tuf-8"> es válido xhtml, debe serlo<meta charset="utf-8" />

— Ian Boyd

@IanBoyd realmente? en HTML5? El borrador del manual del W3C para polyglot html / xhtml dice que se use <meta charset="UTF-8"/>con la etiqueta de cierre. De lo contrario, ¿cómo podrían validarse polyglot o xhtml como html5 y xml?

— cboettig

@cboettig Tienes razón. El marcado políglota (es decir , documentos XHTML compatibles con HTML ) no puede ser HTML 4.01 válido. HTML5 (todavía un trabajo en progreso) tiene la noción de elementos vacíos , elementos que no pueden tener una etiqueta final . Presumiblemente, la mayoría de los navegadores son suaves y perdonarán sus errores de marcado.

— Ian Boyd

49

Los opcionales son todos los que deben ser semánticamente claros donde terminan, sin necesidad de la etiqueta final. EG cada uno <li>implica un </li>si no hay uno justo antes.

Todas las etiquetas finales prohibidas irían inmediatamente seguidas de su etiqueta final, por lo que sería redundante tener que escribir <img src="blah" alt="blah"></img>todo el tiempo.

Casi siempre uso las etiquetas opcionales (a menos que tenga una muy buena razón para no hacerlo) porque se presta a un código más legible y actualizable.

— un barrio pobre
fuente

18

ya lo veo. <LI>Es como una bala. Nadie querría tener que envolver un punto con viñetas completo <LI>...</LI>. Entonces, de esa manera, LIcoincide con lo que la gente escribiría naturalmente durante el marcado. Sames elige una marca de párrafo ( <P>), en el procesamiento de textos, agrega una marca de párrafo al comienzo de un párrafo; y no al final de cada uno también. Entonces, en esta interpretación, las etiquetas de cierre son opcionales porque ninguna persona normal pensaría tenerlas. Además, el elemento en sí no tiene contenido: el elemento es el contenido.

— Ian Boyd

8

¿Qué quiere decir con que casi siempre uso las etiquetas opcionales ? ¿Quiere decir que incluye la etiqueta final o que la omite ? (Tengo la impresión de que se incluya que, cuando leí su respuesta - pero el comentario anterior por Ian Boyd me da la impresión de que se excluya la misma.)

— KajMagnus

3

@IanBoyd ¿Y para el último párrafo?

— Pacerier

22

@Pacerier La gente ha estado escribiendo párrafos de texto durante cientos de años. Nadie se ha confundido cuando termina un párrafo.

— Ian Boyd

44

Enlace relevante para HTML5, para aquellos que encontraron esta respuesta al intentar encontrar la documentación de referencia real: w3.org/TR/html5/syntax.html#optional-tags

— Mike 'Pomax' Kamermans

59

Hay casos en que las etiquetas explícitas ayudan, pero a veces es pedantería innecesaria.

Tenga en cuenta que la especificación HTML especifica claramente cuándo es válido omitir etiquetas, por lo que no siempre es un error.

Por ejemplo, nunca lo necesitas </body></html>. Nadie se acuerda de poner <tbody>explícitamente (hasta el punto de que XHTML hizo excepciones).

No es necesario a </head><body>menos que tenga scripts de manipulación DOM que realmente busquen <head>(entonces es mejor cerrarlo explícitamente, porque las reglas para el final implícito <head>podrían sorprenderlo).

Las listas anidadas en realidad están mejor sin ellas </li>, porque entonces es más difícil crear un ul > ulárbol erróneo .

Válido:

<ul>
  <li>item
  <ul>
    <li>item
  </ul>
</ul>

Inválido:

<ul>
  <li>item</li>
  <ul>
    <li>item</li>
  </ul>
</ul>

Y tenga en cuenta que las etiquetas finales están implícitas si intenta cerrar todos los elementos o no. Poner etiquetas finales no hará que el análisis sea más robusto automáticamente:

<p>foo <p>bar</p> baz</p>

analizará como:

<p>foo</p><p>bar</p> baz

Solo puede ayudar cuando valida documentos.

— Kornel
fuente

44

Espera, ¿por qué <p>foo <p>bar</p> baz</p>no se analiza como dos petiquetas anidadas ?

— Eric

19

Porque un <P>elemento no puede contener elementos a nivel de bloque, y <P>es un elemento a nivel de bloque. De ( w3.org/TR/REC-html40/struct/text.html#edef-P ) "El elemento P representa un párrafo. No puede contener elementos a nivel de bloque (incluido el propio P)".

— Ian Boyd

1

@IanBoyd ¿Quiere decir que no puede contener elementos de nivel de bloque independientemente de las reglas CSS?

— Pacerier

66

@Pacerier CSS no puede influir en DOM de ninguna manera. DOM se analiza primero y luego CSS lo muestra. La blockvisualización de CSS es algo completamente diferente del contenido de nivel de bloque de HTML (simplemente sucede que la mayoría de los elementos de nivel de bloque de HTML se muestran como bloques de CSS de forma predeterminada).

— Kornel

2

@ anton1980 No, esto no es lo mismo. El manejo de las etiquetas de cierre opcionales omitidas se especifica claramente y funciona de manera confiable en todos los navegadores compatibles. OTOH un invento <t>no funcionará como <title>.

— Kornel

18

Estoy agregando algunos enlaces aquí para ayudarlo con la historia de HTML, para que pueda comprender las diversas contradicciones. Esta no es la respuesta a su pregunta, pero sabrá más después de leer estos diversos resúmenes.

Algunos extractos de Inmersión en HTML5 :

[E] l hecho de que el marcado HTML "roto" todavía funcionaba en los navegadores web llevó a los autores a crear páginas HTML rotas. Muchas páginas rotas. Según algunas estimaciones, más del 99% de las páginas HTML en la web de hoy tienen al menos un error en ellas. Pero debido a que estos errores no hacen que los navegadores muestren mensajes de error visibles, nadie los repara.

El W3C vio esto como un problema fundamental con la web, y se propusieron corregirlo. XML, publicado en 1997, rompió con la tradición de perdonar a los clientes y ordenó que todos los programas que consumían XML debieran tratar los llamados errores de "buena formación" como fatales. Este concepto de fallar en el primer error se conoció como "manejo de errores draconianos", después del líder griego Draco, quien instituyó la pena de muerte por infracciones relativamente menores de sus leyes. Cuando el W3C reformuló HTML como vocabulario XML, exigió que todos los documentos que se entreguen con el nuevo application/xhtml+xmltipo MIME estén sujetos a un manejo de errores draconiano. Si hubiera un solo error de buena forma en su página XHTML, los navegadores web [...] no tendrían más remedio que detener el procesamiento y mostrar un mensaje de error al usuario final.

Esta idea no era universalmente popular. Con una tasa de error estimada del 99% en las páginas existentes, la posibilidad siempre presente de mostrar errores al usuario final y la escasez de nuevas funciones en XHTML 1.0 y 1.1 para justificar el costo, los autores web básicamente ignoraron application/xhtml+xml. Pero eso no significa que ignoraron XHTML por completo. Oh, definitivamente no. El apéndice C de la especificación XHTML 1.0 dio a los autores web del mundo un vacío legal: "Use algo que se parezca a la sintaxis XHTML, pero siga sirviéndolo con el text/htmltipo MIME". Y eso es exactamente lo que hicieron miles de desarrolladores web: se "actualizaron" a la sintaxis XHTML pero continuaron sirviéndola con un tipo MIME text / html.

Incluso hoy, millones de páginas web afirman ser XHTML. Comienzan con el doctype XHTML en la primera línea, usan nombres de etiquetas en minúsculas, usan comillas alrededor de los valores de los atributos y agregan una barra diagonal después de elementos vacíos como <br />y <hr />. Pero solo una pequeña fracción de estas páginas se sirve con el application/xhtml+xmltipo MIME que desencadenaría el manejo de errores draconianos de XML. Cualquier página servida con un tipo MIME de text/html, independientemente del doctype, la sintaxis o el estilo de codificación, se analizará utilizando un analizador HTML "indulgente", ignorando silenciosamente cualquier error de marcado y nunca alertando a los usuarios finales (o cualquier otra persona) incluso si las páginas están técnicamente rotos

XHTML 1.0 incluyó este vacío legal, pero XHTML 1.1 lo cerró, y el XHTML 2.0 nunca finalizado continuó la tradición de requerir un manejo de errores draconiano. Y es por eso que hay miles de millones de páginas que afirman ser XHTML 1.0, y solo unas pocas que afirman ser XHTML 1.1 (o XHTML 2.0). Entonces, ¿realmente estás usando XHTML? Verifica tu tipo MIME. (En realidad, si no sabe qué tipo MIME está usando, puedo garantizarle que todavía lo está usando text/html). A menos que esté sirviendo a sus páginas con un tipo MIME application/xhtml+xml, su llamado "XHTML" es XML solo de nombre.

[L] a las personas que habían propuesto la evolución de los formularios HTML y HTML se enfrentaron con dos opciones: renunciar o continuar su trabajo fuera del W3C. Eligieron este último, registraron el whatwg.orgdominio y, en junio de 2004, nació el Grupo de Trabajo WHAT .

[L] a QUÉ grupo de trabajo estaba trabajando en silencio en algunas otras cosas también. Uno de ellos era una especificación, inicialmente denominada Web Forms 2.0 , que agregaba nuevos tipos de controles a los formularios HTML. (Aprenderá más sobre los formularios web en A Form of Madness .) Otro fue un borrador de especificación llamado "Aplicaciones web 1.0", que incluía nuevas características importantes como un lienzo de dibujo en modo directo y soporte nativo para audio y video sin complementos .

En octubre de 2009, el W3C cerró el Grupo de trabajo XHTML 2 y emitió esta declaración para explicar su decisión :

Cuando W3C anunció los Grupos de trabajo HTML y XHTML 2 en marzo de 2007, indicamos que continuaríamos monitoreando el mercado de XHTML 2. W3C reconoce la importancia de una señal clara para la comunidad sobre el futuro del HTML.

Si bien reconocemos el valor de las contribuciones del Grupo de trabajo XHTML 2 a lo largo de los años, después de una discusión con los participantes, la gerencia del W3C ha decidido permitir que el estatuto del Grupo de trabajo expire a fines de 2009 y no renovarlo.

Los que ganan son los que se envían.

— Srikar Doddi
fuente

12

La razón por la que pregunto es porque usted sabe que es opcional por razones de compatibilidad; y los habrían hecho (obligatorios | prohibidos) si hubieran podido.

Esa es una inferencia interesante. Mi lectura es que casi cada vez que una etiqueta puede inferirse de manera confiable, la etiqueta es opcional. El diseño sugiere que la intención era hacerlo rápido y fácil de escribir.

¿Qué hizo HTML 1, 2, 3 con respecto a estas etiquetas de cierre, ahora opcionales?

El DTD para HTML 2 está incrustado en el RFC que, junto con el HTML DTD original , tiene etiquetas de inicio y fin opcionales en todo el lugar.

HTML 3 fue abandonado (gracias a las guerras del navegador) y reemplazado con HTML 3.2 (que fue diseñado para describir el estado actual de la web).

¿Qué hace HTML 5?

HTML 5 se orientó a "pavimentar los caminos de vaca" desde el principio.

¿Y que debería hacer?

Ah, eso es subjetivo y argumentativo :)

Algunas personas piensan que las etiquetas explícitas son mejores para la legibilidad y el mantenimiento en virtud de estar frente a los ojos de los lectores.

Algunas personas piensan que las etiquetas inferidas son mejores para la legibilidad y el mantenimiento en virtud de no saturar el editor.

— Quentin
fuente

1

+1 no había pensado en la noción de "inferido confiablemente". De modo que defiende la idea de que realmente no había ninguna intención de una manera u otra. Supuse que la especificación intentaba ser lo más compatible posible con el contenido HTML y las especificaciones HTML existentes.

— Ian Boyd

Lo siento, Dave, se lo di a Aslum; necesita el representante :) Pero tienes la misma idea, con más contenido vinculado y citado. Pero buena respuesta.

— Ian Boyd

8

¿Qué hace HTML 5?

La respuesta a esta pregunta se encuentra en el Borrador de trabajo del W3C: http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission

¿Y que debería hacer?

Es una cuestión de estilo. Intento nunca omitir las etiquetas finales porque me ayuda a ser riguroso y no omitir las etiquetas que son necesarias.

— ghoppe
fuente

+1 para el enlace al borrador de la especificación HTML 5 y la sección correspondiente. Pero html 5 no dice de una manera u otra.

— Ian Boyd

6

Si es superfluo, déjelo afuera.

Si tiene un propósito (incluso un propósito aparentemente trivial, como apaciguar su IDE o apaciguar sus ojos), déjelo adentro.

Es raro en una especificación bien definida ver elementos opcionales que no afectan el comportamiento. Con la excepción de los "comentarios", por supuesto. Pero la especificación HTML es menos una especificación de diseño y más un documento del estado de las principales implementaciones actuales. Entonces, cuando un elemento es opcional en HTML y parece no tener ningún propósito, podemos suponer que la naturaleza opcional es meramente documentación de una peculiaridad en un navegador específico.

Mirando la sección de RFC de especificaciones HTML-5 vinculada anteriormente, verá que las etiquetas opcionales están extrañamente vinculadas a la presencia de comentarios. Eso debería decirle que los autores no llevan sombreros de diseño. En cambio, están jugando el juego de "documentar las peculiaridades" en las principales implementaciones. Por lo tanto, no podemos tomar la especificación demasiado en serio a este respecto.

Entonces, la solución es: no te preocupes. Pase a algo que realmente importa. :)

— Juan
fuente

5

Creo que la mejor respuesta es incluir etiquetas de cierre para facilitar la lectura o la detección de errores. Sin embargo, si tiene un montón de HTML generado (por ejemplo, tablas de datos), podría ahorrar un ancho de banda significativo al omitir etiquetas opcionales.

— Gabe
fuente

2

Richard: Cuando tienes estructuras profundamente anidadas, es mucho más fácil encontrar errores porque las etiquetas de cierre dan más información sobre la intención.

— Gabe

1

Creo que "las etiquetas de cierre dan más información sobre la intención" es la mejor respuesta concisa a esta pregunta. Argumenta una buena razón clara de una manera u otra.

— squarecandy

4

Mi recomendación es que omita la mayoría de las etiquetas de cierre opcionales y todos los atributos opcionales con los que puede salirse con la suya. Muchos IDE se quejarán, por lo que es posible que no pueda omitir algunos de estos, pero generalmente es mejor para archivos de menor tamaño y menos desorden. Si tiene generadores de código, definitivamente omita las etiquetas finales allí porque puede obtener una buena reducción de tamaño. Por lo general, realmente no importa de una manera u otra.

Pero cuando importa, entonces actúa en consecuencia. En algunos trabajos míos recientes pude reducir el tamaño de mi HTML renderizado de 1.5 MB a 800 KB eliminando la mayoría de los atributos finales y de valor redundante generados para la etiqueta abierta, donde el texto del elemento era el mismo que el valor. Tengo alrededor de 200 etiquetas. Podría implementar esto de otra manera por completo, pero eso sería más trabajo ($$$), por lo que esto me permite hacer que la página sea más receptiva.

Solo por curiosidad descubrí que si eliminaba las comillas alrededor de los atributos que no los necesitaban, podría ahorrar 20 KB, pero a mi IDE (Visual Studio) no le gusta. También me sorprendió descubrir que la ID realmente larga que ASP.NET genera representa el 20% de mi archivo.

La idea de que alguna vez podríamos obtener una fracción relevante de HTML estrictamente válida fue errónea en primer lugar, así que haga lo que funcione mejor para usted y sus clientes. La mayoría de las herramientas que he visto o usado dirán que generan xhtml, pero en realidad no funcionan al 100%, y de todos modos no hay ningún beneficio en el cumplimiento estricto.

— usuario1777246
fuente

Apenas puedo aceptar omitir las etiquetas finales opcionales, pero me parece una mala idea omitir las comillas en los atributos. Estás arriesgando tu sitio para quebrar en algunos navegadores de esa manera. Si tiene archivos html de 800 kb, está haciendo algo gravemente incorrecto.

— Christoph

2

@ Christoph: Omitir etiquetas finales opcionales (como </p>o </li>) está perfectamente bien de acuerdo con las especificaciones HTML. Si el navegador no entiende eso, entonces es un problema con el navegador.

— Konrad Borowski el

2

Personalmente, soy fanático de XHTML y, como ghoppe, "trato de no omitir nunca las etiquetas finales porque me ayuda a ser riguroso y no omitir las etiquetas que son necesarias".

pero

Si está utilizando HTML 4.n deliberadamente, no se puede argumentar que incluirlos hace que sea más fácil consumir el documento, ya que la noción de buena formación en lugar de validez es un concepto XML, y pierde ese beneficio cuando prohibir ciertas etiquetas cercanas. Entonces, el único problema se convierte en la validez ... y si sigue siendo válida sin ellos ... también podría ahorrar el ancho de banda, ¿no?

— Richard JP Le Guen
fuente

2

El uso de etiquetas finales facilita el manejo de fragmentos porque su comportamiento no depende de elementos hermanos. Esta razón por sí sola debería ser lo suficientemente convincente. ¿Alguien más se ocupa de documentos html monolíticos?

— CortinaPerro
fuente

1

En algunos lenguajes de corchetes como C #, puede omitir los corchetes alrededor de una instrucción if si solo tiene dos líneas de largo. por ejemplo...

si ([condición])
[código]

pero no puedes hacer esto ...

if ([condición])
[código]
[código]

la tercera línea no será parte de la declaración if. perjudica la legibilidad y los errores pueden introducirse fácilmente y ser difíciles de encontrar.

por las mismas razones, cierro todas las etiquetas. etiquetas como la etiqueta img todavía necesitan cerrarse, pero no con una etiqueta de cierre separada.

— MiguelR
fuente

¿Podría dar un ejemplo de HTML que es tan complicado? En mi experiencia, las etiquetas finales opcionales no son tan engañosas.

— Kornel

Recuerdo haber tenido un problema con IE7 hace unos años, cuando encontré una etiqueta de li de apertura en una línea separada del texto que contenía, sin li de cierre, IE7 trató todas las viñetas como una gran viñeta. poner la etiqueta y el texto en una línea, o cerrar la etiqueta, solucionaría el problema. Sin embargo, parece que ahora no puedo reprochar esto, por lo que probablemente también tuvo algo que ver con el css en juego. pero no te culpo por tomar esto como un "¡Tengo una novia ... en Canadá!" historia.

— MiguelR

0

Si estuviera escribiendo un analizador HTML, ¿sería más fácil analizar HTML que incluye etiquetas de cierre opcionales o HTML que no? Creo que las etiquetas de cierre opcionales presentes lo facilitarían, ya que no tendría que inferir dónde debería estar la etiqueta de cierre.

Por esa razón, siempre incluyo las etiquetas de cierre opcionales, en la teoría de que mi página podría renderizarse más rápido, ya que estoy creando menos trabajo para el analizador HTML del navegador.

— Joel Mueller
fuente

1

Estoy en desacuerdo; La noción de buena formación en lugar de validez es un concepto solo XML y se vuelve irrelevante cuando tiene elementos cuyas etiquetas cercanas están prohibidas .

— Richard JP Le Guen

1

Entiendo eso, pero el elemento DOM representado tiene un principio y un final, incluso si su etiqueta HTML no lo tiene. Si incluye una <li>etiqueta sin etiqueta de cierre, en algún momento el navegador tendrá que decidir dónde termina el elemento y actuar como si hubiera puesto una etiqueta final en ese punto. Esto puede ser una cantidad relativamente trivial de lógica, pero "algo" sigue siendo más que "ninguno" y no creo que sea irrazonable suponer que dejar fuera las etiquetas finales opcionales hace más trabajo para el navegador que incluirlas.

— Joel Mueller

Es un punto interesante pero todavía no estoy de acuerdo; las etiquetas de cierre son opcionales, ya que serían necesarios y de esta manera implícita de acuerdo con las reglas de validación ... así que cuando el analizador llega a un punto donde no tiene que ser una etiqueta de cierre de acuerdo con la validación, no se podría argumentar que la tarea de consumir una etiqueta de cierre (cuando está presente) simplemente lo ralentizaría?

— Richard JP Le Guen

@ Richard - Supongo que eso depende de la implementación real en un navegador en particular, pero me resulta difícil reconocer la idea de que ser explícito sobre dónde quiere que termine un elemento sería peor para el rendimiento que decirle al navegador que lo descubra. tú.

— Joel Mueller

@RichardJPLeGuen Supongo que todo depende de cómo se vean exactamente las reglas. Cuando está cerrando </table>ay su pila contiene <table><tbody><tr><td>, simplemente puede cerrar todo hasta que coincida con el <table>. Del mismo modo para abrir <p>en un contexto que no sea de reloj. Pero puede haber casos mucho más difíciles, no lo sé.

— maaartinus

-1

Haga lo que crea que el código sea más legible y fácil de mantener.

Personalmente, siempre estaría inclinado a cerrar <td>y <tr>, pero nunca me molestaría <li>.

— Matthew Wilson
fuente

1

Esperaba alguna orientación sobre la decisión de diseño original, y que habrían hecho x si hubieran podido.

— Ian Boyd

¿Cuál es la diferencia entre <td>y <li>eso te hace no molestarte <li>? Para mí, hay poca diferencia.

— ghoppe

No hay diferencia técnica, es puramente subjetiva. Siento que puedo leer mejor el HTML si cierro td y tr. Pero nunca he sentido la necesidad de li.

— Matthew Wilson

-2

Para los tipos de cierre prohibidos, use una sintaxis como: <img />Con el />para cerrar la etiqueta que se acepta en xml

— Dani
fuente

1

No funciona en HTML4 (coincide con una sintaxis SGML oscura que hace algo ligeramente diferente). En HTML5 está permitido, pero no tiene sentido.

— Kornel