Show HN: A simple lightweight CSS grid, not a bloated framework | Hacker News Reader

Show HN: A simple lightweight CSS grid, not a bloated framework

thisisdallas.github.com

134 pointsthisisdallas62 comments

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?

I agree. Frameworks like:

  <div class="table">
    <div class="tr">
      <div class="td">...</div>
      <div class="td">...</div>
    </div>
  </div>

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.

[1]: https://github.com/lorelabs/orbital

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.

[1] - http://www.cs.washington.edu/research/constraints/solvers/ui...

Native column support will probably satisfy 90% of my objections. Until then, css seems like another hack(perhaps a better one) for a previous hack.

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.

Anyway, use compass sass or less. Use frameworks.

Okay, I'll bite first.

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?

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?

Tables carry semantic weight.

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.

People were using tables as a way to control the layout of pages.

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.

Not all of us are skilled at the front-end. I love your grid, especially how columns stack on resize, and wouldn't be able to just whip one up myself. The steam is cool too.

Absolutely! I commend you for sharing your work, big or small, and I hope people can benefit from this.

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.

Good catch.

Edit any of the H3 elements in any of the gray rows and simulate a tooltip:

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. :(

Maybe using display: 'inline-block' is a solution?

The same lightweight pattern has been used in YUI3 Grids for a number of years and it even works on IE6.

User guide: http://yuilibrary.com/yui/docs/cssgrids/ Code: https://github.com/yui/yui3/blob/master/build/cssgrids/grids...

Looks good, I'm just not a fan of the naming conventions on the columns.

Why did you decide to go with ".col-1-2" over something like (foundation's) ".one.column"?

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 just don't think I'm understanding when it comes to something like

.col-2-12 & col-10-12

It signifies the number of columns and how many columns each section, or div, takes.

In your example, the first section would take 2 columns out of twelve. The second section takes the remaining 10 columns.

Or, col-3-12 & col-9-12; first section would take 3 columns out of twelve and the second takes the remaining nine.

What I'm curious about is if doing something like this: col-2-12 & col-8-12. But I'm too lazy to download the css to see for myself.

I had the same problem as it seems the convention isn't explained on the website. However as soon as I took a look at the code it became clear that the numbers represent fractions. .col-2-12 is a column that is 2/12 in width (same as 1/6) and .col-10-12 is 10/12, respectively.

also multiple class support like that only goes back so far

Interesting. Have you thought about using the micro clearfix instead of overflow hidden to sort the columns?

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

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.

> Very simple and lightweight, as advertised

> 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.

Instead of including the entirety of html5shiv, it's almost no overhead to add in a shim just for the HTML5 semantic tags.

Here's a snippet I've used on a number of production sites: https://gist.github.com/3915474

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.

[1]http://1kbgrid.com

The most impressive part of this page to me is that way you animated the hot coffee mug.

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.

Here: http://dhirajkumarsingh.wordpress.com/2012/07/31/animated-sm...

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

This is really useful as a template for building a CSS grid system. I love that it's not a "framework" and that the CSS itself is very simple and straight-forward to build upon: https://github.com/ThisIsDallas/Simple-Grid/blob/master/simp...

Deleted comment

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)?

Looks really nice. A nice base to built up from. Out of interest - what is the level of browser support? For example IE6/7/8?

Hey thanks! Right now, it works in IE8 and up.

Not to be a stickler, but you're missing a few semicolons and a bracket at the end in the download.

Cool! There are a lot of times I'm building a quick and dirty site and this will be really helpful

It is not responsive down to the images, so nothing much of use now.

Seriously? This is so trivial to add in your media query yourself.

img { max-height: 100%; max-width: 100%; min-width: 400px; min-height: 300px; }

http://jsfiddle.net/N8GKd/ -- resize the window.

Imgur doesn't like the deeplinking, so click this link first:

http://i.imgur.com/kyOq3.jpg

and then the jsfiddle link provided by fourstar.

Ah, weird. Thanks.

Thanks for posting, this is great, simple CSS grid.

Just what I've been looking for. Love it. Thanks.

Thanks! This looks great.

Reply on news.ycombinator.com