sirve - HTML: ¿incluye o excluye etiquetas de cierre opcionales?

que es html yahoo (14)

Algunas HTML ^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 para ser incluidas, es decir:

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

Nota: xhtml es diferente de HTML. xhtml es una forma de xml, que requiere que cada elemento tenga una etiqueta de cierre. Una etiqueta de cierre puede estar prohibida 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 pone en

En otras palabras, ¿ debería incluirlos o no debería incluirlos?

La especificación HTML 4.01 se refiere a 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 al azar sobre DevGuru dice :

La etiqueta de finalización 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 ( obligatorio | prohibido ) si pudieran tener.

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

Nota

Algunos elementos en HTML están prohibidos de tener etiquetas de cierre. Puede estar en desacuerdo con eso, pero esa es la especificación, y no está en debate. Estoy preguntando sobre las etiquetas de cierre opcionales , y cuál era la intención.

Notas a pie de página

¹ HTML 4.01

¿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 de cierre porque me ayuda a ser riguroso y no omitir las etiquetas que son necesarias.

La razón por la que pregunto es porque usted sabe que es opcional por razones de compatibilidad; y los habrían hecho (obligatorio | prohibido) si pudieran tener.

Esa es una inferencia interesante. Lo que leo es que casi cualquier momento en que una etiqueta pueda 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?

La DTD para HTML 2 está integrada en la RFC que, junto con la DTD HTML original, tiene etiquetas de inicio y final opcionales por todas partes.

HTML 3 fue abandonado (gracias a las guerras de los navegadores) 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ó hacia "pavimentar los caminos de los vacas" 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 del lector.

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

Creo que la mejor respuesta es incluir etiquetas de cierre para la legibilidad o la detección de errores. Sin embargo, si tiene muchos HTML generados (por ejemplo, tablas de datos), puede ahorrar ancho de banda significativo al omitir las etiquetas opcionales.

El uso de etiquetas finales facilita el tratamiento de los fragmentos porque su comportamiento no depende de elementos hermanos. Esta sola razón debería ser lo suficientemente convincente. ¿Alguien trata con documentos html monolíticos?

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

