it-swarm-es.com

¿Por qué las personas hacen tablas con divs?

En el desarrollo web moderno me encuentro con este patrón cada vez más a menudo. Se parece a esto:

<div class="table">
    <div class="row">
        <div class="cell"></div>
        <div class="cell"></div>
        <div class="cell"></div>
    </div>
</div>

Y en CSS hay algo como:

.table { display: table; }
.row { display: table-row; }
.cell { display: table-cell; }

* (El nombre de la clase es solo ilustrativo; en la vida real esos son nombres de clase normales que reflejan de qué se trata el elemento)

Incluso recientemente intenté hacerlo yo mismo porque ... ya sabes, todos lo están haciendo.

Pero todavía no lo entiendo. ¿Por qué estamos haciendo esto? Si necesita una tabla, simplemente haga un arruinado <table> y terminemos con eso. Sí, incluso si es por diseño. Para eso están las mesas: diseñar cosas en forma de tabla.

La mejor explicación que tengo es que ahora todos han escuchado el mantra de "no usar tablas para el diseño", por lo que lo siguen a ciegas. Pero todavía necesitan una tabla para el diseño (porque nada más tiene las capacidades de expansión de una tabla), por lo que hacen un <div> (porque es no una tabla!) y luego agrega CSS que la convierte en una tabla de todos modos.

Para todo el mundo, esto me parece como poner obstáculos arbitrarios innecesarios en tu camino y luego hacer un trabajo extra para sortearlos.

El argumento original para alejarse de las tablas para el diseño fue que después es difícil modificar un diseño tabular. Pero modificar un diseño de "tabla falsa" es igual de difícil y por las mismas razones. De hecho, en la práctica, modificar un diseño siempre es difícil, y casi nunca es suficiente simplemente cambiar el CSS, si quieres hacer algo más serio que pequeños ajustes. Usted will necesita comprender y cambiar la estructura HTML para cambios de diseño serios. Y las tablas no hacen el trabajo más difícil o más fácil que los divs.

De hecho, la única forma en que veo que las tablas pueden hacer que un diseño sea difícil de modificar es si ablos usó y creó un desastre impío. También puedes hacer eso con divs.

Entonces ... en un intento de cambiar esto de una queja a una pregunta coherente: ¿qué me estoy perdiendo? ¿Cuáles son los beneficios real de usar una "tabla falsa" sobre una real?

Acerca del enlace duplicado: Esta no es una sugerencia para usar otra etiqueta o algo. Esta es una pregunta sobre el uso de un <table> vs display:table.

278
Vilx-

Este es un patrón común para hacer tablas receptivas. Los datos tabulares son difíciles de mostrar en los móviles, ya que la página se ampliará para leer el texto, lo que significa que las tablas salen del costado de la página y el usuario tiene que desplazarse hacia atrás y adelante para leer la tabla, o la página se alejará , generalmente significa que la tabla es demasiado pequeña para poder leerla.

Las tablas receptivas cambian de diseño en pantallas más pequeñas: a veces algunas columnas están ocultas o las columnas se amalgaman, p. el nombre y la dirección de correo electrónico pueden estar separados en pantallas grandes, pero colapsan en una celda en pantallas pequeñas para que la información sea legible sin tener que desplazarse.

<div>s se utilizan para crear las tablas en lugar de <table> etiquetas por un par de razones. Si <table> las etiquetas se utilizan, entonces debe anular los estilos y el diseño predeterminados del navegador antes de agregar su propio código, por lo que en este caso <div> las etiquetas se guardan en una gran cantidad de CSS repetitivo. Además, las versiones anteriores de IE no le permiten anular los estilos de tabla predeterminados, por lo que usar <div>s también suaviza el desarrollo entre navegadores.

Hay una muy buena descripción general de tablas receptivas en CSS-Tricks .

Editar: Debo señalar que no estoy abogando por este patrón, cae en la trampa de la divitis y no es semántico, pero es por eso que encontrarás tablas hechas de divs.

122
whostolemyhat

La pregunta es si los datos son semánticamente una tabla (es decir, un conjunto de datos o unidades de información organizadas lógicamente en dos dimensiones) o si simplemente usa la cuadrícula para el diseño visual, p. porque quieres que se expanda una barra lateral o algo así.

