2010-10-26 19 views
35

Según w3c</TD> y </TR> las etiquetas son opcionales, por lo que la siguiente tabla es perfectamente válida.¿Es seguro omitir las etiquetas</TD> y</TR>?

<table> 
    <tr> 
    <td>google 
    <td>chrome 
</table> 

Y todos los navegadores que he probado con renderizar la tabla bien. Solo quería preguntar si esto generalmente se considera seguro de usar, o si los navegadores más antiguos, a los que no tengo acceso, causan problemas. Gracias.

Reduce el tamaño de gzip html en una página con muchas tablas por un pequeño porcentaje.

+54

No si la persona que lo reemplaza sabe cómo encontrarlo –

+0

¡Algunas versiones de IE pueden quejarse! – zerodin

+2

Además, tenga en cuenta que, como desarrollador, encontrará que muchos editores no seguirán esto, lo que dificultará el uso de la funcionalidad integrada del editor para buscar/contraer las etiquetas de cierre. También querrás asegurarte de que cualquier analizador XML DOM que uses seguirá funcionando correctamente. – webbiedave

Respuesta

15

Es seguro, ya que la opción en el estándar significa que todos los navegadores (al menos los que incluso remotamente importan) habrían implementado esto, y el cumplimiento de los estándares del navegador normalmente se ejecuta en el lado opuesto, tratando de funcionar correctamente incluso con HTML no válido en lugar de fallar en las etiquetas opcionales faltantes.

Habiendo dicho eso, me parece que omitir tales etiquetas hace que las cosas sean más difíciles de leer, lo que puede o no tener importancia si el objetivo es la optimización del tamaño.

P.S. Además, si tiene tablas muy grandes, me pregunto si el analizador de HTML del navegador incurre en gastos indirectos al tratar con tales construcciones. No estoy seguro sin una evaluación comparativa o un pensamiento realmente profundo sobre cómo funciona el analizador de HTML en detalle, pero es algo que podría ser un factor si sucede.

+2

La legibilidad no es un problema porque las tablas se generan automáticamente mediante una secuencia de comandos de Python. Sin embargo, noté un problema diferente. Muchos de los TD tienen un evento mouseover/mouseout adjunto a ellos para cambiar/restaurar el color de fondo, y IE rezaga el cambio de fondo cuando se omite el cierre de TD/TR. Otros navegadores no. –

+5

@pdknsk - pensé que el HTML autogenerado no importaba la legibilidad ... hasta la primera vez que tuve que depurar el HTML/JS resultante :) – DVK

+0

En cuanto al rendimiento: Sugeriría que eliminar las etiquetas de cierre realmente * mejora * la representación hora. Cuando llegas al '' y ya estás dentro de un '', los navegadores saben que este elemento no se puede anidar directamente y crea un nodo hermano. Con las etiquetas de cierre, el navegador tiene que leer algunos caracteres más antes de llegar al mismo punto. (Obviamente, este será un ahorro insignificante, incluso en una mesa grande.) – DisgruntledGoat

19

Esto es HTML válido pero no válido XHTML.
No hay nada intrínsecamente incorrecto con él.

Si nos fijamos en la fuente de Google's privacy policy (o cualquiera de sus otras páginas), encontrará algunos HTML mucho más terser.

Significa que su página no podrá ser utilizada por un analizador XML.

+11

Puede ser válido, pero es repugnante ... opinión personal – cwallenpoole

+9

Google tiene una escala diferente que la mayoría de nosotros; un solo byte puede guardar gigabytes por día. –

+0

En realidad, si elimina la última etiqueta de secuencia de comandos del documento (que de todos modos le faltan los elementos habituales), puede leerse mediante el analizador HTML DOMDocument de PHP ... no del todo XML, pero interesante sin excepción. – cwallenpoole

10

Recomiendo encarecidamente que no lo haga, aunque es válido en HTML4 (y 5). Los ahorros de ancho de banda son minúsculos cuando se los compara con la deuda técnica en la que incurres. También tenga en cuenta que no es válido en XHTML, así que asegúrese de que su doctype esté configurado apropiadamente.

+0

Wow; ¡alguien está realmente vinculado religiosamente a sus etiquetas HTML no cerradas! –

+10

¿En qué deuda técnica está incurriendo? – Chuck

+3

Perder algunas etiquetas de cierre TD no es "deuda técnica". La deuda técnica se usa generalmente para describir problemas relacionados con códigos/dominios a una escala mucho mayor. – nashwan

0

Cerrar todas las etiquetas en HTML para algunas razones:

etiquetas
  1. No cierre se tolera, pero no es correcto XHTML moderna. Está obsoleto en gran medida de la misma manera que los atributos de estilo HTML están a favor de CSS
  2. Es más legible para el próximo tipo si cierra las etiquetas
  3. Los navegadores en realidad tendrán un tiempo más fácil para analizar su fuente si se adhiere más estrictamente a las reglas, incluso si eso hace que la fuente sea más larga
+1

¿Por qué cerramos las etiquetas demasiado cerca de HTML porque es necesario en otro idioma? ¿Marcas todas tus variables de JavaScript globales con un $ porque es obligatorio en Ruby? Use estructuras de datos inmutables solo porque se requiere en Haskell? – Chuck

+0

@Chuck: ¡Qué fracaso! JavaScript no es una versión actualizada de Ruby. Tus ejemplos son ridículos. Es más como comparar C90 a C99. Además, cerrar etiquetas en HTML no es detallado, está claro. Eso es como decir que usar nombres de variables de más de 1 carácter es detallado. –

+1

