By Kevin Yank

Rowspans & Colspans in CSS Tables

By Kevin Yank

“…we’ve implemented every property in CSS 2.1 and are closing in on our goal of complete support for the CSS 2.1 specification by the time we release.”

If you were to guess who recently made that statement you’d be forgiven for thinking it came from the Opera, Safari, or Firefox team; they have always seemed to be the most standards-conscious browser vendors. In fact, this quote comes from Doug Stamper of Microsoft, regarding Internet Explorer 8.

It seems the very thing web designers have been asking for—mature support for CSS2.1 across all major browsers—is actually about to happen. Back in Tech Times #185, I wrote about what this would mean to web designers in Table-Based Layout Is The Next Big Thing. In short, I said that CSS tables would become the best tool for CSS page layout.

There were mixed reactions to that article, particularly on the point of row and column spans. HTML tables let you create cells that span multiple rows or columns, but CSS tables don’t provide that same freedom.

Well, in my research for an as yet unannounced, potentially controversial book on CSS, I’ve figured out how to simulate row and column spans in CSS tables. Rather than make you wait for the book, I thought I’d show you this useful technique right away!


Nothing Up My Sleeve…

If you’ve had experience building layouts using HTML tables, you’ll be familiar with the use of the colspan and rowspan attributes of the td element. These attributes offer complex possibilities to a simple table, enabling cells to span columns and rows.

CSS tables lack any concept of row or column spanning, making it trickier to use one single layout structure than what might have been possible when using tables. However, similar layouts can be achieved by using nested CSS tables.

Of course, nested tables are not a perfect solution. When you want to match the dimensions of cells across nested tables, for example, things can get messy in a hurry, and the extra <div> tags really start to add up.

As it turns out, it’s also possible to simulate row and column spanning using absolute positioning of table cells, in many cases. In this example, we’ll make the second cell of the first row of a table span both rows of the table (as if it had a rowspan of 2). First, let’s take a look at the HTML code:

<div class="tablewrapper">
  <div class="table">
    <div class="row">
      <div class="cell">
        Top left
      <div class="rowspanned cell">
      <div class="cell">
        Top right
    <div class="row">
      <div class="cell">
        Bottom left
      <div class="empty cell"></div>
      <div class="cell">
        Bottom right

You’ll notice that we’ve wrapped our table div in an extra div with a class of "tablewrapper". This extra div is needed to provide a CSS positioning context—which we create by giving it relative positioning:

