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