Si su información es semánticamente una tabla, utiliza un <table>-etiqueta. Si solo desea una cuadrícula para fines de diseño, use algunos otros elementos html apropiados y use display:table en la hoja de estilo.

¿Cuándo son los datos semánticamente una tabla? Cuando los datos se organizan lógicamente a lo largo de dos ejes. Si tiene sentido con encabezados para las filas o columnas, entonces podría tener una tabla semántica. Un ejemplo de algo que no es semánticamente una tabla es presentar un texto en columnas como en un periódico. Esto no es semánticamente una tabla, ya que aún la leería linealmente y no se perdería ningún significado si se eliminara la presentación.


OK, por qué no usa <table> para todo en lugar de solo para algo que es semánticamente una tabla? Visualmente es obviamente lo mismo (ya que el elemento de la tabla solo tiene display:element en la hoja de estilo predeterminada).

La diferencia es que la información semántica puede ayudar a los agentes de usuario alternativos. Por ejemplo, un lector de pantalla puede permitirle navegar en dos dimensiones en la tabla y leer los encabezados de una celda para ambos ejes si olvida dónde se encuentra. Esto sería confuso si la tabla no fuera semánticamente una tabla, sino que solo se usara para el diseño visual.

Los <table> versus display:table la discusión es solo un caso del principio más general del uso del marcado semántico. Ver por ejemplo: ¿Por qué molestarse en marcar de manera adecuada y semánticamente? o ¿Por qué se da más peso al marcado semántico para los motores de búsqueda?

En algunos lugares, es posible que se le exija legalmente que use el marcado semántico por razones de accesibilidad, y en cualquier caso no hay razón para hacer que su página sea menos accesible a propósito.

Incluso si no le importan los usuarios discapacitados, tener una presentación separada del contenido le brinda beneficios. P.ej. su diseño de tres columnas podría presentarse en una sola columna en un dispositivo móvil utilizando una hoja de estilo alternativa.

154
JacquesB

En realidad, diría que el uso de nombres de clase como "tabla" en su ejemplo demuestra cómo las personas realmente no entienden lo que están haciendo cuando intentan un marcado semántico. Obtienen marcas por tratar de mostrar que el contenido no son datos tabulares , pero pierden marcas por nombres de clase incorrectos.

<div class="table">
  <div class="row">
    <div class="cell"></div>
    <div class="cell"></div>
    <div class="cell"></div>
  </div>
</div>

Todo lo que este desarrollador ha hecho es replicar el original <table> marcado con nombres de clase CSS. Esto significa que tan pronto como este diseño no sea una tabla, los nombres de las clases están en desacuerdo.

Lo que este desarrollador debería haber hecho es considerar qué información hay en la tabla: ¿es una galería de miniaturas? Bien entonces:

<div class="thumbnail-gallery">
  <div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
  </div>
</div>

Ahora puedo crear algunos CSS adaptativos:

@media screen {
  .thumbnail-gallery {
    display: table;
    border-collapse: collapse;
    width: 100%;
  }

  .thumbnail-gallery > div {
    display: table-row;
  }

  .thumbnail-gallery .thumbnail {
    display: table-cell;
    border: 1px solid #333333;
  }
}

@media screen and (max-width: 640px) {
  /** reset all thumbnail gallery elements to display as block and fill screen **/
  .thumbnail-gallery,
  .thumbnail-gallery > div,
  .thumbnail-gallery .thumbnail {
    display: block;
    width: 100%;
  }
}

Por qué divs y no tablas

na tabla contiene datos tabulares - la presentación de una tabla está indisolublemente vinculada a la estructura de una tabla. Los datos tabulares siempre tendrán que estar en forma tabular sin importar dónde coloque ese contenido o en qué pantalla/dispositivo desea que se muestre.

Una galería de miniaturas (o muchas otras cosas, como un formulario de registro, un menú y más) no son datos tabulares. Puede presentarse como una tabla en algunos diseños de diseño, pero en otros casos, como pantallas de teléfono estrechas, lo desea utilizando diseños de bloque más tradicionales. O tal vez desee mostrar miniaturas en una barra lateral en lugar de en el área de contenido principal.