if ([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. lastima la legibilidad, y los errores pueden ser fácilmente introducidos, y ser difíciles de encontrar.

por las mismas razones, cierro todas las etiquetas. las etiquetas como la etiqueta img aún deben cerrarse, pero no con una etiqueta de cierre por separado.

Estoy agregando algunos enlaces aquí para ayudarte con la historia de HTML, para que entiendas 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 Dive Into HTML5 :

[E] l hecho de que el marcado HTML "roto" aún 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 soluciona.
El W3C vio esto como un problema fundamental con la web, y se dispusieron a corregirlo. XML, publicado en 1997, rompió con la tradición de perdonar a los clientes y ordenó que todos los programas que consumieran XML deben considerar los llamados errores de "buena formación" como fatales. Este concepto de falla en el primer error se conoció como "manejo de error draconiano", 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 un vocabulario XML, exigió que todos los documentos servidos con la nueva application/xhtml+xml tipo MIME estuvieran sujetos a un manejo draconiano de errores. Si había incluso un solo error de buena formación en su página XHTML, [...] los navegadores web no tendrían más opción que detener el procesamiento y mostrar un mensaje de error al usuario final.
Esta idea no fue universalmente popular. Con una tasa de error estimada del 99% en las páginas existentes, la posibilidad omnipresente 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 de la 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 una laguna: "Utiliza algo que se parece a la sintaxis XHTML, pero sigue sirviendo con el tipo text/html MIME". Y eso es exactamente lo que hicieron miles de desarrolladores web : se "actualizaron" a la sintaxis XHTML pero siguieron sirviendo con un tipo MIME text / html.
Incluso hoy en día, millones de páginas web afirman ser XHTML. Comienzan con el doctype XHTML en la primera línea, usan nombres de etiquetas minúsculas, usan comillas alrededor de los valores de los atributos y agregan una barra al final después de elementos vacíos como <br /> y <hr /> . Pero solo una pequeña fracción de estas páginas se sirve con la application/xhtml+xml tipo MIME que desencadenaría el manejo de error draconiano de XML. Cualquier página servida con un tipo MIME de text/html , independientemente del tipo de documento, sintaxis o estilo de codificación, se analizará utilizando un analizador HTML "indulgente", ignorando silenciosamente cualquier error de marcado y nunca alertando a los usuarios finales (ni a nadie), incluso si las páginas están técnicamente rotas.
XHTML 1.0 incluyó este vacío, pero XHTML 1.1 lo cerró, y el XHTML 2.0 nunca finalizado continuó la tradición de requerir el manejo de errores draconianos. Y es por eso que hay miles de millones de páginas que dicen ser XHTML 1.0, y solo unas pocas que afirman ser XHTML 1.1 (o XHTML 2.0). ¿De verdad estás usando XHTML? Verifica tu tipo MIME. (En realidad, si no sabes qué tipo de MIME estás usando, puedo garantizarte que todavía estás usando text/html ). A menos que estés publicando tus páginas con un tipo de application/xhtml+xml MIME application/xhtml+xml , su llamado "XHTML" es XML solo por nombre.

[L] a gente que había propuesto la evolución de formularios HTML y HTML se enfrentaba con dos opciones: renunciar o continuar su trabajo fuera del W3C. Eligieron este último, registraron el dominio whatwg.org y en junio de 2004, nació el grupo de trabajo WHAT .

[T] él qué grupo de trabajo estaba trabajando silenciosamente en algunas otras cosas también. Una de ellas era una especificación, inicialmente llamada Web Forms 2.0 , que agregaba nuevos tipos de controles a formularios HTML. (Aprenderá más acerca de los formularios web en A Form of Madness ). Otra fue una especificación preliminar llamada "Web Applications 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 el W3C anunció los Grupos de Trabajo HTML y XHTML 2 en marzo de 2007, indicamos que seguiríamos monitoreando el mercado de XHTML 2. W3C reconoce la importancia de una señal clara para la comunidad sobre el futuro de 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 la discusión con los participantes, la administración del W3C ha decidido permitir que el estatuto del Grupo de Trabajo expire a fines de 2009 y no lo renueve.
Los que ganan son los que envían.

Haga lo que sienta que hace que el código sea más legible y mantenible.

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

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

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

Por ejemplo, nunca necesita </body></html> . Nadie recuerda nunca poner <tbody> explícitamente (al punto que XHTML hizo excepciones para ello).

No necesita </head><body> menos que tenga scripts que manipulen DOM que realmente busquen <head> (entonces es mejor cerrarlo explícitamente, porque las reglas para end implied de <head> podrían sorprenderlo).

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

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 ya sea que intente cerrar todos los elementos o no. Poner etiquetas finales no hará automáticamente el análisis más robusto:

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

analizará como:

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

Solo puede ayudar cuando valida documentos.

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

Las etiquetas de extremo prohibidas todas serían seguidas inmediatamente por su etiqueta final, por lo que sería redundante tener que escribir <img src="blah" alt="blah"></img> todas las veces.

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.

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 IDEs se quejarán por lo que es posible que no pueda salirse con la suya al omitir algunos de estos, pero en general es mejor para archivos de menor tamaño y menos desorden. Si tiene generadores de código, definitivamente omita las etiquetas de cierre porque puede obtener una buena reducción de tamaño de la misma. Usualmente no importa de una forma u otra.

Pero cuando sí importa, actúen en consecuencia. En algunos de mis trabajos recientes, pude reducir el tamaño de mi HTML renderizado de 1.5 MB a 800 KB al eliminar la mayoría de los atributos de valor final y 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 completamente, pero eso sería más trabajo ($$$), así que esto me permite hacer que la página sea más receptiva.

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

La idea de que pudiéramos obtener alguna fracción relevante de HTML estrictamente válida fue, en primer lugar, errónea, así que haga lo que sea mejor para usted y sus clientes. La mayoría de las herramientas que he visto o usado dicen que generan xhtml, pero en realidad no funcionan al 100%, y de todos modos no hay ningún beneficio para la adherencia estricta.

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

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

pero

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

Si es superfluo, déjalo fuera.

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

Es raro encontrar en una especificación bien definida productos opcionales que no afecten el comportamiento. Con la excepción de "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 que no sirve para nada, podemos suponer que la naturaleza opcional es meramente documentación de una peculiaridad en un navegador específico.

Al observar la sección RFC de especificación de HTML-5 vinculada anteriormente, verá que las etiquetas opcionales están extrañamente vinculadas a la presencia de comentarios. Eso debería decirte que los autores no usan sombreros de diseño. En su lugar, están jugando el juego de "documentar las peculiaridades" en las principales implementaciones. Entonces, no podemos tomar las especificaciones demasiado en serio a este respecto.

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

Si estuviera escribiendo un analizador HTML, ¿sería más fácil analizar HTML que incluyera etiquetas de cierre opcionales, o HTML que no lo haga? Creo que las etiquetas de cierre opcionales estarían presentes lo haría más fácil, 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 de HTML del navegador.