So I am trying extremely hard to convince myself that these css grids are much better than html tables. Yet, when I see projects like these that make the act of making two columns of arbitrary widths such a big deal, I find it hard to convince myself that css for your basic page container is worth the hacks. I really want to be convinced otherwise because I'd like to believe if so many people are for it, I am obviously not seeing something they can.
So dear HN, please help me convince myself that CSS and its hacks are superior than tables.
My mind's first objection: "to make a simple two column layout that would typically take a few lines with the table tag and be compatible across browsers. The same thing in css would require the use of an open-source grid or bunch of hacks and testing--taking much more effort than the table tag". How do I respond to this objection?
It isn't about which is easiest to implement. No one said CSS(3) was super-easy. This discussion is also very old by now. I am surprised to bump into this view again.
A CSS layout is better than a table-based layout, due to:
- Maintenance: Maintaining or redesigning a table-based layout is very cumbersome, especially with nested tables, because:
- Seperation of content and design: The content has to be changed, to change the design, and that is not a nice workflow.
- Accessibility: CSS designs allow much better for a user-specified stylesheet. Resize the browserwindow and tables keep sticking out, where with CSS you can change the order (put columns under each other). Screenreaders behave in a specific way for tables, they try to read the "summary", or they assume the table holds tabular data, reading it row by row. A table lay-out can therefor confuse.
- SEO: CSS designs make content stacking possible, tables only allow to put the content in the order of the table cells. Webmaster guidelines ask you to check for correct use of HTML, which tables for lay-out isn't:
- Semantics/standards: Use tables for tabular data. Provide a summary and table header if relevant and possible. Using tables for lay-out semantically turns your entire page into tabular data.
- Pagespeed: CSS allows for faster, progressive rendering. HTML tables take their width from the resulting table-cell: Content will jump around while rendering or some browsers even show a blank table before all content is loaded.
A CSS framework like this is far from hacky. Using tables for layout, because CSS is deemed too complex, now that is hacky.
Also, don't forget support for "display: table" is in near all modern browsers. If you really want to design lay-out like you are using tables, it is possible with CSS too.
For responsive designs, much more is possible with CSS than a 100% width table. You can't just slap a few lines of table and expect it to work well on an ipad.
I agree with all the points you listed and that CSS layout is superior. However every time I use a CSS grid I find myself thinking whether the content and design are really separated. If I add classes like .col-1-4, .span3 or .three.columns to an element in the markup, doesn't that mix details specific to a certain design (or even one particular screen size in responsive design) with the content?
remind me of tables too. They tend to add a few unneeded or non-semantic div's. And they don't really separate content and design. It is a lesser-of-two-evils thing for me, because sometimes grids/frameworks can save me a lot of time. Ideally you'd use semantic-sounding classnames and don't include unnecessary div's.
I agree completely, which is why I'd say the solution is to use a grid framework based on Sass or LESS instead of vanilla CSS (I'm partial to Orbital[1], but I'm biased because I wrote it :P). If your column sizing can be applied via preprocessor mixins instead of CSS classes, it's easy to keep your HTML free from nasty non-semantic classes. If you hunt around on GitHub, many popular CSS grids have unofficial LESS/Sass ports as well.
I agree with all these statements. But the most important thing to point out is that CSS 1 and 2 and even 3 didn't solve the layout issues we needed solved. But there are improvements like native column support and true layout control coming. But damn, it's already nearly 2013.
Absolutely agree. The hundreds of websites devoted to explaining how to achieve a X-column fluid layout are testament to CSS's failings in this regard - seriously, layout as a problem has been solved for 15+ years [1].
We're finally getting some progress on constraint-based layout in the form of the flexible box model (great modern browser support), and CSS grid layout, which surprisingly enough is coming from MS.
I agree, the fact that it's almost 2013 and we're still wasting valuable brainpower on f*ing around with what should be trivial layouts is a bit of a shame.
Well that's because we accidentally took a publishing system designed for academia and turned it into the largest explosion of design and media in the history of mankind.
A table for layout is semantically meaningless. If you view a webpage as vaguely structured data, then using a table for layout is akin to using a String to represent an enumerated value. Sure, you can do it and it will work, but you're diminishing our ability to reason about your data and access it with our tools.
If I'm working in a codebase and wanted to see where we're presenting tabular data to the user and we're using tables for layout, I now cannot know which kind of table I'm looking at: presentational or structured.
If a user is using a screenreader to access a site, the screenreader will see the table and read it line-by-line. In a presentational case, that means <tr> by <tr>. This is meaningless to a non-sighted person and lowers the usability of the site.
Tables don't respond to CSS as well as other block elements. Try setting the width or height of an individual cell in relation to the container. You'll likely end up using spanning columns or spanning rows or setting the width using table attributes. Now we're breaking the abstraction between HTML (structured data, our model) and CSS (presentation, our view). We're now scattering view-related semantics inside of our model.
Not sure this directly answers your question, but: CSS (div-based) designs can be responsive in the sense that if you have 3 columns they can get rearranged one under the other in a smaller screen (like phone). Tables can't do this - 3 columns are always 3 columns.
This is just the first reason I can think about right now.
I think this is a perfectly reasonable question especially when it is so easy to slap some code in a table. It can seem like a lot of bloat just to get two columns center-aligned on the page when you're used to using tables.
But, I think tables are best for tabular data. CSS is best for layouts. With CSS you can have your layout more easily adjust for different browsers, mobile, etc. with tables you're locking yourself into one layout.
Also though using styles - the CSS can tend to be a bit more code, but the HTML can wind up looking very clean.
I thought the main reason for not using tables for layout was that the layout algorithm is very expensive, since the size of each every cell depends on the size of every other cell.
As someone who gets elbow deep in tables & inlined CSS fairly regularly still (japanese non-smartphone websites ... ガラケー).. trust me. CSS is fannnnntastic.
That's an excellent point. I actually don't remember why we all moved away from tables (it was before my time). Do you know what was so bad about them?
The web started a move to being all about semantics, machine readability and interpretation of pages by robots (like Googlebot). Personally I threw my lot in with XHTML and started moving to XFN and other microformats.
One of the big things with tables was screenreaders. Screenreaders assume a table is tabular data and treat it as such leading to a terrible UX. Where I am, a business that doesn't make reasonable changes to accommodate disabled users is acting unlawfully.
Screenreaders basically amplified the error of using semantic markup where non-functional style is intended. Semantics was the in thing for a while and separation of function and style pushed people towards using pure [X|]HTML with no extraneous tags and all styling performed outside the markup via CSS files. Tables for tabular data only.
CSS promised to bring table-layouts to 'display:' in CSS1 but IIRC MSIE put the kibosh on that one [that's en-gb euphemism for 'stopped it'] and indeed it's only just become fully supported in IE9 I think.
Markup philoshopies aside it was a real bitch trying to edit tables or change layout with tables without decent visual layout tools. You'd have a page-table (for body centering), then that would have a table for a main grid, then you'd have a table for the visual header, a table for the menu, a table for the ads column(s), tables for the footers, tables to put pull out quotes in, tables for aligning images. All those tables made page markup significant at a time when home users didn't have ADSL connection yet.
You'd end up with nests of tables easily 10 deep on some sites and working out in the markup what was happening in such a site was a nightmare. In contrast a well CSS formatted page is (was?) slim, the content is simple and changing layout is just a matter of altering the CSS and not re-writing the whole page.
It became a point of pride for many to avoid frames, a way to show one knows ones game. For a while it seemed that as no really needs to wrangle with IE6 all the fun would have gone out of CSS layout ... but then we got iPad and a million different android resolutions to worry about and so again there is pressure to use liquid responsive layouts where in the interim things have gotten very much focussed on pixel-perfect presentation.
That all said I was having the same thought the other day - that CSS grids are starting to look a bit messy and that I'm ready for the next iteration.
So dear HN, please help me convince myself that CSS and its hacks are superior than tables.
My mind's first objection: "to make a simple two column layout that would typically take a few lines with the table tag and be compatible across browsers. The same thing in css would require the use of an open-source grid or bunch of hacks and testing--taking much more effort than the table tag". How do I respond to this objection?