Su elección ahora es generar un marcado diferente para el contenido de pantalla ancha (tablas) y el contenido de la barra lateral o de pantalla estrecha (divs), lo que significa que las secuencias de comandos del lado del servidor tendrán que saber a dónde va el contenido si está creando esto mediante programación - o si su secuencia de comandos del lado del servidor genera el mismo marcado (porque no debería importar dónde está colocando esto) y usa diferentes reglas CSS para las diferentes situaciones.

Por lo tanto, tiene la opción de generar siempre tablas y anular las reglas de visualización de la tabla natural con bloque (que realmente debería rectificar algunos engranajes en cualquier cabeza de desarrollador), o ir con divs bien etiquetados que permiten enfoques más flexibles para el estilo.

Y las mejores prácticas desde hace varios años ha sido evitar tablas cuando no es necesario presentar datos tabulares.

102
HorusKol

En los viejos tiempos, el motor de representación de tablas "apareció" era más lento cuando usaba porcentajes para anchos de columna. El motor esencialmente tuvo que descargar todo el conjunto de datos antes de comenzar a averiguar qué tan grande era dibujarlo en la pantalla.

El motor DIV era diferente. A medida que el navegador encuentra un DIV, continúa, lo coloca y comienza a llenar el contenido en línea. Por supuesto, los div podrían saltar cuando los datos terminen de cargarse. De ahí por qué he aparecido en las citas anteriores. El marco de tiempo para completar ambos fue el mismo, sin embargo, las tablas no se dibujaron hasta el final, lo que significaba que el usuario no estaba seguro de si se estaba cargando o no durante un segundo o dos.

Esto empeoró a medida que las tablas estaban anidadas.

Hubo entonces (y todavía existen) formas de hacer que la representación de tablas sea MUCHO, MUCHO más rápida. Básicamente, al darle una pista de que los tamaños de las columnas no están cambiando, el navegador comienza a procesar los datos tabulares de inmediato. En última instancia, esto significa que las tablas pueden mostrarse en la posición correcta más rápido que los divs, lo que les da la apariencia de ser mejores.

Pero esa no es toda la historia. El resto es que la mayoría de los desarrolladores simplemente no se molestan en aprender su oficio lo suficientemente bien como para saber esto. En su lugar, se suben a varios vagones y van con el código que puedan copiar/pegar. Incluso hoy encuentro que muy pocos desarrolladores web saben la diferencia de un doctype al siguiente, y esa es la razón número uno por la que varios sitios tienen todo tipo de soluciones para cubrir varios navegadores.

Entonces, +1 a ti por hacer la pregunta.

11
NotMe

Si puedo obtener un pequeño "meta" aquí, esto me trae a la mente dos problemas:

Uno: Alguien propone una regla por alguna buena razón, y la gente pierde completamente el punto al seguir la letra técnica de la regla mientras ignora el espíritu. Encuentran alguna forma de lograr todas las cosas malas que la regla intentaba evitar, mientras que técnicamente siguen la regla tal como está redactada.

Dos: alguien ve un problema y propone una regla para evitarlo. Otros ven el valor de esta regla. Luego insisten en la devoción ciega a esta regla sin tener en cuenta el problema original que se suponía que debía resolver y/o independientemente de los otros problemas que crea. He tenido muchas conversaciones en las que alguien dice: "Debes hacer X porque esa es la regla", y luego pregunto: "¿Pero por qué deberíamos hacer X?", Y me miran con desconcierto y exasperación y dicen: "Pero ¡Te acabo de decir! ¡Porque es la regla! " Respondo: "Pero parece causar más problemas de los que resuelve. Creo que sería mejor hacer Y". Y luego la persona dice: "No, mira, te lo mostraré. Mira, está justo aquí en este libro. X es la regla".

En este caso, tenemos un problema: la etiqueta de tabla hace dos cosas: una, controla el diseño de un documento. Dos, transmite la idea de que los datos adjuntos están formados por filas y columnas de números u otros datos.

Mucha gente propuso la solución: no use etiquetas de tabla para controlar el diseño de cosas que no son lógicamente "tablas". Utiliza CSS.

