Are CSS Tables Better Than HTML Tables?

Mention css and tables in the same sentence and controversy is sure to follow. Web designers like myself have been telling you not to use html tables for layouts and now here we have a way to create tables with css alone.
What’s the difference between html tables and css tables? Should we use css tables? If so how?

Once again I want to thank Pedro for emailing me the idea to talk about css tables. I hope I cover what you’re interested in knowing.

Let’s get to the how of css tables first and then tackle the question of whether or not you’d want to use them in practice.

How to Create CSS Tables

The css table model is based on the html4 table model and has pretty good browser support. In both table models the table structure parallels the visual display of the table itself.

Rows are primary. The row is specified explicitly and columns are derived from how the rows and cells are set up.

I’m sure you’ve worked with html tables before and if you have you shouldn’t have any problem creating css tables.

Each html table element has an equivalent css display value. The only real difference is that there’s no distinction between td and th with the css variety.

Below are the html table elements and their corresponding css display value.

Table Layout Algorithm

fixed — The width of the layout is not determined by its content, but rather by the widths set on the table, cells, borders, and/or cell spacing

auto — The width of table is set by width of columns and borders

The important thing to consider is that a fixed table-layout is a one-pass calculation and very quick. On the other hand auto requires the same multiple passes of html tables. It’s also the default value.

If you explicitly set a width on the table then the fixed table layout algorithm will be used.

By default the cell height will be the minimum necessary to display the contents of the cell, but you can also explicitly set heights. All cells in a row will be the height of the cell with the maximum minimum necessary height.

The vertical-align property of each table cell determines the cell’s alignment within the row

baseline

top

bottom

middle

sub, super, text-top, text-bottom, <length>, <percentage>

The last group of values do not apply to cells, but the text within the cells. The cell is aligned at the baseline instead.

CSS Table Borders

There are 3 interesting properties for table borders

border-collapse — values can be collapse, separate, or inherit

border-spacing — values can be <length> (horizontal), <length> (vertical), or inherit. border-spacing is the distance between cell borders.

empty-cells — values can be show, hide, or inherit. If cells are empty or set to visibility: hidden content doesn’t show by default. Setting empty-cells: show on the table will cause backgrounds and borders to display for the empty cell.

Should You Use CSS Tables?

Are css tables better than html tables? If so what advantages do they have and if not why should we use them at all? Good questions that I don’t have great answers for.

I can say I’ve never used a css table in practice and have no intention of using them any time soon. If a page calls for tabular content it strikes me than an html table is called for and I think we have and will have better techniques for site layout than css tables.

I took a look at an older post I wrote on css vs tables to remind myself of the cons for using html tables for layout over a combination of divs and css.

Extra code — html tables require more structural code than divs, but css tables use just as much. If anything css tables use more since ids and classes will likely be added. If html tables use too much code then css tables do too.

Rigid structure — html tables are source dependent. The order you structure the cells is the same order in which they’ll display. The same is essentially true of css tables as well.

Browser rendering — browsers require multiple passes at the structure of html tables. They should only require one pass to display a css table if the table-layout is set to fixed. They’ll require the same multiple passes if set to auto.

Considering the above css tables aren’t offering enough benefit over html tables to use them for layout.

We could reach and suggest that since the css can be easily changed a css table is less rigid than an html table, but in practice I think they’re going to be just as rigid.

Overall it’s hard for me to see much improvement in css tables over html tables, some perhaps, but not enough to justify to myself using them.

I think some of the other css layout modules on the horizon will be better and even our current practice of using floats and positioning for layout are still a better option.

At the same time I can’t say I’ve worked much with css tables. This post is the most time I’ve spend with them since they’ve been introduced and I’m open to someone else’s reasons for why we should use them.

There are some nice features of css tables like the ability to collapse one or more columns through the visibility: collapse property and they can be used as solutions to some specific problems.

However they don’t provide enough advantage for me over html tables when it comes to layout. Their advantages seem minor and a bit of a reach. Ultimately I think we have better layout solutions than both html and css tables.

Again though I’m open to being convinced otherwise.

Have you used css tables in practice? If so how? Have you used them for site layout? To present tabular data? To solve a specific problem?

I am currently coding a css table thatwill be part of a joomla template and I believe that the module placement will be easier and function better than with an html table. Your tutorial has been a great help.

