

The Anti-hero of CSS Layout – “display:table” - p0larboy
http://colintoh.com/blog/display-table-anti-hero

======
DigitalSea
I remember the anti-html table movement fondly. While everyone knew tables
were bad for certain purposes, the hate movement brainwashed people into
thinking that using tables for anything (including tabular data) was bad. And
so, people started marking up tabular data using DIV's and CSS properties that
suffered from a myriad of compatibility issues, convincing themselves that
using floats was the right thing to do.

And we all bought into it, well most of us. Every time an overzealous
developer would spot the use of a table tag, hell would reign down upon Earth
lambasting the developer for using a table, even if it was being used for the
right purpose. "how dare you use a table you noob, use floats and DIV's, they
are so much better" \- for a good while people were hating on using the table
tag to the point where many were hating it, but could not really tell you why
other than, "because tables are bad"

In many ways the web has gone full circle, Flexbox is merely a more powerful
CSS version of tables, in-fact there are many similarities like the ability to
have columns of content of varied size sitting alongside one another. We added
in a new set of properties, changed the name and made them a little bit more
powerful.

I am one of those developers who have been quietly using display table for
non-tabular data for a while now to solve issues I have seen other developers
resort to additional markup and CSS hacks for, that either makes me a lazy
developer, an efficient developer or perhaps both.

Just recently I proved a remote developer wrong in regards to responsive
tables. He tried telling me and the business responsive tables cannot be done
without hacks. I implemented a solution using display table and DIV's. This is
for part of an app that only logged in users see, not search engines, so while
it was not a true proper use of the properties, it allowed me to implement a
true responsive solution for tables that will not degrade SEO or performance,
as it is not public.

Simply using media queries I was able to make my table DIV's collapse by
setting them to display block, adding in some type and colour adjustments, and
it just worked. No need to use before and after pseudo selectors to hack in
support for titles and stacked tables. No hair pulling when the business asked
me to support IE9 either.

As developers we all mostly want to do everything correctly and use the proper
tags and CSS properties in the appropriate way, but sometimes when you have a
deadline to meet and time is running out, you have to do what you have to do
to get things done.

~~~
alex_duf
To be honest the css property display:table isn't bad itself.

What we were reproaching to the <table> tag was to be wrong on the semantic
side.

If you use divs and style them with display:table I see absolutely nothing
wrong here, semantic is right, you infer the display behaviour through css.

~~~
cpncrunch
I think you're still falling into the religious trap here. Quite often I will
put inline css into the html page, or use a table tag. Normally I would never
admit this, as I would be hounded by css zealots. Often I do this when I'm
building a user interface in html/javascript, or for a single one-off layout
in a single page. Using external css in these cases would make it much more
difficult to understand/maintain.

I can understand the argument that "you should put styling into an external
css so you can just change it in one place rather than throughout the code".
However that argument doesn't apply to many use-cases.

~~~
rporrata
It comes to knowing your tools and craft.

Part of the madness was due to tools that auto generated attributes and
browser implementations when repainting/reflow occurred.

If the time, and potential knowledge was there, to better organize the
structure vs. the layout thing may have been different. We would probably
still be wrestling with browser issues.

I have worked in places where corporate sites had tables were littered with
font tags for each cell, littered with a half dozen iframes(!?!)

The use for tables in layout was easy, but the long term debt was never paid.

Granted this is less of a case now; wading through this was not fun.

~~~
cpncrunch
I definitely agree that in cases like that CSS is the much cleaner solution.

------
pcwalton
As someone who just implemented automatic table layout and is now intimately
familiar with the details of how it works, I'd like to suggest that the
problem with table-based layout is that _it 's excessively complex_ and
_largely undocumented and unspecified_. The results will differ between
browsers. Even the parts that have draft specs (which don't include, for
example, percentage heights) are much more complex than CSS blocks and
inlines: look at sections 4.1 through 4.4 of [1] for example.

