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.
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?
This is really nice (I love the subtle steam off the coffee on the page!), but I feel that basic grids like this are so straightforward to implement that anyone can whip one up for their project if they want one.
It's always good to have a template to start from like this, but I don't see it being much different than an on-the-fly one that I would throw together myself if I'm not using a framework.
Hey thanks for the kind words! I completely agree with everything said. I also think in a lot of cases, there might be some projects that require a difference in a grid, if one is being used so building a grid specifically for each project isn't always a bad thing to do.
That's actually why I created this grid, to fit a specfic project of mine. I am picky and wanted something that I couldn't already find so I decided to build one and throw it up on github.
True but this also helps a lot of people who aren't as comfortable with CSS layouts to better understand how grids work. I remember when I was green having one hell of a time understanding how to position elements in a grid and no tutorial really made the idea stick until I used a couple of grid frameworks and messed with them. So I think there's more benefit to this than you'd imagine and as a professional developer myself I actually haven't seen a grid implemented in this way before and it actually gave me a couple of ideas.
Nice, but I see you are using overflow: hidden on grid containers to clear the floats. This can be a pain when implementing absolutely and relatively positioned elements like tooltips and badges, etc.
There really wasn't a specific reason for the naming convention. Although adding "col-" to all of the columns allowed me to easily select every column using [class*='col-'].
I really like this. Very simple and lightweight, as advertised. Not perfect on IE8 but comparable with other frameworks that have too much going on.
One suggestion - use HTML5 semantic tags (header, section, etc) in your example page and code snippets. Too many divs scattered everywhere makes it a bit difficult to read.
You can only have two of the three things that you have on your wishlist. IE8 doesn't know how to apply CSS to HTML5 tags. This is typically fixed with html5shiv, a JavaScript library. But including html5shiv would make this grid less simple and less lightweight.
Very nice, fantastic work and thanks for putting it out there. Is there any license or usage info (WTFPL)? I read recently that if there is no license you shouldn't touch it because the default is non-permissive, even if the source code is open etc. Cheers.
I love the goal of keeping it lightweight. This is very similar to my grid of choice, the 1KB grid[1] which I like because you can adjust the number of columns and width in px.
Oh man I wish I could claim that I wrote that steam script but I don't know js that well. I'll try to find the original version that I worked off of and post it here.
On Chrome for iOS latest on an iPad 1 this doesn't appear to render properly. There's a gutter of scrollable space on the right side and the headers in the 4 ad copy columns bleeds over to the next column.
I'm not a fan (nor hater) of css grids because I prefer to make the html foundations for greater accuracy and control over the build. It's not rocket science, it's html and css! Second, you get a quality custom structure according to the spec of the website. You've placed HTML in specific configurations with ids and classes of your choosing, and the result can go beyond the grid! life outside the grid is good, a few dust storms and heatwaves, a bit of crime in the streets.
Looks good. Your #viewport div causes a strange error with having a horizontal scrollbar @ ~789px. Instead of using the margin-left, why not position it with left and top since it is already absolutely positioned?
Edit: you can probably just change margin-left to left and create the same steam effect that is offscreen when the browser is too narrow
CSS Frameworks are not for beginners. They're geared at developers who need to hit the ground running on a website.
I'd actually say to stay away from them until you've been doing front-end for awhile as the non-semantic naming conventions are not something beginners should be using.
I'm sure you could adjust positions with specificity, but in my opinion, that goes against a Grid Frameworks purpose.
The grid adds a base layout which you would then customize by adding classes and ids on top of the default grid classes. You can definitely adjust positions with pixel accuracy. The grid is useful because it helps with responsive web design: everything resizes and repositions when you change your browser size or use a mobile device to view the webpage.
I've been using this grid technique for a little while. It's really great. I was disappointed that the original author wasn't credited though. Compare with: http://css-tricks.com/dont-overthink-it-grids/
Hey corny, if you check out the description on the github page you will see that I gave credit to Chris and his post on css-tricks. I'm a big fan of Chris and that post was definitely the inspiration for the grid.
What's the advantage of using this grid system, instead of a framework that contains this functionality and more (such as Twitter Bootstrap or Skeleton)?
[+] [-] zaidf|13 years ago|reply
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?
[+] [-] blauwbilgorgel|13 years ago|reply
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.
[+] [-] drhayes9|13 years ago|reply
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.
Are those good enough reasons?
[+] [-] handzhiev|13 years ago|reply
This is just the first reason I can think about right now.
[+] [-] jakejake|13 years ago|reply
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.
[+] [-] aubergene|13 years ago|reply
[+] [-] minikomi|13 years ago|reply
[+] [-] tocomment|13 years ago|reply
[+] [-] sbarre|13 years ago|reply
It's always good to have a template to start from like this, but I don't see it being much different than an on-the-fly one that I would throw together myself if I'm not using a framework.
[+] [-] thisisdallas|13 years ago|reply
That's actually why I created this grid, to fit a specfic project of mine. I am picky and wanted something that I couldn't already find so I decided to build one and throw it up on github.
[+] [-] bpatrianakos|13 years ago|reply
[+] [-] pault|13 years ago|reply
[+] [-] armageddon|13 years ago|reply
Edit any of the H3 elements in any of the gray rows and simulate a tooltip:
<h3>col-1-1</h3>
Replace it in Firebug with a basic tooltip:
<h3 style="position:relative"> col-1-2 <span style="border:1px solid blue;background:yellow;display:block;position:absolute;width:300px;height:50px;left:0;top:-55px">Hi there</span> </h3>
The tooltips get cut off. :(
[+] [-] bmuon|13 years ago|reply
User guide: http://yuilibrary.com/yui/docs/cssgrids/ Code: https://github.com/yui/yui3/blob/master/build/cssgrids/grids...
[+] [-] envex|13 years ago|reply
Why did you decide to go with ".col-1-2" over something like (foundation's) ".one.column"?
[+] [-] thisisdallas|13 years ago|reply
[+] [-] bung|13 years ago|reply
[+] [-] petewailes|13 years ago|reply
Also, what made you choose to go fluid instead of fixed?
Also, would love feedback on a project I've been working on: http://wail.es/opendaws/ | HN thread: http://news.ycombinator.com/item?id=4669809
[+] [-] binarymax|13 years ago|reply
One suggestion - use HTML5 semantic tags (header, section, etc) in your example page and code snippets. Too many divs scattered everywhere makes it a bit difficult to read.
[+] [-] kijin|13 years ago|reply
> perfect on IE8
> use HTML5 semantic tags (header, section, etc)
You can only have two of the three things that you have on your wishlist. IE8 doesn't know how to apply CSS to HTML5 tags. This is typically fixed with html5shiv, a JavaScript library. But including html5shiv would make this grid less simple and less lightweight.
[+] [-] da_n|13 years ago|reply
[+] [-] firefoxman1|13 years ago|reply
[1]http://1kbgrid.com
[+] [-] artursapek|13 years ago|reply
[+] [-] thisisdallas|13 years ago|reply
[+] [-] JulianWasTaken|13 years ago|reply
[+] [-] exodust|13 years ago|reply
[+] [-] emehrkay|13 years ago|reply
Edit: you can probably just change margin-left to left and create the same steam effect that is offscreen when the browser is too narrow
[+] [-] daigoba66|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] thoughtpalette|13 years ago|reply
I'd actually say to stay away from them until you've been doing front-end for awhile as the non-semantic naming conventions are not something beginners should be using.
I'm sure you could adjust positions with specificity, but in my opinion, that goes against a Grid Frameworks purpose.
[+] [-] thornofmight|13 years ago|reply
[+] [-] corny|13 years ago|reply
[+] [-] thisisdallas|13 years ago|reply
[+] [-] andrewkkirk|13 years ago|reply
[+] [-] theallan|13 years ago|reply
[+] [-] thisisdallas|13 years ago|reply
[+] [-] bicknergseng|13 years ago|reply
[+] [-] tharris0101|13 years ago|reply