▲ 82 points
Ultra minimal CSS grid utility
brajeshwar.github.comGrid is a simple and minimal fluid grid system that can flow inside any fluid or fixed container or co-exist nicely with any other heavyweight grid system.
back
28 comments
Am I the only one that doesn't understand everyone's obsession with CSS grids?
I mean, I understand why grids are an important part of design, don't get me wrong. I use grids and I try to adhere to a baseline, but I don't actually formalize this into my markup. I keep that formatting strictly in the CSS.
If you're going to use a CSS grid, this formatting spills over into your HTML via those dorky ambiguous classnames that really remind me of Dreamweaver.
I'm sure this "grid.css" is great, really concise, etc. But do we really need to be using it? I like to type out comments on HN and never hit "add comment," today I will.
"Am I the only one that doesn't understand everyone's obsession with CSS grids"
I saw a great talk by Nicole Sullivan on CSS last week. She said that many sites lack a meaningful high-level abstraction for their visual layout, and end up with a tangled mess of float, padding & margin declarations on every element. This complexity, she said, is more clearly and concisely handled at a higher, site-wide level and suggested using a grid.
I've wasted an insane amount of time pushing one element four pixels this way and another element three pixels that way, so I'm definitely eager to try a grid on my next project.
Links to her slides (with some other great info) and her grid framework:
http://www.slideshare.net/stubbornella/our-best-practices-ar... https://github.com/stubbornella/oocss/blob/master/core/grid/...
I think a high level abstraction with semantic meaning is important. If you want to include the layout styles in that abstraction, that's one thing. But if you want a simplified way to set the layout without building the grid system yourself, what choice do you have besides including layout-only classes on your html elements?
So I agree with Breefield that it's not optimal to have separate class definitions outside of your high level semantic abstraction for the sole purpose of layout. But I don't know of any other way to do it other than just building the grid into your abstraction, which means you can't reuse existing css layout systems (unless you just copy the code... ick...).
I can't speak for all the options, but Blueprint has for quite some time now had a "semantic" option where a Ruby script generates the appropriate CSS based on your input.
Using that you can still think of things in a logical grid format rather than pure CSS (i.e. 3 columns wide, rather than 80px), but keep your HTML clean.
See the "semantic_classes" option: http://joshuaclayton.me/blueprints_compress_a_walkthrough.ht...
Not to mention if you use Compass you can do the same thing with their Blueprint mixins: http://compass-style.org/reference/blueprint/grid/
Or if you use Less: https://github.com/omnifroodle/blueprint.less
I was just searching for the sass/scss version of Blueprint. Is there one available? I don't want to use Compass just for Blueprint. Compass is almost broken with rails 3.1 and there's a lot of confusion.
it's the typical developer response, that all concepts, no matter how abstract, should be captured in Code.
In saying that, it's easier to shove a bunch of classes into your html, and that's kind of what the multipurpose class tag is for. As to whether the binding should be done via css selectors or via html classes... well, I think the appropriate phrase is "6 of one, half a dozen of the other".
I've done most things both ways at some stage or another, and the maintenance is the same, the complexity is the same, and there's an advantage to having a label directly on the html node, that tells you what the hell is being applied to it.
I totally agree.
Grid systems are great, but not in the way they're being used today - with lots presentational of classes and ids in the markup.
Are we going back to the days of tables for layout? Look, classes like span-x, grid-y, append-x describe only the presentation of the content. I thought HTML was meant to describe structure, not layout.
Grid systems are destroying the semantic web.
EDIT:
Other classes-littered systems aren't any better (OOCSS, I'm looking at you).
I haven't had much utility for it, but I did just realize a useful feature of grids.
I found that you can select (and therefore copy) all text in a paragraph in one grid, while keeping the text in another paragraph unselected. While this doesn't have any immediately obvious uses to me, there is still some merit.
Screenshot: http://i.imgur.com/uycBt.png
"If you're going to use a CSS grid, this formatting spills over into your HTML via those dorky ambiguous classnames that really remind me of Dreamweaver."
Not if you're using Compass with its mixins: http://compass-style.org/examples/blueprint/grid/two_cols/
I use Compass/SASS with the 960gs grid system, allowing me to create purely semantic HTML while the layout remains in CSS. Using a grid system doesn't necessarily pollute your content.
I think people should remember why they use grids in the first place and not just jump on the grid bandwagon, just because that's in vogue.
I love using a grid, but it serves a purpose for me, and I do it all in the CSS without creating a dozen of "clearfix" and "column1" classes and whatnot.
Grids are great at building structure with a minimal amount of CSS. Especially when you use a recursive grid system. It just makes sense when you are trying to make small performant website.
a couple of reasons I think we see so many
1) the development time / potential number of users ratio is attractive for a developer (easy 100+ watchers on github etc) 2) many people have built their own grid system over the years and feel like sharing them, documenting it and putting it on github isn't hard.
I don't see the use either. I don't need crutches for something as basic as lay-out. DRY is fine, but not if YAGNI.
As far as I know, there's some holy war against <table>s going on, so people rather write tons of obscure CSS code, which becomes instantly impossible to understand the moment you write it and probably renders 10 times as slow in any browser, than to just use tables.
I had to do a double take on your comment because that holy war ended a very long time ago and with very good reasons.
Here's a pretty good summary: http://stackoverflow.com/questions/83073/why-not-use-tables-...
The responses that use valid arguments (i.e. not "it will harm your professional reputation to use tables! or tables are for tabular data! or I can bill more hours if I use CSS!") pretty much agree that the arguments against tables don't hold much water.
The only argument that might be important against tables that I could see is that they work less well with screenreaders. Can anyone using a screen reader confirm or deny this? I could easily see it being the other way around, because with tables a screen reader will let you quickly navigate to different parts of the page (e.g. sidebar to header to main content by going left, right, up and down instead of painstakingly navigating over a bunch of text).
On the other hand, tables are easier to use, more flexible, more predictable across browsers, and more readable. Just look at the years and years of research it took the CSS experts at e.g. Alistapart to replicate layouts that are trivial with tables using CSS.
Examples:
http://www.alistapart.com/articles/fauxcolumns/
http://www.alistapart.com/articles/fauxabsolutepositioning/
http://www.alistapart.com/articles/multicolumnlayouts/
http://www.alistapart.com/articles/negativemargins/
And even then it doesn't always work: http://www.satzansatz.de/cssd/hgjump.html
Note that these layouts are utterly trivial to create with tables.
They also don't work very well if you're trying to build a site that looks decent on a mobile browser... You can do some cool CSS tricks to facilitate different screen sizes. See http://cssgrid.net/ for an example (resize your browser window and see how things change)
I think of tables as a shortcut and they do cause actual problems in the future even if they work for you. I think the bigger issue here is that it isn't clear to everyone how to code with CSS. I use tables only for tabular data but my HTML is clean, fast and certainly not obscure. I would say in most cases I can create an tableless design in less lines of code and have a much easier time maintaining or updating it in the future.
This still suffers from the rounding error seen here [http://i.imgur.com/DXjVN.png].
Otherwise, yup... it's a grid. Looks like they're setting the grid elements to display:inline... which seems weird and unnecessary to me? Block elements don't belong inside inline elements.
I hate to keep posting this, but I've been unable to find fault with this grid [https://github.com/stubbornella/oocss/blob/master/core/grid/...] code. .lastUnit spans the pixel gap on the rightmost, nestable, extendable, fluid widths.
The two are mostly the same idea, but I think the OOCSS project implements it better and works with more browsers.
IE6 has a double-margin bug on floated elements which is fixed by display: inline;
http://www.positioniseverything.net/explorer/doubled-margin....
CSS defines style, HTML defines the semantics. The semantics of a div or an h1 don't change if you declare them inline in your CSS. So there is nothing wrong putting inline elements (styled as block) inside block elements.
HTML5 blurs this further as you can now wrap pretty much anything with <a>.
This Framework is mix of my Malo CSS Framework(2008) http://code.google.com/p/malo/ & https://github.com/stubbornella/oocss/blob/master/core/grid/... naming system is used.
I'm to blame about display:inline in Malo that is actually wrong it should be *display:inline or even better _display:inline to resolve the double margin problem in IE6.
The posted grid system is broken in some versions of IE, Opera, and other browsers I'm sure but I don't remember which other ones suffer rounding errors offhand.
It amazes me how, with so many existing grids that do it right, someone can write one that's wrong. Or would bother to in the first place.
I agree with huckfinnaafb - OOCSS is better implemented if you want a simple grid
One thing I would note, if you use "box-sizing: border-box" you can include borders (transparent if you want gutters) and padding without any float drops.
I wrote up an example here: http://monkeyandcrow.com/blog/splitting_the_difference/
Seriously, lets take a step back and ask our selves do we need another CSS grids. As far as I can tell there are like 3 methods to grids.
Blueprint type grids(http://www.blueprintcss.org/), OOCSS/YUI2 (https://github.com/stubbornella/oocss/wiki), and YUI3 (http://developer.yahoo.com/yui/3/cssgrids/).
Why create new grids, lets make the old ones better, or explore new uses for them. Like many on this post I can't imagine there are very many good ways to go about this.
This is pretty nice but it's still using floats. Check out http://stacklayout.com/ for an example achieving a practically identical result using display:inline-block
We're getting one step closer to tables again. One day people will realize that all the extra effort in doing this in CSS is worthless and just use tables. Who cares that your layout is made with tables instead of divs? Mixing presentation with content? We already have a much better solution for that, it's called server side templates. Just use what requires the least amount of work, for some things that will be CSS for other things that will be tables. Don't get hung up in cargo cult design.