¿Por qué las personas hacen tablas con divs?

269

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 mesa, simplemente haga una arruinada <table>y termine con ella. 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 necesita una mesa de diseño (porque nada más tiene la capacidad de expansión de una mesa), por lo que hacer una <div>(porque es no una mesa!) Y luego añadir CSS que hace que sea una mesa 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 va a necesitar para entender y cambiar la estructura HTML para cambios de diseño graves. Y las tablas no hacen el trabajo más difícil o más fácil que los divs.

De hecho, la única manera que veo que las tablas podrían hacer un diseño difícil de modificar, si es ab les hayan utilizado y creado 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 reales de usar una "tabla falsa" sobre una real?

Acerca del enlace duplicado: Esta no es una sugerencia para usar otra etiqueta o algo así. Esta es una pregunta acerca del uso de un <table>frente display:table.

Vilx-
fuente
66
@JuhaUntinen: eso ... suena poco probable. ¿Fuente?
Paul D. Waite
55
@ PaulD.Waite - Creo que todavía es cierto hoy. Lee las otras respuestas. A menos que la tabla lo tenga table-layout:fixed, deberá cargarse por completo antes de poder mostrarse. Con la banda ancha moderna, este efecto es simplemente menos notable.
Vilx-
44
@JuhaUntinen: Eso no es del todo exacto. El motor de renderizado de tablas era más lento cuando usaba porcentajes para anchos de columna, ya que toda la tabla tenía que descargarse antes de que el navegador pudiera comenzar a calcular qué tan grande era hacer todo. Esto fue demasiado complicado por las tablas anidadas. Sin embargo, entonces había (y todavía existen) formas de hacer que la representación de tablas MUCHO MUCHO sea más rápida. Muy pocos desarrolladores se molestan en aprender su oficio lo suficientemente bien y, en cambio, se suben a los carros.
NotMe 01 de
44
En los días más antiguos, solíamos imitar divs con tablas, así que allí.
Wyatt Barnett
44
Alguien leyó que se suponía que no debían usar tablas para el diseño y entendió que no debían usar tablas en absoluto. Detesto esta tendencia.
Casey

Respuestas:

120

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 se apartan al 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 están amalgamadas, por ejemplo, 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>se usan etiquetas, debe anular los estilos y el diseño predeterminados del navegador antes de agregar su propio código, por lo que en este caso las <div>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 el uso de <div>s también facilita el desarrollo entre navegadores.

Hay una buena visión general de las 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.

whostolemyhat
fuente
66
Estoy aceptando esta respuesta porque parece que ya no viene nada más útil. Hay respuestas con más votos pero básicamente dicen "porque la semántica" (y la única razón para la semántica que pueden proporcionar es lectores de pantalla, lo que no me convence). La respuesta de @ HorusKol mencionó la capacidad de respuesta antes que la suya, pero la suya es más importante. Si aparece una mejor respuesta en el futuro, la cambiaré para que sea la aceptada.
Vilx-
55
Esto es ridículo y vago. Cualquier cosa que esté haciendo con <div>"tablas" probablemente podría hacerse con las regulares, por lo que literalmente no hay razón (aparte de las versiones antiguas de IE y la pereza) para usar elementos no semánticos para construir tablas. Dicho esto, los datos tabulares reales parecen raros en Internet, por lo que tal vez esto no sea un problema.
Usted
1
@Vilx: La pregunta que planteó es "¿Por qué las personas están haciendo tablas con divs", que es a lo que está recibiendo respuestas? Por ejemplo, es posible que no le interesen los lectores de pantalla, pero eso no cambia que la accesibilidad es una preocupación real para muchos y (junto con los motores de búsqueda) la razón principal por la que muchas personas eligen HTML semántico.
JacquesB
13
Para todos los efectos, esto es simplemente incorrecto. Si sus datos son tabulares, van en una tabla. Afirmar que las tablas se comportan especialmente mal en un dispositivo móvil es BS. Puede cambiar fácilmente las propiedades de visualización de los elementos de la tabla para que sean valores que no sean de tabla, así como puede hacer que los elementos que no sean de tabla tengan valores de tabla.
cimmanon
8
Creo que esta respuesta es un poco engañosa. Las tablas receptivas son un buen diseño, pero es independiente de la pregunta de si debe usar <table> o <div>; puede usar cualquiera de ellas con el mismo efecto visual. De hecho, esto es fundamental en la idea de separación de estructura y presentación. Es cierto que las versiones anteriores de IE no permitían anular el estilo de la tabla, pero las versiones anteriores de IE tampoco admitían display: table, por lo que no podía usar tablas receptivas de ninguna manera.
JacquesB
153

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, por ejemplo, porque desea que se expanda una barra lateral o algo así.

