CSS display:table - Pros and Cons for layouts

With all the questions that keep coming up about using tables for layout I thought a thread on the pros and cons of doing so would be useful. I’ll start with the ones I can think of and others can add theirs to help people work out whether they should use tables for part of their page.

Let’s assume that the HTML uses semantically correct tags to mark up the content and that it will stay that way regardless of what CSS we use to define how we want it to look.


  1. It is the easiest way to the same height.
  2. It avoids using float or position:absolute for purposes for which they were not intended.
  3. It provides a simple way for beginners to produce side by side layouts in CSS without polluting their HTML with non-semantic tags.


  1. It doesn’t work in IE7 and earlier and so you either need to define a different layout for those browsers or mess around with floats or position:absolutes to produce CSS for those browsers which works equally well in other browsers anyway.
  2. To create a colspan or rowspan effect requires nesting one table inside another.
  3. It encourages people to build grid layouts rather than taking a more flexible approach.

tnx for this…


I think you need to re-phrase (or clarify) the question as I’m a little confused:)

Are you talking about html tables or using the display:table CSS property because your Number 1) comment under “Cons” doesn’t make much sense otherwise because tables work fine in IE7 but of course display:table doesn’t :slight_smile:

It’s not immediately clear what the topic is :wink:

Stephen is talking about display:table and related box types, i.e., ‘modern’ layout tables.

Although I understand your intent, Stephen, I think there’s a risk that unsuspecting readers will get quite the wrong idea. :slight_smile:

Personally I thought he is talking about <table>'s because he said using “tables for layout” and that indicates not using display:table.

Does this mean we’ve moved on from the semantics of HTML to the semantics of CSS?

Or perhaps from the presentational aspects of HTML to the semantic aspects of CSS? Out of the frying pan and into the fire. :smiley:

I’d have thought that from the fact that I posted this in the CSS forum and from the pros and cons that I listed (as well as the mention of semantic HTML) would make it obvious which sort of tables I meant. Using <table> isn’t semantic and isn’t CSS. The pros and cons are supposed to be regarding the setting up of grid layouts using display:table.

There’s no need for a thread on pros and cons of using <table> for layout because that is just completely wrong in the first place.

I gess it is basically intended to be a discussion of CSS semantics since it can be argued that using anything other than display:table for setting up a grid type layout is using the wrong CSS for the job even if it does work in all browsers

Also this is the one area of discussing table layouts where there are legitimate arguments both ways (unlike <table> where there are no remaining legitimate arguments for using it for layout).

I knew what you meant but I also knew that loads of others wouldn’t hence the reason why I raised the question :slight_smile:

Now that you have clarified :slight_smile:

  1. It avoids using float or position:absolute for purposes for which they were not intended.

I disagree with the above statement as floats were always intended for layout as this test page from the w3c about ten years ago shows :slight_smile:

Absolute positioning can also layout pages but is limited in usefulness in certain situations.

I’ll agree that neither floats or absolute positionng are the complete solution and we could do with something better.

I think display:table is a step in the right direction but is just another tool to use when other tools are not good enough. However I don’t think there’s a need to do everything with display:table when there may be simpler alternatives. If you find at a certain point that you need 3 equal height containers then slip in the display:table when needed.

There are also reservations about how browsers will handle them and at present Firefox handles them badly unless you physically add the display:table-row as additional extra mark up. IE8 also seems a but shaky at the moment but hopefully it will be fully functional when finally released.

In essence my pros and cons wouldn’t be much different from the ones in the first post.

Equal Columns

Inconsistent handling by browsers.
No support in IE7 and under
Extra mark up required for Firefox
Rowspans and Colspans are not implemented by default
Grid type layout is too rigid

I don’t actually see CSS as having any semantic value because that’s the the purpose of the html. Whether an element is marked up as display:table or as float:left has no meaning other than how the element will be presented . It doesn’t infer anything else on the mark up as far as I’m concerned.:slight_smile:

Just to clarify - what I had meant to say was that floats were never intended to be used to create adjacent elements of equal height - which of course is something that they can’t actually do and you have to play around with a few other things so as to give them the appearance of having equal height whereas the purpose of display:table-cell is that adjacent cells will automatically have the same height.

I also agree with you about tables not being the solution to everything.The big danger once all browsers do support them is that people may start trying to use them do do the entire page layout and they’ll end up with rigid inflexible grid based designs and ignore the other 99%+ of page layouts that are possible.

Ok, yes I understand and agree with that :slight_smile:

I think we are basically saying the same things.

