Algunas etiquetas de cierre HTML 1 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
1 HTML 4.01
</p>etiquetas de cierre y el segundo las omite!/>, por ejemplo<meta charset="utf-8" />, ¿aunque<meta charset="utf-8">es un HTML5 válido?<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" /><meta charset="UTF-8"/>con la etiqueta de cierre. De lo contrario, ¿cómo podrían validarse polyglot o xhtml como html5 y xml?Respuestas:
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.
fuente
<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.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 unul > ulárbol erróneo .Válido:
Inválido:
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:
analizará como:
Solo puede ayudar cuando valida documentos.
fuente
<p>foo <p>bar</p> baz</p>no se analiza como dospetiquetas anidadas ?<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)".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).<t>no funcionará como<title>.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 :
fuente
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.
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).
HTML 5 se orientó a "pavimentar los caminos de vaca" desde el principio.
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.
fuente
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
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.
fuente
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. :)
fuente
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.
fuente
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.
fuente
</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.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?
fuente
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?
fuente
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.
fuente
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.
fuente
<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.</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é.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>.fuente
<td>y<li>eso te hace no molestarte<li>? Para mí, hay poca diferencia.Para los tipos de cierre prohibidos, use una sintaxis como:
<img />Con el/>para cerrar la etiqueta que se acepta en xmlfuente