Si su información es semánticamente una tabla, utiliza una <table>etiqueta. Si solo desea una cuadrícula para propósitos de diseño, use algunos otros elementos html apropiados y use display:tableen 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 usar <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:elementen 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 podría 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 utilizara para el diseño visual.

La discusión <table>versus display:tablees 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ántica? o ¿Por qué se le da más peso al marcado semántico a 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 ninguna razón para hacer que su página sea menos accesible.

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

JacquesB
fuente
14
@ Vilx: ¿por qué usar <em>y en <strong>lugar de <b>y <i>? Porque <b>y <i>no se trata de la semántica de la etiqueta. <table>tiene significado semántico . Usarlo para algo que no es una tabla hace que sea más difícil entender el significado semántico del documento.
22
@ Vilx: The book <i>Peoplesoft</i> is the <em>best</em> book on the subject. poner lo <i>mejor sería incorrecto porque eso significa algo diferente al <i>título del libro. Para obtener más información, consulte ¿Por qué están en desuso las etiquetas <b>y <i>? y ¿Cuál es la diferencia entre <b>y <strong>, <i>y <em>?
19
Si no le importa lo que significa su contenido, le sugiero que deje de usar cualquier elemento, excepto formularios y divs. Simplemente agregue clases para aplicar estilo y comportamiento.
Rich Remer
99
@ Vilx-: cuando dice que le importa la experiencia de sus usuarios, parece que solo se refiere a un subconjunto de sus usuarios. La razón principal para usar el marcado correctamente en la forma en que está describiendo es la accesibilidad, que se relaciona directamente con la experiencia del usuario de los usuarios discapacitados. Estas son las personas que se benefician de que usted haga las cosas de la manera correcta e ignore estas convenciones, lo que probablemente haga que su experiencia web sea más difícil.
rooby
31
@ Vilx-, sí, un lector de pantalla trata una <table> muy diferente de una <div>. Los <div> s se ignoran y se leen secuencialmente. Dentro de una <table> tiene que proporcionar diferentes teclas / comandos de navegación ("Saltar a la celda a la derecha", "Leer el título de la columna y la fila", etc.), y expresar diferente información de ubicación (cuando el flujo de lectura ingresa a una tabla va algo así como "Tabla 3, fila 1, columna 1, Lorem Ipsum dolor ... ")
Euro Micelli
102

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 <table>marcado original 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?

Una 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, desea usar diseños de bloque más tradicionales. O quizás 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 engranar 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 han sido evitar las tablas cuando no es necesario presentar datos tabulares.