.tablewrapper {
  position: relative;

According to the CSS spec, we should be able to simply apply relative positioning to the table div, but current browsers don’t seem to support this.

Sleight of Hand and Absolute Positioning

Now, we can use absolute positioning to control the size and position of the div with class "rowspanned cell":

.cell.rowspanned {
  position: absolute;
  top: 0;
  bottom: 0;
  width: 100px;

With the top and bottom properties both set to zero, the cell will stretch to fill the full height of the table, simulating a row span. Depending on the needs of your layout, you could use different values for top and bottom, or even set the cell’s height directly to achieve other row-spanning layouts.

You also need to specify the width of the cell. Usually, the easiest way to do this is just to set its width property, but depending what you know of the dimensions of surrounding table cells, you could also do this by setting left and right.

Since the positioned cell doesn’t actually span multiple rows of the table, the table must still contain a corresponding cell in each of the other rows. These cells are simply empty placeholders, though; note the div with class "empty cell" in the HTML code above. The function of this cell is to hold open the space that will be occupied by the “spanned” cell, so we must ensure its width matches the width we specified for the "rowspanned cell":

.cell.empty {
  width: 100px;

And that’s all there is to it! To complete the style sheet for this example, we need only set the appropriate display property values, and add some borders so we can see what’s going on:

.tablewrapper {
  position: relative;
.table {
  display: table;
.row {
  display: table-row;
.cell {
  border: 1px solid red;
  display: table-cell;
  border: none;
  width: 100px;
.cell.rowspanned {
  position: absolute;
  top: 0;
  bottom: 0;
  width: 100px;

In essence, by using absolute positioning we are telling the browser, “Let me handle the layout of this table cell—you take care of the rest.” Here’s what the results look like:

Try it for yourself. This example works in all major browsers except for Internet Explorer 7, and also works in the current IE8 Beta 2 release.

What do you think? Can you see yourself switching to CSS tables for layout as your Internet Explorer users make the move to IE8?

  • madr

    Let just hope IE-team find a strategy to make all or at least as many as possible of adapt IE8 as soon as possible. Even if one IE version is ok, one will still have to struggle with at least 2 horrible versions for many years to come.

  • Matt Wilcox

    Implemented all properties, in Beta2? Oh really, then where the hell is Generated Content, because that still doesn’t work on my site. And, brilliantly, it crashes the tab completely when used in conjunction with :hover pseudo class. Excellent.

  • Instead of massively nested tables, we now have massively nested divs? No thanks.

  • Right now, the only instances where I can think of having the content of bottom left not following top left immediately in the source would be if I was actually using a table. Maybe I’m not thinking creatively enough, but I can’t see a plausible usage for that type of HTML structure at the moment.

  • Rodrigo Fante

    no thanks… back to the past isn’t the solution for the future…

  • Nunks

    I’ll have to agree with stopsatgreen. Why not use an HTML table in this case?
    I feel CSS isn’t making things easier, and this looks like an example of using the wrong tool for the job…

  • aaron.heinrich

    This is interesting. However, the one real advantage of table behavior with regard to layout is the ability of one cell to automatically expand to fill the space left by a neighbor cell within the parent table. But it’s hard for me to believe that this one advantage is worth the new quirks that will inevitably arise during actual implementation. Besides, how may years would it be before we could actually use this method? Our lowest common denominator which we’re developing for is still IE6.

  • Sojan80

    It seems almost like driving nails with jackhammers to me. While you can do it, you’re going to punch one hell of a lot of holes in your walls in the process.

    I’d have to say I wouldn’t adopt this one for a while and not unless some very convincing arguments could be made in favor of doing it. Otherwise use the right tool for the right job.

  • Robert Cameron

    I read this and thought, Why on earth are you re-inventing the wheel? Using a table is not a sin. I’ll even use it for layout IF I can’t find a simpler alternative (or have to support a device that doesn’t support the css I need). That said, a table should not generally be used for layout, but it SHOULD be used for tabular data.

  • David

    Why bother? If I really want to use tables, HTML tables are actually less coding than using the nested divs. The whole idea of NOT using html tables is that the presentation is handled more exclusively by the CSS. In this example, the CSS does handle much of the presentation, but the HTML is coded to a specific presentation as well. In the end, you’ve gained nothing! Might as well stick with HTML tables.

  • Stopsatgreen posted my exact thoughts.

    CSS tables might end up being great, but not if it takes a bunch of divs to make them work.

    Of course, everything in a page tends to be marked up as something, so perhaps they can be useful styling existing markup in certain situations. I wish I had some free time to play around with this :(

  • Erik

    I’d recommend using table-tags for a table.

  • luciano991

    Here’s what I think.

    First of all, for all the cranky posters, nertz to you!

    Secondly, I find it helpful to the conversation on standards to read about any idea at all that represents a new way of thinking. I always learn something. There are some display properties in this tutorial that I was not aware of.

    I think that we need to be more agnostic about tables and standards.

    I think that the fact this solution doesn’t work in IE7 and there’s no hack for that is deal breaker.

    I think that we should use standards, think standards whenever we can, and not be afraid to use an actual table from time to time. We have clients to take care of so let’s get over ourselves.



  • Redivider

    While I’d love it if everyone upgraded to IE 8 when it comes out, we’re still dealing with clients who still use IE 6.

  • Pablo

    It looks neat, but everyone has a valid point here. Not everyone will migrate to IE8 right away, maybe the ignorant, but I really think IE8 will have its shares of bugs too, even if it can implement this. Perhaps the only advantage is that you can position this more precise? I am not really sure about that though, I have had problems positioning tables in the past.


    I don’t think it would be possible for me to come up with a more complex and convoluted way to do something that is so simple and flexible to do in HTML. Every slightly different cell size or variance would require an entirely new class. It just seems like so much extra work for little, if no reward. I’m all for making things better, but not to change things just for the sake of making it more complicated to implement. It should still remain relatively easy for someone to present something in HTML. You shouldn’t need a doctorate in CSS to put a simple table together.

  • HybridCodeIsTheWayToGo

    In the stubborn effort to refuse to acknowledge HTML’s place in the world, Sitepoint goes sailing right over the top. I laughed out loud at the nested divs in this code. I like CSS as much as the next person, but, come on people, for those of us who manage large, complex production e-commerce, database-driven websites, maintained by many hands, and that need to support the browsers of every paying customer, this is ridiculous, both in theory and execution. CSS is turning out NOT to be the presentation layer solution everyone was hoping for. (I’m still laughing at the thought of going into my next development mtg and telling my developers, forget about our unbreakable cross-browser hybrid code. We’re replacing HTML tables with *this*. Hoo, that’s a good one….)

  • tgoyer

    I can see using to fix all those horrifically complicated “solutions” for 3-column layouts and all that.

    Currently I’m still using an HTML table when that requirement arises because they are far less buggy and error prone to get working in all browsers compared to all the hackified pure-CSS solutions. I would *love* to be able to use a pure CSS solution for this.

  • mford

    Interesting, as ever, but I don’t see the point. Perhaps I’m missing something, but this appears to re-invent the wheel with twice the code.

  • There’s a lot of div’s – better stick to the actual table and use col and rowspan then use CSS for the format. Tables are good when properly used especially for spreading out data. To many div’s for me. And then you have to start to worry about the browsers that can read the stuff.

  • While I have to agree with the points re: convoluted markup and lack of support for real-world application (that is public IE6 usage) the contrived CSS classes could be simplified by using CSS2 adjacent and sibling selectors and thus a single id on the parent ID would suffice for styling the rest of the ‘s.

    Granted this is still pie in the sky given lack of support for such selectors but as someone said above, worthy of discussion no?


  • Sorry, that should have been “..thus a single id on the parent div”…

  • Jamesy

    Wonderful, great, thanks, however am I missing the point here? I mean why not just use a table, less markup for a start and does what it says on the tin.

  • gzyz

    Bottom line is that it needs to be browser compatible for it to apply to the industry. Secondly, as it’s been iterated here, if you have to jump through hoops to get what you want, it’s probably not the correct answer out of all the possible answers available. Sometimes you just need to sacrifice layout choices for the sake of compatability and proper structure/form.

  • sqwirral

    That bunch of divs reminds me of something, a t… ta… nope, can’t think what it can be.

  • Shulem Jeremias

    I like the idea of standards, and I try to code as compliant as possible.
    Having said that, a standard is as respectable as good as it is. What I am is that if a standard doesn’t deliver the usefulness that it should, it is not a standard. If Microsoft (whatever names you call ’em) does not accept a feature, the it shouldn’t become part of that standard, considering that the largest vendor haven’t accepted it.

  • Just to clarify my disdain for the nested divs, I’m not against CSS Tables. I just don’t like how they were presented in the example above. Maybe it was necessary for the example, but it was still ugly.

    I’ll eventually use CSS tables even if just to have 3 columns that go to the bottom of the page without having to write a bunch of gobeltygook to keep them from stopping short.

    It seems a lot of you are against the idea of using them at all, I hope you at least read Kevin’s earlier article on them before passing complete judgement. (Which could still go either way, they might end up sucking in practice)

    Of course this still doesn’t help the fact that we can’t rely on them if we wanted to until certain widely used browsers (*cough* IE6 and 7 *cough*) finally retire.

  • Nonz

    I don’t know how many times we’ve gone back to using tables for layout simply because getting CSS to work on all browsers was adding far too much development time to the job. From an SEO standpoint CSS was more efficient at cutting down on code clutter than tables so when I first heard about CSS tables I was overjoyed at the prospect.

    The problem is with CSS tables the code clutter is just as bad, if not worse, than tables.

    It’s a pity, I was really looking forward to it too.

  • Georged

    I think this one misses the mark. If one needs to display tabular data, good ol’ tables is the way to go.

    If objective is newspaper-like layout, there are excellent CSS grid frameworks out there, namely blueprint and grid960. As an additional bonus they do support all IE versions.

  • Chadwick Meyer

    I agree… why have tables become everyone’s favorite whipping boy? They are simple, elegant, less code than this new suggestion, less code than most divs when you add in the complimentary CSS, and they are backward compatible to 1990 and beyond. I tried switching to CSS layout about 5 times over the past 5 years, and I gave myself a headache everytime. We do about 75% CSS layout, but we also use tables when we need the flexibility. Someone has yet to explain to me, why that’s such a bad thing. I’m all for standards, but if standards are going to take away tools and handicap our development screw it. Fix the standards or make CSS do what we need it to do.

  • Tim

    @Kevin, nice work on the achieving the second half of this quote … “unannounced, potentially controversial book on CSS” :) Can’t wait to see what the rest of the techniques might be!

  • tbee

    I see other responses in the same style; we’re hacking our way around a CSS short-coming AGAIN? Wait until it turns out that there are differences between browsers, then we get hacked hacks!

    If CSS can’t do it straight forward, use a template engine and use HTML tables. In the end this all is mostly about maintainability for the coder and a template engine goes a long way in achieving that.

  • nathj07

    Are you really suggesting tables for whole page layout? that to me seems to defeat the point of CSS somewhat. CSS moved us from using a data format for general content. tables are great for presenting tabular data but as your code shows they do not handle normal site content so well. DIV’s and SPAN’s are much better placed for that and give you much more flexibility and easier maintenance.

    Let’s just forget about tables fr anything other than tabular data.

  • nathj07

    Also, a method that works n all major browsers apart from the worlds most popular browser! Surely that’s a bit poor. I can get the layout you describe using divs and it works in Opera, FF, IE6, IE7, Safari and Google chrome without the need for any dodgy hacks.

  • Ricardo Peirera

    What’s the story of the CSS fanboys and ? They work great, they’re compatible with all browsers, easy to read and develop. Why do we need a 1K CSS definition for something we can do under 100 characters?!
    (Ok, there are some table-nesting abuses out there, but there’s also a lot of css abuses, so that’s not an argument)

  • Sammy

    Using CSS Tables for layout is a joke.

    I have spent a lots of time perusing the “Advanced Layout Module“. I strongly believe this is the only true layout that completely achieve the separation of contents from presentation.

    The problem is that no major browser is implementing this module which is very unfortunate.

    Firefox and Safari are starting implementing CSS animation and transition and all other things which are not necessary and they have not yet implemented a true layout such as grid layout or Advanced Layout module. They need to get their priorities right.

    In the meantime using mixture of Tables and Divs are the best tool. using floats for layout is extremely ridiculous. Div within Div within Div…

    CSS tables!? Haha ha ha very funny.

  • Jon

    As others have pointed out, this is really no better than just using tables. In fact, I’d say it is worse, as you’ve replicated the markup structure of a table, but obfuscated its real nature using class attributes and CSS.

    There is a proposed CSS module called “Flexible Box Layout” that would provide a better mechanism for achieving layouts like this, without using tables or excessive markup: . Although the spec hasn’t been worked on since 2006, there was a discussion on the W3C CSS mailing list about it a couple of months ago, where both Mozilla and Apple expressed a high degree of interest in getting something implemented.

  • anon

    Looks like a kludge, no thank you.

  • cob

    I understand if this is one of those demo to show off some of the flexibility of CSS. Otherwise I don’t understand why anyone would do this.

    I thought everyone was working towards the “semantic web”?

  • Ean

    Something about this seems messy and not exactly semantic to me.

    As well, our previous version of IE is 7. To make matters worse, significant numbers of users still use IE6 when we’re checking the analytics for any site a normal person might browse.

    That’s not, for example, a site where you find creative or programming content of any kind because these people tend to upgrade. I’m talking about your local chamber of commerce, some corporate intranets, e-commerce sites and many other situations where older browsers might be used out of necessity or habbit.

    This requires messy stylesheet switching using tags.

    To make matters simpler, if a layout can be achieved fairly accurately which works in IE6 and displays properly in the rest without relying on anything newer than CSS1, I think that’s where I’ll have to leave it for now.

    This is a great glimpse into the future, but I don’t think the modern web is quite as modern as we as developers would like it to be.


  • I think it’s not Kevin (and by extension – the article), but a lot of the commenters here that miss the point – CSS tables are NOT the current thing. They’re the next thing.

    Another new feature – another thing to make degrade gracefully. That’s how it has always been, that’s how it still is, and will be.

    The example is bad though, I’ll have to admit that. An example like the one from that other article mentioned would’ve been a better one.

    The example here is to illustrate a method (styling divs as tables), not to provide a specific solution (“How do we create tables?”).

    It’s all about semantics here – if you have tabular data, use a table. If you don’t have tabular data, but want it to appear as a table, use divs styled as tables (and with the current state of things – make them degrade gracefully when linearized). SEMANTICS is the lesson CSS was supposed to teach. Using tables is good, using them for layout is bad. Using any HTML for what it’s meant for is good. Using it solely for presentation is bad. DIVs and SPANs have no semantical attachment, so if all else is not appropriate, they are there for it. For all of your presentation needs, use CSS (any CSS – including display:table;).

    As for the verbosity, as suggested, there can be a single class, and everything from there on be styled with more complicated selectors (more CSS, less HTML – another thing CSS has been doing already).

    Here’s the example in the article, refined:

    <div class="tablewrapper">
                <div>Top left corner (or menu, or header... remember this is just an overall example)</div>
                <div class="rowspanned">Middle cell, rowspanned</div>
                <div>Top right corner</div>
                <div>Bottom left corner</div>
                <div class="empty"></div>
                <div>Bottom right corner</div>

    and CSS

    .tablewrapper {  
       position: relative;   
     .tablewrapper > div {  
       display: table;   
     .tablewrapper > div > div {  
       display: table-row;   
     .tablewrapper > div > div > div {  
       border: 1px solid red;   
       display: table-cell;   
     .tablewrapper > div > div > div.empty {  
       border: none;   
       width: 100px;   
     .tablewrapper > div > div > div.rowspanned {  
       position: absolute;   
       top: 0;   
       bottom: 0;   
       width: 100px;   

    The markup is still a little more verbose than a plain ol’ table, but again – the idea is to use this only if your data is not tabular, but needs to be presented in a table-like fashion.
    (as far as use cases for spanning go… I can’t think of a use case today either, but when we do have this power at our hands without being afraid to use it because of IE6 and 7, we’ll all think of something)

    Wow… this comment went on being more lenghtly than I expected… ok… rant ends now.

  • Ean

    Wow, I think about half of the comments out there ignore the fact that we’re talking about marking a site up with non-tabular elements and treating them like a table in CSS.

    Basically he’s talking about the super-new parts of CSS that let you get what you had in tables way back in the day just as easily.

    The issue he’s presenting here is that there’s no support for rowspanning or colspanning. This is a “hack” to make rowspans and colspans possible.

    The unfortunate side-effect is that we have extra tags to deal with. This is a moot point when you consider to get full-length columnuar layout in CSS1 you often have to have a clear: both; float: none; div at the bottom of your columns anyway.


    To Chadwick Meyer – using CSS simply allows you to style your content. The reason for switching to properly written, semantically correct HTML is first and foremost accessibility.

    HTML was created so you could organize thoughts into specific categories. These categories are represented by the tags you use to write HTML and each HTML tag has a specific purpose.

    When you’re using tables for layout, you’re essentially using an awful hack to get the “look” you want while sacrificing organization and accessibility on some devices.

    h1 is a main header – it should be the title of the document you’re writing or something like that

    p is a paragraph of text

    li is a list

    table is a table of tabular data such as a balance sheet, etc.

    If you misuse the tags, it breaks the semantic validity of your document and basically:



  • bgano

    aaron.heinrich hit on an important point about the main benefit of using HTML tables for layout is that cells will expand to fill all available space. This technique doesn’t solve that problem, or only does so for a small fraction of layout choices. Faux columns and others are much better solutions to the problems this technique aims to solve.
    cob later said, “I thought everyone was working towards the ‘semantic web’?” Exactly! What happened to writing your markup to describe your content, NOT your structure? How do you intend to achieve properly nested headings with that structure?
    I understand that this is a technology demo, and the example in the article is meant to outline what can be done, not necessarily a recommendation on how to do it. I think you need to be very careful to label it appropriately, or you’re going to start seeing this pop up all over the place. How do you think the propagation of HTML table-based layout came about if not through books and articles just like this?

  • The code is little bit long. Instead of this much length, we can use table.

  • Sreenath Urala

    Would make it more stylable than tables for sure. But can get very deeply nested. But what other option does one have if he must stick to divs? None as I can see.

    But sad that IE doesn’t support his strategy. It’ll be ages before IE 8 replaces IE 7. I still have a hard time getting my clients move to IE 7. And am glad that Chrome supports this.

    What would be a workaround for IE 6 and 7?

  • prose

    Seriously, why is everyone so afraid of making a table tag.

  • shanchan


  • Having contributed one, and read all the other comments here, no-one *no-one* seems to have mentioned the “A” word.


    Lots of people say “tables are bad for layout”, but do any of you know *why*?

    When a screenreader hits a table, it, quite rightly from the HTML specs point of view, expects to see – well – tabular data. Further, to my knowledge, older screenreaders (and there are lots of them around) have issues with reading tabular data in the way that the developer might have designed the layout to be read and perceived by the user.

    So by creating simple, bloat-free, easy to maintain markup (sans “classitis”) and ensuring the markup source order, correlates with the intended page layout and text/content flow, you are creating a web-page that can be read by anyone, using any computer interactive device, be that keyboard, mouse, pointer, pen, or wand.

    If you ever get the chance to see Andrew Downie or any other blind web-user talk at a seminar or conference go and do it, it’s an eye-opener and a half, (if you’ll pardon the pun) and you’ll see what all the fuss is about.


  • HybridCodeIsTheWayToGo

    boen_robot made a good point when mentioning, “I think it’s not Kevin (and by extension – the article), but a lot of the commenters here that miss the point – CSS tables are NOT the current thing. They’re the next thing.” I was guilty of that, too, in my previous post in not acknowledging the article was not presenting production code for today. However, my frustration with the lack of evolution of CSS remains. In the e-commerce world, product presentation and geometry go hand-in hand. In the presentation of products, clients demand the visual appeal of even and consistent distribution of [database-driven] information. CSS is unruly, at best. It’s cool, it’s fun to play with, and much beloved by me and my e-commerce development peers for certain formatting tasks, but, for presentation layout/structure, in my field, it’s a support nightmare. Looking down the road, if I have to face doing CSS tables with this type of row- and colspanning code to achieve certain layouts, I will have to quit my job and, I don’t know, bake bread all day or something. It is *not* a step forward to double the code load to achieve the same thing that has been supported via HTML since Al Gore invented the internet. Should we chase the rainbow of semantic coding and move away from HTML on the presentation layer? Sure, okay, I’m game. Should CSS be the path we trod? Um…. hm.

  • arts-multimedia

    Sure, you can do anything with CSS, if you put enough time and effort in it, but are we not forgetting something here? Are tables not meant for tabular data? Hence, are CSS tables not meant for tabular data?

    Why use table layouts again while that practice was condemned in the first place by usability experts and css purists?

    For the rest, I agree with many of you that, as an intellectual game, this is fun, but I doubt it is practical. I can see the hours of debugging already looming up and I thought css was going to make life easier on all of us?

  • arts-multimedia,

    Are tables not meant for tabular data? Hence, are CSS tables not meant for tabular data?

    No, they aren’t.

    HTML tables are meant for tabular data.

    CSS tables are meant to describe table-style layouts, both as they apply to tables, and to non-table elements. From the CSS 2.1 spec:

    In a visual medium, CSS tables can also be used to achieve specific layouts. In this case, authors should not use table-related elements in the document language, but should apply the CSS to the relevant structural elements to achieve the desired layout.

  • arts-multimedia

    Thanks for the info, Kevin.
    Well, in that case, I’m sorry, but I find this a very poor solution. They will have to come up with something much better before I’m prepared to use it.
    I like css, but this method is pointless. It is easier to create layouts with regular divs, if you ask me.

  • Well, like many others here. I don’t see any real benefit to this in the near future. Sure, it would be great if this method worked in all major browsers, but the fact that it doesn’t work in IE 7 blows the whole thing for me.

    I market to my clients based on the fact that my sites are rendered the same in all the major browsers. Right now (and for years to come it seems) HTML tables are very consistent across those browsers. I say years to come because even though these new browsers are being released it doesn’t mean that users are going to upgrade.

    So, if I have to choose a method I am going to use the one that allows me to write the HTML code once for all major browsers.

  • Anonymous

    Semantics! I thought the lesson of CSS based markup is to create the page structure based on semantics and describing what the content is, rather than doing everything in presentation code!

    When and if a valid scenario for using the CSS table properties within semantic markup is available (and I’m sure there will be), then I welcome IE8’s full support of this. Otherwise, it is going backwards to the land of dodos for sake of layout rather than the content needing tabular data!

    (those who persist in using table elements for non-tabular content layout when CSS is suitable and works with minimal hackery: try harder!)

  • The fact that it’s displayed like a table doesn’t offend my sense of semantics in the least. We could call it a grid layout or a boxyMcRoxy layout instead of a table layout – it doesn’t matter! It’s still not going to require tabular data for correct semantic use. CSS is for how you want stuff to look and how you want it to be arranged. You get to pick how to arrange stuff. HTML is for marking up your information in a way that describes it.

    HTML table tags are the ones that need to be used for tabular data.

    The divitis in the example is not what I would consider good practice, but I wouldn’t classify it as semantically misleading in the least.

  • asbjornu

    People who reply that this is the exact same as using a table misses the point entirely. The whole point of not using a table is because a table has a semantic meaning where columns headers signify the type of content to expect in given data columns. A table also explicitly and visually places the first td left of the next and so on.

    Using display: table, however, is something completely different. First, you’re not semantically marking anything up as tabular data, because it isn’t. Secondly, without the CSS or even without display: table support, the rendering will be completely different. The rendering will be up to the user and the user agent, not up to the design or the designer. And that is precisely how it should be and why display: table is such an excellent idea.

    The people that don’t understand this probably don’t use table for tabular data either, because “tables are bad!” If what you want is a visual layout that mimics that of a table, then display: table is what you should use. Using a table instead since that’s “the same” just proves how little of the semantics involved you understand.

    • Anonymous

      This is why the CSS guys should have named these tags “grid” instead of “table” and avoided the confusion altogether…

  • sqwirral

    And that is precisely how it should be and why display: table is such an excellent idea.

    It doesn’t even work. I’d rather go the non-semantic route if it means tidier and less code, and actually works in current browsers.

  • Anonymous

    i prefer to simply use a table and style the rows and cells,
    until the browser creators get their act together.

  • Has anybody looked at this from an accessibility mindset? It doesn’t seem like it. Screen readers use table elements to allow the user to navigate the table. CSS Tables are lacking this, and can’t reproduce it, yay

  • arts-multimedia

    Not using html tables as a method to to create a layout IS looking at it from an accessibility mindset. There is no other reason, actually.
    If screen readers cannot handle css tables then I suggest the makers of screen readers adapt to the new standards.
    That said, the css tables are not worth considering at this time, as you can read from many other comments above.

Get the latest in JavaScript, once a week, for free.