Hi Steven,
did you think out about table which has group rows (like nested list) and width of columns is the same in every level. I can’t make it either with classic table or css table. If you know such solution, could you write me on email or here to disscusion?

Not so much in that context. One use I’ve found for css tables is they help remove the extra space when using inline-blocks. It’s something of a hack to set the parent of inline-blocks as a css table, but it does help with the space.

I’m not 100% sure that I’m following the issue you’re having. Do you have an example you can link to or email me?

I think we shouldn’t compare HTML tables and CSS tables. The purpose of CSS is to separate the content from presentation. CSS Tables are valid technique as floats or positioning. Actually CSS Tables are much more flexible than floats. I built CSS Framework with only 2 lines of code http://www.vcarrer.com/2010/10/two-lines-css-framework.html that can accept multiple fluid columns(auto resize). Here is a demo http://www.allapis.com/Two-Lines-CSS-Framework/demo1.html , making this with floats is almost impossible. I think in the future when IE6/7 finally die, we should give this technique a chance.

Thank you, your demo is really helpful for something I am actually designing right now that needs this sort of thing. I came to this blog looking for the answer and it seems I found it by reading the comments

Good point. In tablular data the fact that it is tabular is part of the content not of the presentation. A table consist of a cell and a row concept. In order to define this in content it would be logical to do it there and leave the how-the-cell-or-row-should-be-rendered to the style sheet. Something that can be done awesomly with and (and ) tags. The fact that tabular data is just that is not a attribute of design but of content.

Don I plan on looking the the grid module in an upcoming post. Not sure when I’ll publish it, but it’s something I’m working on. There are definitely some exciting things coming in layouts, though we’ll likely still be using floats in the foreseeable future.

I’ve used the display:table properties before for something that had 2 equal sized columns with backgrounds. But had to put in a polyfill using the 5-6 nested & floated divs solution if the browser didn’t support display:table, which is still a problem since IE7 is still quite common.

It is very important that tabular data should be understood as tabular data. The relationships between those data are what make them suitable for presentation in a table.

While AT and accessibility-layer support for CSS tables is currently so limited and unreliable, I believe that no-one should be presenting tabular data without using table mark-up. Otherwise, the relationships that are vital to understanding the content are lost.

On the other hand, presenting non-tabular content with CSS table properties will, in time, be just as misleading and problematic as misusing table mark-up in the same way.

It would be more interesting if I didn’t get the vibe that it’s sort of equating two things that shouldn’t be equated.

The two aren’t mutually exclusive. One’s style/skin, one’s semantics.

CSS table display types are a specification for the apparent visual functionality of HTML tables. HTML tables predated the specification, yes. But so did block and inline, they just weren’t frequently called that.

If you need a table you would absolutely NOT use what you’re calling “CSS tables” (which I take to mean “using CSS display types to create the visual appearance of a table without using table, thead, tbody, tfoot, caption, tr, th, or td”). You WOULD use an “HTML table” and you would use CSS to style it.

You can also leverage the CSS table layout model (not “CSS tables”…is this really a thing?) to achieve certain visual effects on non-tabular data.

They’re different things, but like I said above I think the comparison is fair. Both are creating a similar html structure and in the case of site layout are going to be used in the same way.

I agree that you should use an html table for tabular data and said so in the post. Some have suggested that css tables (and yes it’s probably more correct to say the css table layout model, though it takes more time to type ) could overcome the limitations of html tables for layout. I don’t think they overcome those limitations, which is mainly what I was comparing here.

The purpose of “html” tables is to display tabular data. Using other elements and css to replicate table elements is less than ideal. We can use multiple tags and css to replicate the base style of an h1 except have it within an em tag, doesn’t mean that we should.

The question should be – which version is more accessible? And the table structured content is definitely better structured and accessible, then a css based table. Think about screenreader and you will never think about css tables! Perhaps ;o)

That’s exactly the biggest problem for me. See my earlier comment from the 14th. This situation may change, but it always takes a long time for that to happen to the point at which method X becomes real-world usable.

If it’s not tabular data why would it matter if search engines can’t interpret it as tabular data. I don’t think search engines care what technique we use to layout a site. They don’t care if our columns are created through floats or through positioning for example.