Display:table is another useful tool towards a full solution. It’s a shame that CSS didn’t encompass all the things that designers needed from the start. There are a lot of things implemented that no-one uses but basic layout techniques should have been the starting point.


  • Design maintenance later on

How - I’d expect it to be the exact opposite.

The CSS is simpler and therefore easier to maintain. If you need to change from display:table to something else in your CSS because the two or more elements no longer need to be the same height then it is easier to do if the equal height elements were coded using display:table in the first place than if they were coded using some other CSS that isn’t intended for setting adjacent elements to equal height.

Can you explain how using a specific element in the CSS instead of a whole bunch of CSS to simulate that same effect makes it easier rather than harder to maintain.

How is

.col {display:table-cell;height:200px;}

harder to maintain that the much larger amount of CSS necessary to simulate several columns that are all the same height if you don’t use CSS tables?

  1. To create a colspan or rowspan effect requires nesting one table inside another.

This one right here had me convinced for a moment that the subject was “tables for layout” instead of “display: table for layout”.

Could add to the Pros: vertical-alignment.

Setting display: table on everything-- who the heck does that? It makes things display like tables which, other than the height and vertical-align things, suck!

They accordion.

They wobble.

They act differently with widths.

They set off two nasty Firefox bugs.

In a very long page with a long column with a lot of display: table elements (with no further styling and no table-row or table-column stuff) Opera finally loses it and stops rendering (the page has to be kinda long for this and as it and FF are the only ones who have issues with this I expect them to be fixed… eventually).

99% of the time display: table does exactly what I DON’T want it to do-- makes the page elements act like tables. Floats and positioning and margins all do a much better job at making the page the way I want it-- with full Nazi-like control over any strange thing some user might throw at it.

Agreed with Paul re the sole equal-height advantage (but also adding vert-align), though I haven’t used display: table for this yet (in page columns). But using an image to fake it is, actually, a nasty, often inflexible hack that also requires another GET request-- an unneeded one if CSS had let us do things like vertical-align with auto vertical margins (with rendered heights not stated heights) or % heights based on rendered (not stated) parent heights.

I also want a parent selector and a pony for Christmas.

i initially thought it was about tables too, so the no ie7 confused me, thanks for clarifying this.

every con and pro i could think of was already said, so ill just say.

stupid ie7 and lower…

display table should be used to create a css based table?
not to create the “look” of a website?

Used to create a css-based table?

Only if you think your page looks great dressed up like Excel : )

Table tables, they are already actually display: table so they’re set.

display: table in regular css is good for the things listed above (making vertical-alignments and having equal-height side-by-side siblings), and for one other thing I can think of:
I redid a page that had been built all in tables, including a menu. The designer wanted to preserve the tabley-ness of that menu, while I knew it should be a menu not a table cause that’s what it was, a menu. But it needed to accordion.

So I used display: table here (white menu, stretchie with your browser) and for the first time had used HTML IE CC’s to get IE looking decent. I’m still normally preferring

  • html #element {blah;}
    *+html #element {blah;}
    in the single CSS sheet rather than every single HTML page, but this went into an Evil Templating System anyway, so it didn’t matter.

Well all sensible web page authors know to write semantic HTML where table tags are used to contain tabular data and for no other purpose.

There is still room for people to disagree as to whe it is appropriateto use the CSS table commands display:table, display:table-row and display:table-cell although from the look of all the posts so far everyone io far is in agreement on what it should be used for and what the advantages and disadvantages of using it are.

Perhaps we should also consider when it would be appropriate to start using them given that IE7 and earlier don’t support the commands.

Perhaps we should also consider when it would be appropriate to start using them given that IE7 and earlier don’t support the commands.

valid point.

edit: if we were to support the most common user, the answer would be… never.
even tho w3c says the amount of ie6 users is 20.0%, the percent is actually larger.

I doubt that much more than 20% of people visiting the W3C are still using IE6. The exact percentage depends on what your site is about. My own site has IE6 hovering around 20-21% at the moment and I’d expect the percentage for the W3C site to be a lot lower than that.

It isn’t necessary that we wait for IE6 and IE7 to completely disappear before starting to use things that those browsers don’t support. There is nothing that says that your page has to look the same in all browsers or we’d still be writing pages that display the same in Nexus (or World Wide Web as it was originally called) as well as in far more modern browsers such as Mosaic and Netscape 1 etc. The question on when to stop worrying about the site degrading to a more basic but still usable version in antiquated browsers such as IE7 needs to be made on a site by site basis. For some sites it may not even be necessary that the majority of visitors be using a browser that makes use of all the features built into the page.

I would agree to that.

For me, using cool css stuff which older browsers don’t support, is an opportunity to tell people how great it is to upgrade.