@Rafe Kettler: Y XHTML no es una versión actualizada de HTML5, es una reformulación de HTML como un dialecto XML. Y digo "cierre exhaustivo" porque las etiquetas ya están cerradas simplemente creando otro 'tr' o cerrando la' tabla'. Escribir una etiqueta de cierre es una forma más detallada de lograr lo mismo que no escribir una etiqueta de cierre. Si es claro o no es subjetivo, pero es indudablemente más detallado. Y decir que "se adhiere más estrictamente a las reglas" de HTML es claramente falso. – Chuck

1

Aconsejo siempre el cierre de las etiquetas. Realmente no hay una buena razón para no hacerlo. Los navegadores pueden manejar algunas etiquetas mal cerradas, pero solo para estar seguros (¡y es una buena práctica de programación!), ¡Cierre sus etiquetas!

+2

No estamos hablando de etiquetas mal cerradas. Ese marcado es correcto y las etiquetas se cierran correctamente de acuerdo con el estándar de idioma. – Chuck

2

Personalmente no considero una buena práctica. Mirando la especificación no dio mucha información. Sé que es necesario para XHTML, así que busqué las especificaciones de HTML 5.HTML 5 parece tener la misma opinión sobre ella como HTML 4, que es lo que se ha establecido un vínculo, pero da a little more information:

etiqueta final de un elemento td puede omitirse si el elemento td es seguido inmediatamente por un td o th elemento, o si no hay más contenido en el elemento principal.

0

Ciertamente, si usted está utilizando solamente HTML hay absolutamente ningún problema eso no es el caso con XHTML, sin embargo, no creo que usted puede conseguir mucho, también sugiero dont tablas de abuso recuerdan div son mejores que las tablas

+3

Divs no son mejores que las tablas para mostrar datos tabulares. – Chuck

+0

Tienen más flexibilidad que la anterior Tabla simple prefiero un diseño regular Div que intentar hacer lo mismo con

Necronet

+0

@Necronet pero esto puede no ser necesariamente sobre un diseño, podría ser para una tabla literal, ya que son bastante común para mostrar datos tabulares. – semicolon

7

Ha habido etiquetas opcionales en HTML desde el principio: son una característica heredada de SGML, por lo que los primeros navegadores deben haber sido capaces de manejarlas. Si bien XHTML se alejó de esto y requirió una sintaxis mucho más uniforme, esto no le afecta a menos que le indique explícitamente al navegador que lo analice en modo XML. Nunca he visto un problema al usar los analizadores estándar de HTML 4/5.

Como HTML5 so carefully describe cuando ciertas etiquetas son opcionales, leería eso para dar a entender que alguien hizo muchas pruebas para asegurarse de que en estos casos, la mayoría de los navegadores producen el mismo árbol de documentos.

Y mientras que el ahorro de espacio son insignificantes, considero que dejar fuera de las etiquetas de cierre de <p>, <li>, <td>, y <tr> simplemente me hace la vida más fácil cuando estoy trabajando en el marcado, y me hace menos probable que un error.

1

¡Siempre cierre sus etiquetas!

+1

"Solo quería preguntar si esto generalmente se considera seguro de usar, o si los navegadores más antiguos, a los que no tengo acceso, causan problemas". No está respondiendo la pregunta, solo está expresando su opinión. – semicolon

-3

No está mal con páginas estáticas no para páginas dinámicas ... depurar

+0

¿No entendí esta respuesta? ... ¿Qué quiere decir estático sí pero en dinámico no? – Necronet

+0

@Necronet: Creo que * lo que está tratando de decir es que esta abreviatura hace que sea más difícil depurar la salida de su generador de HTML (presumiblemente porque es más difícil de leer). – Chuck

-3

Debe cerrar sus <TR> y <TD> etiquetas si es posible, pero no siempre, porque en algunos casos se puede molestar. Esto se debe a que las etiquetas <TR> y <TD> se pudieron diseñar con el estilo display:none, mientras que la etiqueta </TR> no. Significa que un escenario en el cual desea extender/limitar su pantalla con consultas de medios, fallará si usa </TR>. Considere el siguiente código:

<style> 
@media (max-width : 480px) { 
.hidden-class {display:none;} 
} 
</style> 

<table> 
    <tr> 
     <td>cell 1</td> 
    </tr class="hidden-class"> <!-- this will fail! --> 
    <tr class="hidden-class"> 
     <td>cell 2</td> 
    </tr>      <!-- this could stay --> 
</table> 

Esto significa que se escribirían como:

<table> 
    <tr> 
     <td>cell 1</td> 
    </tr> <!-- this will now close the TR for every screen width, which will destroy your extenstion --> 
    <tr class="hidden-class"> 
     <td>cell 2</td> 
    </tr>      <!-- this could stay --> 
</table> 

Lo que significa que la única manera de hacerlo es mediante la omisión de la en el primer lugar:

 <table> 
    <tr> 
     <td>cell 1</td> 
    <tr class="hidden-class"> 
     <td>cell 2</td> 
    </tr>      <!-- this could stay --> 
</table> 
+2

Ahora, ¿por qué en el mundo alguien pondría un atributo en una etiqueta de cierre? Eso no es válido _anywhere_. Si te encuentras haciendo eso a menudo, tienes otros problemas. –

+0

Bueno ... #Jeff Mercado, el punto es que usted no puede poner ese atributo en una etiqueta de cierre, sin embargo, le gustaría ponerlo en una etiqueta de apertura. Significa que el no coincidirá con la tabla, que es el punto de esta pregunta ....: SIEMPRE no debe usar – PalDev

+4

Si ese es su punto, entonces no tiene nada que ver con la pregunta. ¿Qué estás probando exactamente al introducir un marcado no válido? Todo lo que ha demostrado es que no debe poner marcas no válidas porque rompe las cosas. –