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.
{code type=css}
table { display: 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 }
{/code}
Captions can be positioned above or below the table with the caption-side property
{code type=css}
#caption {caption-side: top}
#caption {caption-side: bottom}
{/code}
Looking at the above it shouldn’t be too hard to figure out how to set up a css table. Here’s a simple example.
{code type=html}
{/code}
{code type=css}
#table {display: table;}
.row {display: table-row;}
.cell {display: table-cell;}
{/code}
If you look only at the html above you can easily see the basic table structure except that I’ve used div and span with ids and classes instead of table, tr, and td.
A relatively small amount of css then presents the divs and spans as the familiar table, table row, and table cell.
In addition to the above the css table model includes an inline-table value, which defines a new table the same as display: table, but does so according to the inline formatting context.
Columns and Column-Groups
While tables cells are always descendants of table rows it makes sense to set some properties on columns. The css table model allows for the following on columns and column-groups
- border — The usual properties as long as border-collapse has been set to collapse on the table element
- background — The usual properties as long as both row and cell have background set to transparent
- width — Sets a max-width on the column
- visibility — If set to collapse (the only available value) then column cells don’t display, cells spanning into other columns are clipped, and width of the table is adjusted
CSS Table Stacking Context
Different table elements have different stacking contexts for the purpose of adding backgrounds to these different layers.
These layers can be seen in the image below.
- table – lowest layer
- column group
- columns
- row group
- rows
- cells – highest layer
The background of any layer will only be seen if all the layers above it have backgrounds set to transparent.
This can be a nice way to show an empty cell is truly empty by having its background be transparent and letting the background of the row, column, or table show through.
Table Layout Algorithm
The width of css tables can be calculated using one of two algorithms. This can be controlled through the table-layout property and the 2 values below.
- 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.
CSS tables do have the advantage of being more semantically correct as we can choose html elements that better describe our content.
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.
I have a hunch they’ll remain in use to solve some specific problems like vertically centering content or cleverly switching the display order of different elements in a responsive design.
They may also prove to be a good pattern for navigation. I don’t see them being a viable solution to the problem of layouts though.
Summary
CSS tables are pretty simple to understand and use. It’s mostly a matter of remembering the corresponding css display property values for the basic html table elements.
table becomes display: table. td becomes display: table-cell, etc.
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?
Download a free sample from my book, Design Fundamentals.
nice comparison between css tables and html table….in my career I have used both, but I like using CSS tables the most…thanks
Is there a reason you like css tables? I still don’t see myself using them in practice except for some limited use cases.
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.
Glad I could help. I’ve been rethinking css tables the last few weeks and finding more use cases for them.
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.
Thanks Vladimir. I think the comparison is fair because the structure of the html ends up being the same. The tag name and the semantics change, but the structure is still essentially the same.
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 🙂
Don’t forget to subscribe to Vlad’s blog. He has lots of really good information there. I highly recommend it.
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.
Exactly. It’s about the content. Use tables when he content calls for it, but not when it’s specifically for presentation of the entire layout.
Vladimir, awesome. Two lines of code for layout in any web measurement…that’s gotta make sites load faster, right?
Chris, check out the rest of Vladimir’s code at his site. He has plenty of great demos and downloads.
vertical-align property — hu-ah
I’ve always wondered about this link http://expression.microsoft.com/en-us/dd794430.aspx and now you’re addressing it in a similar vein. What about CSS3 Grids http://dev.w3.org/csswg/css3-grid-align/ ? It seems to me that the days of floating divs are numbered and a better layout approach should be developed.
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.
I’ve seen css tables used for equal sized columns too. Might be one of the use cases for them, though there are other ways to develop columns with equal heights.
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.
I agree about presenting tabular data and as you can tell I’m not sold on using css to create tables for layout either.
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.
Agreed. html tables for tabular data is the way I would go. I can see some limited use cases for css tables, but in general they won’t be commonly used.
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.
I agree. When it comes to presenting tabular data html tables should be used. I think most people look to the css counterpart for layout where the information doesn’t need to be structured as a table.
CSS table’s should not be used. If used, there is no way for a (search engine) robot to understand if it is a tabular data or not.
using CSS table are like using instead of .
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
No reason they should be concerned with tables. It’s the content that’s important. Unless the markup is helping them understand the content, they may as well just strip it away.
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.
imho
I think how you used display: table is more how they’ll be used in the future. I can see where css tables will help solve specific problems. I don’t see them being used much for overall layout though.
Yep, completely agree about using html tables for tabular data. Makes more semantic sense.
I’d be curious which methods you had in mind when you wrote “Ultimately I think we have better layout solutions than both html and css tables.”
Even though both have their faults I think using floats and positioning is a better method for site layout than tables (either html or css).
In the not too distant future we’ll have or may have layout modules like flexbox and templates and grids, which I think will improve things even more.
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.
Good point about readability. Ultimately it’s real people we’re designing and developing for.
I couldn’t really find compelling reasons to use css tables, but I also didn’t find anything suggesting you can’t or shouldn’t use them for anything either.
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 John. Yeah I wasn’t crazy about css tables after looking at them. I get what they’re trying to do, but I didn’t see any great advantage in choosing them over a table when needed.
I will disagree with you about using tables for layouts. I never find a time where I can’t create a layout with css, even getting rows and columns to line up.
I do agree about vertical-align. It would be nice to have something simple that always worked.
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:
#Container {
position: relative;
width: 517px;
margin: 50px;
border: 1px solid black;
}
#scrollDiv {
border:0px solid red;
height: 240px;
overflow: auto;
width: 100%;
}
#header {
background: lightgray;
border:0px solid green;
left: 0px; top: 0px;
position: absolute;
display: table-row;
}
.row{display:table-row;}
.cell {
/* if height not specified row cells will have different height*/
height:50px;
float:left;
overflow:auto;
width: 100px;
display: table-cell;
border-right: 1px solid #999;
border-top: 1px solid #999;
}
Name
Operator
Began operation
Tonnage
Status
Seabourne Sun
Seabourn Cruise Line
1988
Ended service in 2002, currently operating as Prinsendam
…
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
Thanks for the additional info. I took a look at the article you linked to and the demo it pointed to. The scrolling table looks great. Hopefully you’ll find a solution for horizontal scrolling.
“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.
Very interesting article. Can’t wait to try it out!
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.
CSS tables could certainly be made to work as well.
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.
Great! That was exactly what I was looking for!
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?
Just curious.
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.
Thanks again.
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.
Thanks Christy.
I haven’t used css tables much myself, though I do find them useful here and there. html tables I only use for tabular data. Both are definitely useful and have their place.
Hi steven,
Quality always speak and yes your will for long time. If you could have put try it kind of tool like other giants, then probably it would have helped a lot.
Anyways, thanks for sharing your information with us.
thanks for this post! I’ve recently been forced to convert my HTML table to a CSS table because we wanted to wrap an anchor link to each table row, which is semantically incorrect, but we wanted the entire row to be clickable (it’s a web app).
Thanks for the read
Glad to help Jan. Did wrapping each row with a link work the way you wanted it to?