We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you two Citrix podcasts. Learn about 2020 trends and get answers to your biggest Citrix questions!Listen Now


Feedback on CSS Table Generator

Medium Priority
Last Modified: 2013-11-19
I'm working on creating a generator for creating valid CSS Tables. The generator is supposed to create pure CSS tables and, as far as I can tell, the results produce valid HTML and CSS markup.

Generator: http://rowdydata.com/Toolbox/CSS/Tables
Example: http://rowdydata.com/Toolbox/CSS/CSSTable_Example.aspx

Points awarded for providing ideas for improving it or pointing out problems areas you see with it.
Watch Question

It works, but it's completely the wrong idea.

CSS isn't about translating everything, one-to-one, to a table.

CSS is about marking up document properly, with tags that make sense, AND THEN applying styles so that it looks nice. This does nothing of the sort. It just basically replaces rows and columns with divs and spans, which is not the point of CSS design.


>It works, but it's completely the wrong idea

What do think my idea is?

It's not to simply use CSS for the fun of it--I've got better ways to waste time.   :-)

I have fairly frequent situations where the flexibility of using CSS tables is preferred.  For example, I may want to display the rows as paragraphs or some other non-column format to optimize the layout depending on the media accessing the page (print, mobile devices, AT sofware, etc).

I've just always used a snippet for my template and the other day I decided to update and test it for IE 7.  While I was tinkering with it, I figured I could just make a quick generator to save me some time in the future.  I'd like to know if there are any problems with the output that I might be missing.

I could probably build in more options for how the "table" gets formatted.  I picked the most time-consuming option for me (creating a direct HTML table replacement) but having it create alternate layouts with the same structure might be useful.

Hmmm, at first glance I would say, waste of bandwidth. If you're looking for something to replace tables in a completely non-semantic way, why not look for elements that have shorter names, like <b> and <i> tags? And at least shorten your classnames to reflect the original element-names.

At second glance I read something about "sites that want to be highly accessible" and can't help but wonder about the semantic garble you're cooking up.
- How will it assist usabillity for visually impaired users?
- How will the waste of bandwith help mobile users?
- Is this a solution, or just a band-aid to get us by until a real solution pops up?
- Would it help to read the specs on tables again? It has some hidden semantics that might be usefull:
  * http://tantek.com/presentations/2005/09/elements-of-xhtml/ This presentation goes with a podcast from web-essentials 2005. And talks about the axis and headers properties.

I'm being overly critizising here, but it serves a purpose. I think you should have a bloody good reason for implementing tabular data in a non-semantic form and from your site I don't get the impression you have such a good reason for it. Apart from that I have to point out again, if you're doing it for the mobile user, you should considder saving bandwidth, data is expensive and slow for a mobile client.

If there's serious issues for mobile devices in using tables, the mobile device programmers will come up with a solution, I think you'd be better of waiting for that, or looking for more semantic solutions.

My two cents,


Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts
I've got to completely disagree with the approach and the reasoning behind it.  I would *highly* suggest you look into all the various accessibility features built into tables in (X)HTML.

An *excellent* write-up can be found at: http://www.456bereastreet.com/archive/200410/bring_on_the_tables/


Jeff, if you want completely disagree with the approach or the reasoning that's fine and you're welcome to explain your position.  However, if you're going simply reference articles from 2004, I *highly* suggest that you explain how they are still *excellent* as opposed to obvious or "old news".  Perhaps there was something specific in the editorial that you found interesting or relevant to my question?  My only other option is to assume that your position is that you agree with this article in its entirety and that leads me to conclue that you work under a completely different philosophy than I do.

To all so far,

I mean no disrespect but if you don't see the reason for CSS tables, don't understand them, or don't like them is irrelevant in this question.  If it was, my question would be "Should I make this tool and how should I use it?"

If you don't like my approach or how the generator outputs the code and think you have a better way, please elaborate.  If you understand the need for designs that go beyond what a <table> can do and would like to contribute, please do.

If you're recommendation is to "just use a <table>", this may not be a thread you want to participate in and you might want to start peaking at the source code on some major sites.  You might be surprised at what is going on...You can start with http://tv.yahoo.com.  I'll give you a hint, the grid for the channel lineup starts with a <div> not a <table>.

My directions for this question were and are, "Points awarded for providing ideas for improving [the tool] or pointing out problems areas you see with it."  I was hoping to get useful responses like, "It breaks when I do this...", "This part looks funny in FireFox...", "Try using ordered lists for the rows/columns instead of DIVs because...", "Based on my experience, I know that ____ would work better because...", etc.  

In response to some of the comments so far...

>...at least shorten your classnames to reflect the original element-names.
I could. Especially if bandwidth was an issue.  Also, adding the ability to specify the target media (print, mobile, etc) would allow you to optimize the output. Programatically time-consuming, but it might be worth it at some point.  

>- How will it assist usabillity for visually impaired users?
How many points are you going to give me for explaining this to you?  Basically, screen readers "read" <table>s in columns (top to bottom), CSS lets them "read" in rows.  The reasons why and where this would be useful should be obvious.  