HorusKol
fuente
Los nombres de las clases fueron en realidad solo un ejemplo. En la vida real, en su mayoría son propiamente descriptivos. De todos modos, en tu ejemplo, ¿por qué lo usas en <div>lugar de <table>? ¿Qué beneficios ofrece?
Vilx-
1
Hmm ... bueno, en tu caso en realidad haces dos representaciones diferentes del mismo HTML a través de consultas de medios. OK, ese es un buen caso de uso. Pero si este no fuera el caso, y sabría de antemano que esta galería de miniaturas solo se mostrará en un lugar y solo en formato tabular, ¿usaría un <table>entonces o aún display:table? Porque, bueno, en cierto modo son datos tabulares. Excepto que los "datos" son imágenes, pero aún así.
Vilx-
15
bueno, no, no son datos tabulares. lo presenta en una cuadrícula que se parece a una tabla. Los datos tabulares son estadísticas e información comparativa; piense como una hoja de cálculo. ¿Diría que la vista en miniatura en el explorador de archivos de Windows son datos tabulares? Y, ¿esto siempre se presentará como una mesa? ¿Qué sucede si desea un estilo de vista diferente en 6 o 12 meses? ¿Por qué poner restricciones que tienen efectos a largo plazo en aras de ser obstinados frente a la práctica ampliamente aceptada?
HorusKol
12
Excepto que no son datos tabulares, en absoluto. No hay otra razón que no sea una decisión de diseño arbitraria de que este contenido se parece a una tabla. No son datos estructurados en columnas y filas, es una lista de contenido, presentada en una cuadrícula. - editar: lo que dijo HorusKol.
Eric King
3
Bueno, está bien, eso fue un poco estirado. :) Bueno, ¡me has dado algo en qué pensar! ¡Gracias por eso! Todavía no estoy 100% convencido, pero al menos es algo con lo que seguir. :)
Vilx-
11

En los viejos tiempos, el motor de renderizado de tablas " parecía " 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 columna 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, dándoles 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 cualquier código desde el 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.

Yo no
fuente
Offtopic sobre el DOCTYPE: pensé que, aunque había una diferencia teórica (y los validadores lo tomaron en serio), en la práctica los navegadores realmente no diferenciaban entre ellos. OK, tal vez hubo algunos cambios menores entre los sabores HTML / XHTML, pero la versión y la información de DTD al menos no se usaron. Es por eso que HTML5 abandonó todo de todos modos y fue justo <!DOCTYPE html>y es por eso que funciona incluso en navegadores antiguos como IE6. ¿Me he perdido algo?
Vilx-
2
@Vilx: un doctype pone un navegador en un modo determinado. Entre otras cosas, define el modelo de caja en uso. Para varios tipos de documentos, los navegadores no se alinearon porque el modelo de caja utilizado era diferente. Esta es la razón por la cual tantos desarrolladores se quejaron de que los navegadores mostraban las páginas de manera diferente y, en lugar de corregir el doctype, usaron hojas masivas de restablecimiento de CSS. Sin embargo, ha habido algunos doctypes en los que todos los navegadores usaron el mismo modelo de caja, pero esos nunca fueron los predeterminados, tenía que conocerlos.
NotMe
@vilx: html 5 no dejó caer todo. Más bien, se agregó un nuevo doctype. El punto es que la primera línea que aparece en la parte superior del documento html es crítica y si no comprende lo que hace y cómo reaccionan los diferentes navegadores, pasará demasiado tiempo descubriendo por qué su diseño está "roto" en un navegador en particular.
NotMe
Esperan, por lo que no son diferentes doctypes que hacen que el mismo documento hacen de manera diferente? ¿Cuáles? Eso sí, estoy hablando de diferentes doctypes, no doctype vs falta de doctype (también conocido como quirksmode).
Vilx-
@Vilx: es un poco más complicado, ya que algunos doctypes activan el modo caprichos (igual que no doctype) y otros doctypes (incluido el html5 doctype) activan el modo estándar, e incluso hay algunos doctypes que activan un tercer "casi estándar" "modo en algunos navegadores.
JacquesB
5

Si puedo obtener un pequeño "meta" aquí, esto me trae 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 manera 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.