Pero hay un problema con esta solución. La etiqueta de tabla y sus subetiquetas realizan muchas funciones de diseño muy útiles que no son fáciles de lograr con CSS, y cuando se pueden lograr, el código necesario para hacerlo es a menudo engorroso, difícil de leer y difícil de mantener. ¿Por qué debemos hacer las cosas de una manera torpe y difícil cuando hay una manera limpia y fácil?

Personalmente, creo que habría sido mejor declarar: "El hecho de que algo esté dentro de una etiqueta de tabla no significa necesariamente que represente filas y columnas de números". Esto no habría sido una declaración escandalosa. Nunca escuché a alguien decir que la etiqueta "p" solo se puede usar para cosas que en realidad son párrafos de oraciones en inglés gramaticalmente correctas y lógicamente construidas. Nunca escuché a alguien decir que está mal usar una etiqueta "ul" para una lista que, de hecho, viene en un orden lógico, solo porque quería viñetas y no números de secuencia. Etc.

5
Jay

Ya hay toneladas de excelentes respuestas aquí. Pero quería agregar que los elementos table tienen limitaciones de representación que no existen para los elementos div. Intente y cree una tabla que haga un desplazamiento virtual (como: SlickGrid , DataTables , y otros) y se sentirá muy decepcionado. Simplemente no funciona. La mayoría de las grillas Javascript modernas (¿Todas?) Usan divs porque el CSS permite una representación mucho más flexible.

También hay otras limitaciones. Mi regla general es que si voy a ver toda la tabla en una sola pantalla y no quiero ninguna/mucha representación personalizada para ello, uso un elemento table, de lo contrario, voy con divs porque Puedo controlar los resultados mucho, mucho más fácilmente.

5
Crisfole

HTML y CSS han desarrollado un grado de flexibilidad que significa que incluso conceptualmente "bloquean" elementos como <div> (La forma de contenido de bloque más antigua y general de HTML) no necesita mostrarse como bloques:

div { display: inline; }

Como notas, <div> se puede reutilizar para emular <table> y sus compañeros de viaje. En realidad, la mayoría de las etiquetas pueden. Dados sus roles especiales, dudo que pueda reasignar provechosamente las etiquetas macro como <html>, <head>, <body> y <script>, pero etiquetas "comunes" como <div>, <p>, <b>, <em>, <span> y <pre>? En juego. Haga que los bloques de etiquetas en línea, los bloques en línea, las etiquetas preformateadas fluyan, las fijas floten. ¡Enloquece, si quieres!

Es posible . Es posible que desee hacer un hilo sobre cómo todos deberíamos usar "marcado semántico" bla bla, ¡bla, o creer con los Pythonistas que "debería haber uno, y preferiblemente solo uno, obvio forma de hacerlo ". Sin embargo, Tim Toady es un tipo inteligente y curioso. Con una mano libre, los explorará a todos. Eso incluye el uso de la flexibilidad disponible para realizar sustituciones. Algunos son sabios, algunos se demostrarán lo contrario. Pero la prueba, el error y la experiencia son la única forma de descubrirlo. Entonces las condiciones suficientes para la sustitución están presentes.

No creo que sea exagerado decir que la sustitución también es necesaria. Como mínimo, es extremadamente conveniente . Durante mucho tiempo, HTML no tenía <menu>, <section> o <aside> elementos. Sin embargo, las páginas web y las aplicaciones en todas partes tienen menús, secciones y barras laterales. ¿Cómo? Porque los elementos de la lista HTML (<ul>, <ol> y <li>) se reutilizaron fácilmente y algunos usos se reclasificaron como contenedores de menú y partes. <div> podría reemplazar a <article>, <section>, <aside>, <figure> y <summary>. HTML5 se ha puesto al día y ha agregado elementos a medida para algunos casos de uso no abordados anteriormente. Es una gran actualización y corrección para acomodar el uso común en el mundo real.