>- How will the waste of bandwith help mobile users?
Presumably this is a rethorical question but you make a flawed assumption...You may think that my approach uses much more bandwidth but, if you consider that <tables>s are rarely used without styles applied to them, it's really about the same and could probably even be reduced to require less bandwidth than a <table> (depending on the complexity of the table).

>- Is this a solution, or just a band-aid to get us by until a real solution pops up?
It is for me.  If other want to use it, so be it.  Just curious...When you say "a real solution", do you mean like some kind of alternative to a <table> that offers better flexibility, usability and portability while providing the same functionality as a <table>?

>-Would it help to read the specs on tables again?
Nope.  I don't think being reminded of the limitations of the <table> would help much.  Knowing what you can do with a <table> is easy--knowing what you can't do with a <table> and how to get past that are where the opportunities are.
But CSS is about semantic design. You CAN'T work in terms of rows and columns in CSS in order to use it. You work in terms of page divisions and headers and so on. And then, once the page makes sense, you add styles to it to make it look nice. But having semantic code is far, far more important for today's web design.

>>better flexibility, usability and portability

>>while providing the same functionality as a <table>?
Absolutely not. No. Not the same functionality as a table. Maybe the same presentation, at the end of it all, but certainly not the same functionality. A table has that functionality for a reason, and if you need to display tabular data, you use that functionality. A table.

>>Read the specs on tables again
You'd see that tables have a great deal of flexibility IF you use them for TABULAR DATA and NOT for layout.

>> Knowing what you can't do with a <table>
That's true, you need to know when to use other tags. But the second part:
>> how to get past that
If you mean use CSS hacks and replacing tables tag-for-tag with spans to work around that, you're wrong. If you mean using the correct tags and CSS so you don't have that problem in the first place, you're right.

Basically, screen readers "read" <table>s in columns (top to bottom), CSS lets them "read" in rows.  The reasons why and where this would be useful should be obvious.  

Screen readers read tables that way because, as above, using them for tabular data makes it make sense. That's the same reason that it makes sense to use Lists for navigation (different inflection, pauses after each item rather than just reading it through, etc) and correct paragraphs and headers for text, and knowing when to use <img> for images and when to place images in the background.

Why is it a GOOD idea to just replace all the table tags with <span>s with special classes applied to make them work like tables?

If you're going to point to a site as an indication of where things are headed, the *least* you could do is point to one that's actually forward-thinking rather than riddled with nonesense HTML, non-semantic markup, and all sorts of other silliness.

No doctype?  <style> blocks in the body? Mix of HTML and XHTML markup?  Source riddled with <script> and <noscript> blocks?  <center> tags?  <font> tags? Tables for layout?  I could go on and on and that's without ever checking it with the W3 validator.

Seriously, there is *nothing* about that site that's forward thinking.  It's age-old tag-soup crap.  It's positively laughable.

Seeing as how the spec *and* the screen reading software hasn't changed much, if any, since 2004, I fail to see the relevancy of the publish date of the article I referenced.  The important point is that it's chock full of good information on how to properly use tables in order to make them accessible.  In fact, there are numerous examples of table accessibility that your method can't reproduce on the best of days.

> >- How will it assist usabillity for visually impaired users?
> How many points are you going to give me for explaining this to you?  Basically, screen readers "read" <table>s in columns (top to bottom), CSS lets them "read" in rows.  The reasons why and where this would be useful should be obvious.

Huh?  I'm guessing you meant the other way around.  Screen readers read, almost universally, in source order.  Tables, by their very definition are constructed row by row and cell by cell within each row.  Therefore, they will be read by rows and not by columns.  While I can see benefits in certain circumstances in being able to read by columns, I don't think it's the primary mode of interaction with tabular data.  Further, should the user have capable screen reading softwar and want to switch from reading by rows to reading by rows with extended information describing the context of the data to the column the cell is contained in.  That's something your solution can't even come close to offering.

Sorry, but I don't see anything better about your approach.  If anything, I see it as a giant, non-semantic step in the wrong direction.  Maybe I'd change my mind if you'd link to some articles on the risks of tables with information about the screen readers that struggle with conventional tables and work better with something more like your solution.

Until then, I just don't see why I should use a screwdriver to hammer a nail in a wall and will continue to use the tools designed for the tasks I need to accomplish (tables for tabular data).
To follow up, I tested numerous screenreaders against your solution and a properly marked up table of tabular data and I could find no discernible improvement in the accessibility of the data.  For the record, I tested with the following: pwWebspeak 32 Release 3, Simply Web 2000, ReaderBar for IE, Window-Eyes 5.5, IBM Homepage Reader 3.04, and Jaws 7.0.  With the exception of Jaws which has the ability to read tabular data by column, every other solution can only read table data by row.  Moreoever, Jaws struggled even more with your solution than it did with a properly marked-up accessible table of tabular data.

I'm currently under the assumption that you're using this product of yours as an alternative to layout TABULAR data. If this is not so, if you're using this as a layout technique, please tell me now and I will simply walk away.


Sorry for not getting back for so long...it's been busy.

I'm afraid that I don't have the time to follow up on this thread and it's just not worth trying to explain everything.  I've got some local colleagues that I can work with directly on this and that will be much more efficient.

I appreciate your participation and thank you for your time.
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.