I agree with Burhan. Any SEO board or SEO will tell you that Google frowns upon table layout on websites. So if CSS tables are any different is something I am still trying to figure out. If trying to optimize a site properly, I would avoid any table properties just to be safe.

There’s never been any indication that Google frowns upon table-based layouts when it comes to ranking. There are other reasons not to use html tables for layout, but search engines have never really been one.

I agree I worked with people who have done seo for years professionally ranking sites with CSS tables for difficult keywords it has nothing to do with tables for seo the algorithms don’t work like that

I don’t use css tables per se, but I have used (recently) a container element with ‘display: table’ and set its children to ‘display:table-cell’ to have the elements arrange horizontally w/o having to use floats or absolute positioning.

Of course, this was for a device-specific use (iPad), so I didn’t have to worry about cross-browser issues.

Otherwise, tabular data should be placed in html tables, but the different ‘display’ options can offer interesting solutions to layout probs.

It seems people are confused about the difference between CSS tables and HTML tables.

CSS tables, for lack of a better term, were never designed to be used for displaying tabular data. They were created to provide easy to implement site layout control only. If you need to display tabular data then use a table, an HTML table. To suggest otherwise, or even compare the two in this manner is absurd.

Therefore the only reason to compare HTML tables to CSS tables would be to compare their suitability for layout control. Again, this is absurd since using HTML tables for layout isn’t what they were designed for.

So what have we learnt? CSS tables are like a can opener and HTML tables are like a knife. They are different things for different purposes. Not interchangeable depending on your mood.

Floats are also a pain. Yes they work, or can be convinced to work here and there. All my sites heavily rely on them. They do cause problems with other elements however and their implementation for even a typical 3 column layout is not a trivial task. The layout complexity soon increases as you have to work around other problems that arise. Floats for site layout become very counter intuitive very quickly. Floats were not designed for site layout to the extent they are been relied upon today. CSS tables are designed for this purpose however.

So why bother with CSS tables? Because they provide an “easy” to understand, logical, predictable tabular layout for a page while remaining semantically innocuous. Perhaps there is no benefit over HTML tables in terms of effort but HTML tables when used for layout are semantically incorrect. That is enough of a reason right there to use CSS tables instead of HTML tables.

Naturally this brings us to the following quote from the above article:

“Considering the above css tables aren’t offering enough benefit over html tables to use them for layout.”

Again I’m confused with this comment. HTML tables shouldn’t be used for layout. Never! This renders the above quote pointless and irrelevant. Two paragraphs further down the article answers the question as to why you’d use CSS tables. To paraphrase, “Because CSS tables are semantically correct”. In other words, you’d use CSS tables because they are the correct tool for the job. HTML tables are not! That is the only reason you need. Using HTML tables for layout is unacceptable and wrong.

I’m also not convinced the argument that CSS tables are rigid is particularly valid. What is the alternative? Floats often have to be placed in a specific order or the combination of layout constraints will be broken. If you want pure control over a page then you’ll need to use absolute positioning which has its own drawbacks, especially with fluid sites and other design requirements.

So why use CSS tables? Because using HTML tables is wrong. Using the other methods requires complex solutions, hacks, tricks and at the end of it the code is being coerced to behave in ways it wasn’t designed for. Therefore you could also argue much of the alternative techniques are also wrong. CSS tables to the rescue. Great! I Can’t wait for the appropriate support of it.

Until a better alternative becomes available and realistically viable, CSS tables are the nearest viable solution to the fundamental layout problems that have plagued designers since the beginning of it all. They are a solution, not a hack and not a workaround, designed specifically for the task.

I’m sure there are at least a few good reasons why you’d use CSS tables over HTML tables. I’m not saying they are perfect either. They are however a great step forward. Once CSS tables are sufficiently supported that is.

Did you catch the first couple of paragraphs of this post? I agree that html tables shouldn’t be used for layout and said as much. 80% of this post is simply walking through how to use css tables. Nowhere do I advocate html tables for layout or suggest that css tables and html tables are the same thing.

Still it’s natural that some people will want to compare the two based on the word table. And like it or not there are people who still think it appropriate to use html tables for layout. I’m not one of those people, but they do exist.

Also keep in mind that this is an intro post to the topic of css tables and until someone has an understanding at the intro level they aren’t going to be able to determine if css and html tables are the same or different or how they might differ.