[1]: [http://dbaron.org/css/intrinsic/](http://dbaron.org/css/intrinsic/)

~~~
mariusc23
Yes! I remember running into a really obscure bug that was caused by having an
element nested into a parent with display: table. I don't remember the
details, but I remember we were using the sticky footer technique described in
the article.

~~~
macNchz
I ran into a similar situation a while back while building an internal
dashboard that had a fairly complex nested-table layout. It wouldn't render
properly because of a bug in Firefox that had been open since 2000. I think
this was the one (it seems they've fixed it):
[https://bugzilla.mozilla.org/show_bug.cgi?id=63895](https://bugzilla.mozilla.org/show_bug.cgi?id=63895)

------
darrhiggs
_> > E8 and IE9 still make up 32% of the browser market share and that is a
lot to give up if I was to revert to the flex solution_

Yes, if you have an even worldwide visitor share. Can I Use[0] puts USA IE9
usage at 3.86% and IE8 at 7.28% (11.14% in total). If your user base is
different it would be wise to examine the data before discounting flex-box
based on worldwide stats.

If anyone has access to netmarketshare's USA[1] (used in the article) data, it
would be nice to see what it is.

EDIT: Also the article's stats[2] are for desktop only. It seems[2] that
mobile support is relatively high with Can I Use[0] stating that total USA
support = 86.46%.

[0] [http://caniuse.com/#search=flexbox](http://caniuse.com/#search=flexbox)
[1] [http://www.netmarketshare.com/browser-market-
share.aspx?qpri...](http://www.netmarketshare.com/browser-market-
share.aspx?qprid=2&qpcustomd=0&qpaf=-000%09101%09US%0D) [2]
[http://www.netmarketshare.com/browser-market-
share.aspx?qpri...](http://www.netmarketshare.com/browser-market-
share.aspx?qprid=2&qpcustomd=0)

~~~
IkmoIkmo
Agreed. A friend of mine suggested Flexbox for a web-app I was going to build
him. I glanced over the requirements and then asked him his traffic for <IE10,
and it was nearly 10%. (Website has 1m+ pageviews per month).

Not nearly as bad as 32%. And the number continues to drop.

~~~
btown
That said, if I told people on this site that I was offering a PaaS with only
_1 nine_ of reliability, I'd be laughed out of the park. And yet that's
exactly what I'd be saying if I were to advocate for ignoring <IE10.

~~~
IkmoIkmo
Sure, wasn't making any comment as to whether it's okay to ignore 10%, just
that 30% <IE10 is probably an overstatement.

As for whether it's okay to ignore... I guess it really depends. I actually
ended up writing a mobile web-app with Cordova, so obviously my target market
had no old IE in there. It might also be true that people on old IE are people
on old hardware, the type like my dad who never does any ecommerce at all, and
who may not be very lucrative visitors anyway.

Anyway I wonder if someone has some actual data on this, I can make up some
assumptions but I really don't have a clue. I do often read that China and
Russia are big IE markets (lots of windows XP and lots of websites that still
use activex stuff). It'd be interesting to see which markets are high on <IE10
and what the average value (e.g. ad or ecommerce) per user from different
browsers is.

Just checked on my own website, target audience are mostly 30-40 year old moms
in OECD countries. <5% IE, and virtually all IE10/11\. Just 5% IE9 and barely
anything below. (mostly West-European audience.)

------
yoklov
The biggest downside of display: table and friends is performance. Changing
any CSS or DOM properties will basically cause a full page (!) relayout and
repaint on a lot of browsers (especially mobile safari).

~~~
scotty79
Doesn't

    
    
      table-layout: fixed; 

help in Safari?

------
insin
It still takes me a few beats from thinking "I need a flexible grid layout
here" to remembering I can just use display:table, having spent so many years
discounting it off-hand because of Internet Explorer.

~~~
OniBait
What does IE have to do with this? Wasn't the whole anti-table movement a
response to the abuse of <table>, <tr>, <td> HTML tags for layout? I can't
think of any particular issue with Internet Explorer and display:table...

~~~
recursive
I think IE7 doesn't support display: table;

~~~
OniBait
Sure, but IE 7 predated Chrome by 2 years. I'm not sure how IE 7 which has a
global browser share roughly equivalent to Chrome 11, Firefox 3.6, Android 2.3
and Blackberry 7 has any relevance.

------
scotty79
If you use table for layout, remember to also use

    
    
      table-layout: fixed;

It will improve table behavior (content will no longer affect horizontal
layout of the table) and performance, saving repaints, reflows and whatnots.

~~~
cpncrunch
It really depends why you are using the table layout. Quite often the reason
for using tables is to lay out multiple items based on their content size, so
you want the default automatica layout.

------
rporrata
We have come full circle. Tables to CSS grid based frameworks back to Tables?

Tables are generally for structured content. They work and are perfect - Excel
for example. Hundreds of cells on a page? Rendering / performance would be a
nightmare.

CSS grids for layout - perfect and may cause some pain. Once you get it right
the performance is there.

With css/tags there can be abuse and we must think of how we plan to present
our content to the user who ultimately judges our work.

They do not care about the how it was implemented, they just want it now and
that it works consistently.

We need to ensure _we keep our sanity_ the balance is in between the two.

On another note, the use of colgroups should be mentioned with the above. It
does help with rendering performance. [http://www.w3.org/TR/html5/single-
page.html#the-colgroup-ele...](http://www.w3.org/TR/html5/single-
page.html#the-colgroup-element)

\- Enjoy!

------
vixen99
'I absolutely dissent HTML table-layout'. Don't you have to dissent from?

~~~
jrochkind1
yeah, that makes no sense grammatically, I think maybe OP meant "detest".

------
lacoolj
This is the most appropriately-named article, ever.

------
rado
My IE8+ grid is based on display: table and just works.
[http://natuive.net](http://natuive.net)

------
avighnay
>> the holy grail layout

gave me an instant smile, I remember 7 years back, wracking my brains out to
get it done for a project!

------
igvadaimon
What I didn't understand from this blog post is WHY display:table is really
bad.

~~~
pornel
It's not. That's the point.

"Tables for layout are bad" applies _only_ to use of <table> HTML markup for
layout. `display:table` achieves the same layout, but without presentational
markup and accessibility problems that html-tables-for-layout caused.

If it was called "display:stretchy-box", nobody would mind.

~~~
adamtj
Are html-tables bad even for their intended purpose of laying out tabular
data?

~~~
jerf
No.

And again, that's part of the point; "HTML table tags aren't good for layout"
semantically collapsed[1] to "tables aren't good for layout" collapsed to
"tables are bad" collapsed to "tables are EVIL". No, they aren't. The first
collapse is easily explained by the fact that for a long time HTML table tags
bidirectionally implied table layout (no way to have one without the other),
but now that CSS has broken that in both directions it's not a valid
simplification.

(Less well known aspect of CSS table support, I'm pretty sure it's possible to
take a series of HTML table elements and "undo" their tableness if you're
feeling feisty. But it's a weird way to do things.)

[1]: I seem to recall there's a term for what I'm reaching for. Much obliged
if someone can remind me.

~~~
pbhjpbhj
>"for a long time HTML table tags bidirectionally implied table layout" //

You're right, tables are fine for tabular data. But it was always thus.

Perhaps if you were a html noob and hung out listening to people pissed off
with table layouts you'd get confused and think all tables were bad (you
definitely want a graphical layout helper app though as keeping track of them
in code is a PITA).

It was

    
    
        table tage |- table layout V tabulated data
    

rather than just

    
    
        table tage |- table layout

~~~
nitrogen
I've worked on HTML that was written by someone who cargo culted all of the
tables into rows of Bootstrap columns, for tabular data. It happens.

------
amwelles
I've been using this in some of my latest projects. Works like a charm!

------
rpwverheij
interesting! will look this up again when I have one of the described
problems. In the meanwhile, I'll push an update to my brain: not everything
related to tables is old / bad!

------
blablabla123
Most of the examples can be achieved with flex layouts, Stylus+nib even
manages the browser prefixes for you. Just mentioning this, because last week
I considered a {HTML|CSS} table layout. As it turned out, solving the problem
with tables was more difficult than using other methods...

------
addict3d
You can achieve the same results with absolute positioning, which I prefer.

~~~
Sharlin
I'm pretty sure you can't, except in the trivial case of a table with
absolute-sized everything, or alternatively by reimplementing the table
algorithms in JS.

