Tablas Css. Display: table y asociadas. Su oportunidad en el responsive design 18.1.13
Un vistazo a las "tablas Css" (propiedad display:table y asociadas). Sus diferencias con las tablas html y sus posibilidades en el responsive design.
Tablas Css. Display: table y asociadas. Su oportunidad en el responsive design
Sí. Es cierto. Hablar de tablas Css puede ser peligroso. Según quien, es poco menos que un tema tabú. Serán muchas las veces que oigas/leas que si necesitas presentar datos tabulados uses el elemento table. Y de utilizar tablas para crear el layout... ¡uf! Ni mencionarlo siquiera.
Sin embargo, existir existen. Y si existen lo mejor es intentar conocer sus particularidades y evaluar si se pueden usar o no. Y de usarlas, cuándo, cómo y para qué.
Así que vamos con un vistazo a las tablas Css, comparándolas con el elemento table de Html y algún ejemplo de uso.
Estructura de la tabla Css
Display table y asociados
El modelo de tabla Css se basa en el modelo de tabla de Html4, y la presentación y ordenamiento visual es la misma en ambos casos.
En Css las tablas se obtienen a través de la propiedad display y sus valores correspondientes para hacer de un elemento su equivalente en la tabla html. Estos son:
table { display: table /*inline-table*/ }
tr { display: table-row }
thead { display: table-header-group }
tbody { display: table-row-group }
tfoot { display: table-footer-group }
col { display: table-column }
colgroup { display: table-column-group }
td, th { display: table-cell }
caption { display: table-caption }
La única diferencia entre los valores Table | inline-table es que el segundo crea un tabla en línea (inline) con otros elementos y el primero crea un bloque (block).
Y caption puede colocarse antes o después de la tabla (arriba o abajo) también con css:
#caption {caption-side: top}
#caption {caption-side: bottom}
En cuanto al soporte por los navegadores, en 2013 no debería preocuparte en exceso y sólo en muy contadas ocasiones
Marcado de la tabla Css
A diferencia de lo que ocurre con las tablas Html, las "creadas" vía Css no necesitan declarar obligatoriamente la tabla, las filas y las celdas. Si a un elemento le defines sólo display: table se generan bloques de contención anónimos que suplen los intermedios y obviados.
El típico ejemplo es el usado, yo también, para centrar elementos de tamaño desconocido a priori, como las imágenes. El porqué en el siguiente apartado.
.centro {
display: table;
margin: 0 auto;
}
Tampoco es obligatorio, si no se necesita, declarar un elemento interpuesto como table-row entre el padre table y su descendiente table-cell (se generan las cajas anónimas oportunas).
Algorritmo en tablas: propiedad table-layout
La anchura de una tabla depende de qué método (algorritmo) se establezca mediante la propiedad table-layout. Admite, además del valor inherit dos más:
- fixed
- La anchura no la define su contenido, viene dada por declarada en la tabla, las celdas, bordes y/o espaciado entre celdas (cell spacing).
- auto
- Es el valor por defecto o inicial. La anchura de la tabla la marca la anchura de las columnas y los bordes.
La diferencia más notable entre un valor y otro, es que si usas auto corres el riesgo que la anchura de las celdas se modifique en función del contenido, obviando incluso la anchura declarada para las celdas. Lo que puede llevar a recalcular la anchura de las celdas y su reacomodo.
Y en algunos navegadores como FF, si olvidas declarar table-layout: fixed verás que no surte efecto declarar anchura en la celda. Anula la declaración en .layout
Esta es la explicación del porqué se centra la imagen anterior. El tamaño computado de la tabla creada no es el 100% del que tiene disponible aunque sea un elemento de bloque y fuerze un salto de línea. Su display≠block). Este comportamiento de permitir o no otros elementos en su línea lo controla el par de valores posibles table | inline-table.
Usar o no tablas Css
Diferencias y semejanzas entre unas tablas y otras
- Pese a que el marcado de la tabla Html sea más prolijo que el de las tablas Css, éste también lo es.
- Ambas estructuras son rígidas. Su orden de presentación depende de su orden de aparición en el html. Y el querer alterarlo requiere de sobreesfuerzo y declaraciones añadidas en el css. Por ejemplo para dejar el thead fijo al hacer scroll no siempre fácil o intuitivo.
- El renderizado de una tabla html le supone al navegador varias pasadas (reflow) en la mayoría de ocasiones. Con las Css no se requieren.
Cuándo y para qué usar una u otra tabla
Sin entrar en razones o argumentar los porqués, hoy en día debería estar más que claro que:
- Tablas HTML: Si necesitas presentar datos tabulados (en el más amplio sentido de la expresión) nunca deberías complicarte creando tablas Css.
- Tabla Css: si quieres aprovecharte de algunas de las propiedades/comportamiento de las tablas en algún elemento(s) usa display: table. Y nunca una tabla Html para crear el layout o tramoya de la página.
Algunos ejemplos de realizaciones que se vuelven sencillas al usar el valor table y asociados además de los centrados:
- Falsas columnas de igual altura
- Pie abajo o Sticky Footer
- Cuerpo al 100% de la ventana con encabezado y pie de página.
Display: table en el RWD. Mucha cancha y juego
Con el advenimiento del RWD, las @media-queries y su explosión, las "tablas Css" han visto cómo se recuperan o redescubren. El display:table ha pasado de ser ignorado por los problemas del navegador de siempre a ser tomado en cuenta para crear el layout, estructura o tramoya de las páginas.
Layouts con display: table
Son muchos los artículos y realizaciones RWD basados en el uso de las tablas Css. Posíblemente ya los conozcas. Si no fuese así, unos pocos enlaces para que te inicies:
- Un framework con dos líneas de Css
- display:table-cell y su oportunidad en el Responsive Design
- Un ejemplo
- Otro ejemplo
Alternativas, enlaces complementarios
Como todo esto de las tablas, ya sean Html o emulaciones vía Css con display:table son cosas con mucho tiempo a sus espaldas, no te sorprendo si te digo que hay propuestas más o menos viables a estas alturas para lograr un mayor control de la presentación de la información.
DY si quieres ampliar información sobre el tema de las tablas Css, algún enlace que puedes consultar
- Layouts Css. Pasado, presente y futuro
Y en él encontrarás información y enlaces a lo más nuevo de Css: - Table formatting
- Re-tabulate
![](https://www.pinterest.com/pin/create/button/?url=https://escss.blogspot.com/2013/01/tabla-css-rwd.html&media=https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjz4oBufkZBMduFVyqsdSb_bmpuP1OuoXoFAmpr9XCkuUJE6KpNIOrjTGSSy2GPBEn7aF6pugKTIryDpfleq0EijUWtMCfSj0_RMPlUqRsVkYh69k4H7bE24czswe5N9ZJuKnvTpj4JUVs/s1600/tabla-css.jpg&description=Un vistazo a las "tablas Css" (propiedad display:table y asociadas). Sus diferencias con las tablas html y sus posibilidades en el responsive design.){kind=link}
Kseso
the obCSServer ᛯ Ramajero Argonauta, Enredique Amanuense de CSS.#impoCSSible inside
Dicen que, en español, EsCss es el mejor blog de CSS. Posíblemente exageren.
@Kseso EsCss Kseso
También la propiedad display:table se usaba anteriormente para crear etiquetas HTML5 en versiones antiguas de IE. Para este caso, es mejor display:block.
ResponderEliminarLa polémica con las tablas existirá por largo tiempo al haberse usado mucho para maquetar webs. Pero si somos partidarios de la semántica, las tablas son necesarias para lo que fueron creadas, la presentación de datos tabulados.
Sos de usar tablas css kseso? Y el flex vendría a mejorar esto?
ResponderEliminarGeorge a estas alturas no deberías confundir el elemento html <table> con el valor 'table' de la propiedad Css 'display'.
EliminarY no. No se deben crear tablas en base a los valores Css del grupo 'table-'. Para eso están las tablas html y sus hijos (tbody, tr...) cuando se necesita presentar datos relacionados en una estructura tabular.
Otra cosa muy distinta es usar alguno de esos valores css para obtener un resultado dado.
¡Hace cuánto que no aparecía un buen debate de estos que ilusionan con terminar en una carnicería!
ResponderEliminarBien, como BlogSpot no nos da mucho espacio, vamos a ser concisos: ¿qué sentido tiene crear propiedades y valores CSS para aplicar formatos específicos de alguna etiqueta que de por sí ya tiene su comportamiento único?
Es el caso típico de '<table>', '<tbody>', '<tr>', '<td>', ... que sólo contienen o son contenidas unas por otras, igualan sus anchos o altos, respetan por omisión los tamaños de sus datos y los centran verticalmente como estilo de tabulación.
El sentido claro es hacer tablas en lenguajes que no tienen (o tenían, ahora creo que hay en todos) sus propias etiquetas de tabla. Y los navegadores empezaron a aceptarlos en cualquiera (¿para qué discriminar?).
El punto es: si está mal maquetar con tablas ¿pasa a estar bien si aplicamos sus estilos pero no sus etiquetas en lenguajes que sí las tienen?
Si fuese simplemente un formato, la discusión podría volverse bizantina. Pero en algún foro me explicaron que si yo pongo un 'display: table-cell' a una caja, el navegador completa los ancestros que le faltan para ser una verdadera celda de tabla. Tal y como hace si dejamos "suelta" una etiqueta '<td></td>'. que no puede existir sin el resto de la tabla a su alrededor.
Si nunca vamos a usar una celda y su tabla para (p.e.) centrar un texto, ¿con qué excusa creamos una celda (y su tabla) con CSS para hacer lo mismo? ¿podremos dormir tranquilos solamente porque no usamos la etiqueta prehecha para tal fin?
Por supuesto que si un lenguaje no tiene forma de presentar un texto como queremos, tragamos saliva y echamos mano de los recursos más viles disponibles; pero tenemos que aceptar que moralmente (ejem...) no hay diferencia entre una tabla CSS y una HTML.
Furoya una precisión pese a que tú no la necesites:
EliminarCss no crea (dejemos fuera los pseudoelementos y contadores).
Se "limita" a dar la apariencia -y dentro de ella el comportamiento del propio elemento del html respecto a sí mismo y su influencia sobre terceros- actuando sobre las propiedades y sus valores que por definición tiene el elemento o cambiándolas a otras que inicialmente no le corresponden. Vamos, lo que se conocen como aplicar estilos.
Aquí deberíamos traer a colación conceptos (tanto de html u otro lenguaje de marcado y de Css) como el modelo de formato, o las cajas (generadas, reemplazadas, anónimas...) sin olvidarnos de los bloques de contención en función de la naturaleza del elemento.
Y vuelvo a mi idea inicial: css no crea tablas (como entidad o elemento html) y pretender crear una estructura de "falsa tabla" en base a alterar las propiedades (display) de otros elementos (html) como div´s, li´s... es un error.
Pero no lo es en un momento dado hacer que un elemento (del html) adquiera un determinado comportamiento (vía declaraciones css) sin tener que crear una estructura completa de una tabla.
Y lo es porque esa apariencia es fruto de una cuestión estética que sí le es propia (en exclusiva) de Css.
Y pongo un ejemplo: Tengo una imagen y un texto descriptivo. Hay quien podrá crear tablas y habrá quien vea más apropiado etiquetarlo en el html como <figure> No entramos en cuál es más acertado.
Si opto por lo segundo ¿es errado que dentro de 2 años y tras cuatro cambios de look a la página declare a figure un display del grupo table, o inline-block o... para lograr la apariencia acorde con el diseño sin tener que ir al html y hacer las modificaciones allí cambiando, añadiendo o suprimiendo etiquetados sabiendo que en función de unas declaraciones u otras el agente de usuario tiene las herramientas (programación) para generar las cajas de contención anónimas si fuesen necesarias?
Perdón por la parrafada. Que más que argumentación es digresión.
OK. Me quedo con las ganas de ver sangre.
EliminarRecién estuve haciendo algunas pruebas (no muchas) y vi que los navegadores no "completan" las cajas que faltan.
O ya no lo hacen, o nunca lo hicieron y me engañaron como a una colegiala.
De hecho, ni rellenan hacia arriba una tag '<td>' suelta en medio del '<body>', simplemente la ignoran. Aunque todavía lo hacen si ponemos una celda directamente en '<table>' : al código le aparece magicamente '<tbody>' y '<tr>'.
De cualquier forma, darle a un elemento un estilo contranatura debería ser igual a cambiar el elemento. Porque las etiquetas justamente están para dar formatos, lo que confunde es que tengan el suyo por default, que está declarado en algún documento para aplicar CSS's que tiene el navegador. La etiqueta '<tr>' se comporta como una fila porque ya tiene asignado el estilo 'display:table-row', aunque no lo veamos escrito.
Entonces deberíamos empezar a buscar excusas por el lado de la semántica ... pero eso ya es otra historia.
Soy el menos indicado para tener que disculpar comentarios "largos" (que es un término muy relativo, según me consolaba mi ex); siempre es agradable leer tu prosa detallada, así que no te preocupes por eso.