After looking through the specs for css tables and playing around with them I don’t think they offer a good solution for site layout. Sure floats can be a pain at times, but I still think they’re a better solution. There are better solutions that floats coming, but css tables aren’t one of them.

To show why I simply referred to an older post where I point out why I think html tables are bad for layout. I think some of the same arguments apply here. In the older post I’m saying A, B, and C are reasons why html tables shouldn’t be used for layouts. Here I’m looking at css tables in terms of A, B, and C and saying if css tables also have those same issues then they aren’t a good solution to layout for the same reason html tables aren’t good.

The point isn’t to say css tables and html tables are the same thing. It was simply to use the the same arguments against one for the other. Maybe I didn’t do the best job getting that across and if so my bad.

I understand that people who’ve worked with both will see they aren’t the same and aren’t meant to be used for the same thing, but keep in mind that not everyone has worked with both.

counter-example (@Burhan): One can easily use CSS to render HTML table elements so that they won’t look like a table anymore, no matter if they contain tabular data or sth else.

In fact, any smart SE *must* care a lot about CSS/HTML based display attributes! Just consider meaningless or even fake (SEO-only) contents such as HTML comments, text with zero font-size, font-color transparent or font=background color, or page-filling keyword lists within an off-screen or zero-size h2/table/td/object.

I see no reason not to use CSS tables. If they help to increase readability or to avoid that a floating layout breaks into pieces, they are cool. Otherwise they suck. The same is true for display:float etc, so what!?

Finally, the CSS table styles are absolutely necessary for more general markup languages which do not define any proprietary table/cell element.

Interesting read. Very surprised on the amount of content regarding this topic. Only after actively searching google for 20 minutes was I able to find a good discussion. Are people afraid of mentioning the term “table” in regards to layout?

After reading the article and a few comment chains, I was able to pick up a few perspectives I had not considered, but in the end my stance remained the same. Using the “css table layout model”, or “css tables”, is necessary for building the flexible, responsive web experiences we are required to develop. Like anything, it should not be abused. With IE7 pretty much out of the race, we are left with IE8 and IE9 to deal with, which means we won’t be using the new flexbox model in production for a good chunk of time. Using css tables I can achieve the following very quickly:

– Sticky variable height footer
– Variable width margins w/ multi line vertical centering (*great for flexible menus)
– Custom alignments. In the new world of responsive design we are no longer looking at how many pixels from the top, the left. We are looking to how the item is positioned relative to its counterparts. Using display table cell has provided me with a new tool to use when floats, etc, seem unreasonable.

The “css table layout model” is a necessary evil in my eyes. When a better solution becomes available to use in production, I will gladly leave the table layout model. Until then I will use it to solve some of the most complicated alignments in my layout.

Thanks Jarid. I think you don’t see tables mentioned in regards to layout much anymore is because the industry has mostly moved beyond using them. Posts about tables and layouts are going to be older and as a result, probably don’t rank as well in search engines. I’m not sure people are afraid to talk about it as much as there’s not a lot left to say.

I don’t know that css tables are necessary for responsive design. Where flexibility is concerned it’s more about making sure to use relative measurements instead of absolute measurements. If anything tables could be harder to work with, because their structure is is less adaptive in general.

If you create a table with 4 columns, it’s not so easy to change that so it only has 2 columns when the screen can’t accommodate all 4. I think the way forward is to be more modular in our structure. Instead of tying one block of elements to another by placing them inside the same container, we’ll be better off removing the containers so the blocks inside have more options for repositioning.

I’m wondering if you neglected to read the full response I wrote, or perhaps I wasn’t completely clear. I am not using css tables to hold my layout together (columns). I am however using the css table layout model, when best suited, for unique styling circumstances that require vertical alignments. I also touched on the variable height sticky footer, which utilizes the table layout model, and is the best solution I have found to this date (ie8, ie7 graceful fallback).

I have been taught and am a firm believer that you should use the best tool for the job, and at times, that tool may be css tables. I was very surprised after reading your response. I can’t help but think it is a very narrow minded opinion.

I think I may have misread your response. I was thinking you were using tables for the full layout on some occasions. My bad.

I’m guessing what you’re doing could still be done with using css tables though. To me when I hear table (html or css) I think tabular data and if the information I want to display is something else then I look for something other than table code to display it.