Arrendajo
fuente
77
wrt hasta el último párrafo: has leído la especificación HTML5 para esos elementos, ¿no? w3.org/html/wg/drafts/html/master/semantics.html#the-p-element w3.org/html/wg/drafts/html/master/semantics.html#the-ul-element w3.org/ html / wg / drafts / html / master / semantics.html # the-ol-element - particularmente, si el orden es importante, entonces use el elemento ol (ya que esta es la parte estructural) - todavía puede presentarlo como una lista de viñetas usando CSS
HorusKol
55
y si mira las otras dos respuestas aquí, verá que ninguno de los dos dice simplemente "porque es la regla" - ambos presentan justificaciones muy claras para la regla y usan casos
HorusKol
1
Hmm, me parece que dije algo como: "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 para resolver y / o independientemente de qué otros problemas crea ". No niego que haya razonamientos razonables detrás de la regla. Simplemente no estoy de acuerdo con la conclusión. Seguramente puedo decir: "Tienes un buen punto allí, pero no estoy de acuerdo". Y seguramente no niegas que hay personas que no entienden los pros y los contras y dicen ...
Jay
1
... "porque es la regla". He tenido varias conversaciones con esas personas a lo largo de los años, sobre este tema en particular y sobre muchos otros. Las personas que se niegan incluso a discutir los pros y los contras de una regla, porque es la regla, el final de la discusión.
Jay
Ha surgido esta desafortunada noción de que el diseño HTML tiene sus raíces en alguna forma abstracta de ingeniería en lugar de arte. Como tal, en ese sentido, algunos han decidido que debe haber reglas absolutas análogas a la física, y que se debe obedecer la gravedad , o alguien que infringe esas reglas se aleja de la "fe más pura". La realidad es que ningún navegador ni metáfora de diseño es infalible. Camina con cautela alrededor de aquellos que insisten en lo contrario.
David W
5

Ya hay toneladas de excelentes respuestas aquí. Pero quería agregar que los tableelementos tienen limitaciones de representación que no existen para los divelementos. Intente crear 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 cuadrículas de 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 tableelemento, de lo contrario voy con divs porque puedo controlar mucho los resultados Mucho más fácilmente.

Crisfole
fuente
3

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

div { display: inline; }

Como notará, <div>puede reutilizarse para emular <table>y sus compañeros de viaje. En realidad, la mayoría de las etiquetas pueden. Teniendo en cuenta sus papeles especiales, dudo que puedas volver a asignar etiquetas útilmente macro como <html>, <head>, <body>, y <script>, aunque las 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 el "marcado semántico" , bla , bla , bla , o creer con los Pythonistas que "debería haber una, y preferiblemente solo una, forma obvia de hacerlo". Sin embargo, Tim Toady es un tipo inteligente y curioso. Con una mano libre, los explorará a todos. Eso incluye usar la flexibilidad disponible para hacer 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, el 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? Debido a que los elementos de listas HTML ( <ul>, <ol>y <li>) fueron fácilmente reutilizados y algunos usos reclasificadas como contenedores de menú y las partes. <div>podría sustituir 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 personalizadas 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 trabajarlo 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, el "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 ser capaces de personalizar y reasignar que 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.

Jonathan Eunice
fuente
44
¿Cómo va esto cerca de responder la pregunta?
HorusKol
2
En mi opinión, discute la pregunta subyacente de por qué los diseñadores, desarrolladores y trabajadores de contenido eligen usar elementos genéricos ( <div>y <span>) en lugar de elementos específicos, especialmente diseñados (por ejemplo <table>). Es un poco más meta que solo esas etiquetas, pero habla directamente de los patrones y principios de uso.
Jonathan Eunice
@HorusKol De hecho, de todas las respuestas aquí, esta es más consistente y apoya tu respuesta. Yo diría que encajan bien.
Jonathan Eunice
1
No sé si iría tan lejos como para contrastar div(como genérico) con table(como construido específicamente). Son tanto especialmente diseñada, con dos propósitos diferentes (tal vez todavía se superponen parcialmente). Esto, creo, es el corazón de la pregunta.
Eric King
@EricKing Es justo decir que divtiene un propósito. Sin embargo, divy spanno tienen la muy específica finalidad de que table, thead, tdetc hacer. Nadie se asustará si usa divelementos misceláneos para barras laterales, comillas tipográficas, agrupaciones de secciones, etc., también en casi cualquier parte del documento. Intente hacer eso con un no cerrado thead, tdo li. En lugar de "construido a propósito", quizás "específico a propósito" o "con un rol específico".
Jonathan Eunice
0

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 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.

Robert Munn
fuente