Aun así, quedan muchos modismos comunes que no tienen etiquetas a medida o modelos semánticos . Cosas como páginas, notas al pie, citas extraídas, secuencias de comentarios, avatares asociados, "me gusta", subtítulos y subtítulos que yo y muchos otros usamos todos los días. Qué vamos a hacer? Lo que podemos Reutilice elementos "cercanos pero inexactos" con clases e identificadores para respaldar nuestro trabajo durante los próximos cinco o diez años, o por muchos años, hasta que HTML6 o HTML7 se pongan al día. El HTML/CSS "sí, es una X, en teoría, pero vamos a etiquetarlo y trabajar con él como una Y" es increíblemente conveniente. Indispensable, de verdad. Hace que el contenido web sea flexible y no sea frágil.

Yendo aún más lejos, "marcado semántico" tiene limitaciones irreducibles . Eso es cierto para cualquier tipo de estructura rigurosa que puedas imaginar para el contenido.

Los formatos estándar no pueden abarcar toda la riqueza de la necesidad humana, el deseo y la variedad. Siempre estarán "detrás de la curva" de lo que la gente está haciendo ¡ahora. Cómo están innovando. Diablos, HTML5 todavía está detrás de la curva en notas al pie, subtítulos y otras innovaciones de impresión del siglo XVII. Carece de características esenciales para muchos trabajadores de la información y creadores de contenido. Entonces improvisamos.

Aún más inmutable es que la información no cumple con un conjunto de reglas. Claro, comienza como una mesa. Pero tal vez solo desee el resumen: diga el título de cada fila como una lista. Tal vez ocupa demasiado espacio, y le gustaría tenerlo como una lista en línea para ahorrar espacio. Tal vez tenga registros de los que solo desea el título, luego, si hace clic, verá los detalles subyacentes. O desea que los elementos de una lista o tabla compleja se agrupen y categoricen. Oh, ahora lo quieres transponer y categorizar de una manera diferente. O los valores trazados como un gráfico de barras. Estas son cosas que se hacen todos los días en aplicaciones, hojas de cálculo y visualización de datos. Son parte integrante de nuestro panorama de información y de lo que queremos y necesitamos hacer en la web. Los humanos reorganizamos constantemente la forma y la presentación de nuestros datos. No es solo una cosa, o un formato/diseño, o un concepto. Es fungible, con una semántica que depende de las circunstancias y de las elecciones que los usuarios hagan de forma interactiva. Sí, marque el texto como "enfatizado" (<em>), pero eso es solo una convención. He trabajado en documentos con al menos media docena de diferentes tipos de "énfasis". Nosotros necesitamos poder personalizar y reasignar eso para diferentes usos, diferentes interpretaciones. ¿Un tipo de énfasis en HTML? Atrozmente reduccionista. Limitante Frágil. Lo mismo es cierto para <table>, <p>, etc.

Es genial tener etiquetas/elementos que ayuden a organizar el pensamiento de toda la comunidad sobre "qué va a dónde". Eso ayuda a establecer convenciones y modismos, y nos hace colectivamente más eficientes. ¿Pero la capacidad de reasignar cosas, rediseñar y reutilizar esas estructuras? Eso es parte integrante de la inclusión de la Web y su éxito.

3
Jonathan Eunice

Los casos de uso son importantes. Hay una gran diferencia entre el diseño/presentación en una página de contenido y en una aplicación. En el contenido, la semántica es muy importante para la conciencia de SEO y la usabilidad. En estos casos, usar tablas para presentar datos tabulares es, en general, lo correcto. Como otros han señalado, los motores de búsqueda lo penalizarán e incluso puede entrar en conflicto con las leyes de usabilidad si la ley le exige que cumpla con las pautas de usabilidad del gobierno.

En una aplicación web, los desarrolladores pueden optar por crear vistas completamente separadas para fines de SEO y usabilidad. El diseño receptivo ha llevado a las personas a crear vistas que pueden manejar diseños de escritorio y móviles, y los divs son mejores que las tablas en esos casos de uso.

Tome los sitios de comercio electrónico, por ejemplo. Ver una lista de productos en un resultado de búsqueda o búsqueda muestra, en general, una lista de productos en formato tabular, pero esas vistas pueden generarse utilizando divs (que proporcionan opciones de diseño y estilo más genéricas y flexibles) en lugar de tablas. Amazon y eBay son buenos ejemplos de este enfoque. Inspeccione un resultado de búsqueda en cualquiera de los sitios y verá un conjunto de divs profundamente anidados.

0
Robert Munn