I’m not sure why you think I’m being narrow minded. You said you thought css tables were a necessary evil, but myself and many others use other methods, so I don’t see how they’d be necessary.

I do agree that you should use the best tools and css tables can be one of those tools. I just haven’t found them to be best. I’m not knocking you using them if they work for you though.

Thanks for your article and opinions on CSS tables.
I found this page while searching for an explanation of why anybody would use CSS that REQUIRES a specific html layout. It seems like css tables are just a way to ensure that all html tags can be described with css, rather than something useful or meaningful.
Personally, once in a very long time, I still find tables to be the best way to accomplish certain layouts. They’re awful, but I use them because css doesn’t offer any alternative. I find myself in a place where I want to use normal flow to dictate the size of containers, but I want both the row and column to always line up. Seems like a simple case, but suddenly I need three times the markup (whether using html or css tables). Also the vertical-align thing, of course, though there are work-arounds. We really just need a ‘vertical-align-contents’ property, instead of completely changing the behavior of vertical-align based on display. Anyway, I’ll quit ranting for now.

Thanks for this study.
I always used html tables but, because some lacks, I dreamed about using Css tables with DIVs. You did it!
The missing features, important for me, are
– not easy to do scrolling with fixed header row,
– to have editable cells, we must insert Input field or…editable DIV!
A simple solution is there:http://www.cssbakery.com/2010/12/css-scrolling-tables-with-fixed.html
But it is a mix of Html table and Div or Span in each cell.
I looked at a Css table with just Divs and got this working, except not uniform Cell height ; a fix it to use either overflow:hidden (or overflow:auto plus fixed height) for each cell
Here is part of code:

The trick is to set absolute position to header Div, and either add a dummy row in first position or set top property of header a negative value equal to its height (with help of Javascript, I didn’t find a css solution.
If we don’t use float:left for each cell, this solves the height problem of Cells but in some browsers, the cells of header row have not the same width of ones other rows! It seems they are not involved in table-cell width calculation…
No solution yet for horizontal scrolling!
Thanks

“I never find a time where I can’t create a layout with css, even getting rows and columns to line up.”
May be you can do alignment equally well, but more importantly as fast using CSS or tables.
But does it matter to you that 90% of the world’s developers can use HTML/CSS tables to do it in 1/10th max time compared to floats/non-table CSS?
Or has “time-to-market” / “on-time” criteria sunk with the dot-com bust for you and all others who think that fiddling (and it is) with CSS properties to adjust a few pixels misalignment more important? Certainly keeps you employed!!

I think using css floats is faster and more maintainable than using html tables. I think you might also want to check the source code behind more sites because 90% of developers are not using tables. You also don’t need to fiddle around adjusting px.

I tend to use a HTML table when trying to get a columned layout as it tends to be easier to get full height columns and automatic widths (I know I shouldn’t really use tables for layout). However, I am currently working on a site where I need the cells of the table to break down onto the next line if there isn’t enough room.

I was just going to settle for a JavaScript solution but as the site needs to work on mobile browsers (scale down to one column) and also should be functional if the user doesn’t have JavaScript enabled, it is not optimal. I think by combining the use of the CSS table and media queries, this shouldn’t be a problem.

Glad I could help James. Are you sure you need to use css tables for your layout though? I do think they make sense to use under certain circumstances, but usually there are better ways to set up the overall layout.

In the end if css tables work for what you’re trying to do, it’s fine to use them, but I’d probably consider other ways to set up the layout first. For example this site scales down to a single column, but uses floats/

You claim to be able to do everything without tables. I have a specific problem and have not been able to find any solutions that don’t involve tables or fixed width elements.

The scenario is the classic set of label/field pairs with fields to the right of the labels. I want the field lefts to line up. The labels can have variable widths.

On a side note, I currently have this implemented as a table. Failing you knowing a better way, would you agree that CSS tables would be more suitable for this since it does not imply any tabular structure to the markup.

Off the top of my head you could wrap all the labels in one container and all the fields in another. Float both containers to the left or do whatever works to get them side by side. Then you can left align all the fields in the container on the right.

Wouldn’t that work? The labels and fields shouldn’t need to be adjacent to each other in the html for everything to work.

Another option (again off the top of my head) if you do want the labels and fields adjacent in the html would be to wrap each field in it’s own container. Float the container to the right and then left align the field inside it. If you give each of the containers the same width, their left edge should line up.

Don’t hold me to those working since I haven’t actually tried them, but I think either should work or could be made to work with a bit of tweaking.

This piece of comment ” or do whatever works to get them side by side.” is the key difference to messing with floats for hours, days maybe weeks and ending up with a hack, “px” filled rigid page that displays well ONLY on the developers screen, versus using a table/rows/columns and getting the job done in a few minutes with a fluid page that works 99% well on most modern browsers and devices.

Except you don’t need to mess with floats for hours, days, or weeks. One person is having trouble doing something and I offer to help without actually seeing any code and you take that to mean everyone has to spend a long time getting floats to work on every problem.

The majority of sites today are based on a float drive layout. Have you not been paying attention? Guess what? In a couple of years the industry is going to move on to using flexbox and other layout modules that are on the way. I assume you’ll still be arguing for tables then too.

I’m VERY glad I SKIPPED the VERY LONG 1st part, and jumped right to the SHOULD YOU USE … part. I saved much reading time !!! You should seriously consider changing the ORDER to save other people time too. OTHERWISE, it is good stuff.

Sorry you feel annoyed, but I don’t plan on changing the order of the section. The should you use part is just my opinion. It’s not some kind of commandment saying you can’t use css tables. If you read through the comments here, you’ll see some people happily use them and I do myself at times.

This isn’t like saying there’s no browser support so you can’t use them. At the time I wrote this my opinion was css tables didn’t offer enough advantages over html tables to use them for site layout.

Again sorry you felt annoyed, but I don’t think there’s a need to change the order of the sections.

So, in the end, there’s no difference using CSS or HTML tables? The rendering time is the same? Is that correct? I’m asking because I’m using CSS tables to produce fluid layouts and I wanna know if it is good or not for rendering time and even SEO techniques. Thanks a lot buddy!

I wouldn’t say there’s no difference. I’m not sure what the rendering performance is of either kind of table. I would think css tables render quicker, but truthfully unless you’re nesting a lot of html tables, I don’t think rendering time is that much of an issue.

Don’t take my word for the above though. I can’t say I really know the performance differences. It’s not something I’ve ever tested

As far as seo is concerned there shouldn’t be a difference, at least nothing significant enough to matter.

Personally I would use css tables to layout an entire site though. I think they can work well for part of the layout, but I think much of the reasons why we no longer use html tables to layout a site also apply to css tables.

Nice article about tables! To be honest, in most part of situations we should use css tables instead. But, if you need a table “thead” fixed with a lot of items with scroll-y, You’ll have a big headache.

If you have to put a css-table inside a limited div, with scroll, fixed “thead” will not work.

Thanks Lucas. I don’t end up using a lot of tables. When I do I still typically use an html table, though I have no objections to css tables. Why do you think css tables are the better choice other than when you need the fixed header?

There are two arguments for CSS tables that haven’t been made (or I missed them):

1.
You can enclose (CSS-) table rows in their own form, which is helpful if you want to make a CRUD-like table with editable rows.
If you have one form per row, only the input in the selected row will be submitted; with HTML tables you can only enclose the entire table in a form and you’ll then have to figure out on the server side what row has been edited (not to mention an unnecessary large POST if you have a large table).

2.
You can create a responsive layout without needing Javascript and e.g. resize or hide columns depending on the device size.
Or you can split rows: for example, for very narrow devices you might want to switch the table to a single column layout simply by removing or replacing the “display: table*” style without generating different HTML for that case.

Thanks Rick. I definitely did not mention either of your points. I completely agree about wrapping table rows. I hadn’t thought about that when writing the post.

I was going to disagree some on your second point because you can design a responsive site without Javascript or css tables, but I understand what you’re saying. Again it’s something I hadn’t considered when I wrote the article. Such an easy thing to change the display at different breakpoints.

I have used both CSS tables and HTML tables. It largely depends on what I need to do. In one case, I had a header menu that I wanted to use vertical align: bottom on each menu item, so I used a CSS table. Normally I will only use an HTML table for non-responsive design websites. CSS tables allows me some extra flexibility with styling, and also for potential future changes to a site.