Skip to main content

Web: 960 Grid System

I just watched the video for 960 Grid System. What a weird idea: constrain the page to 960 pixels and cut it up into 12 columns. When laying out your page, each piece fits into one or more contiguous columns. It might make more sense if you look at their examples.

Naturally, I knew about YUI Grid, but for some reason, watching the video for 960 Grid System helped me envision how I might actually use it. I've never really been good at super complicated layouts without using tables, but this seems easy enough to use. There's even a version of the CSS that isn't limited to 960 pixels.

Anyway, I'm not saying I'm going to convert all my sites, but I do think it's weird that somehow constraining yourself to fixed numbers like 960 pixels and 12 columns leads to greater flexbiliity. Since I'm a fan of haiku, that kind of makes sense to me.

Comments said…
If you're getting into grids Blueprint is worth a look too. It's a grid system plus some typography and form styling and it comes with some nice command line tools to store customizations and generate customized versions of the base framework...
jjinux said…
Thanks, Simeon.
Anonymous said…
I like the idea of using grids for layout, which actually long predates the web, originating from the days of hand typesetting. However, while the CSS grid frameworks probably make it a little faster to do the initial layout, I don't like that they depend strongly on mixing the presentation into the HTML.

So, instead of the normal approach of adding semantic classes like "menu-bar" to the elements and styling that class from CSS, your presentation must be specified with classes like "columns-2". That said, it probably does make it a bit quicker to build new layouts, though changes to the layout may require changing more HTML files than a purely CSS-based layout.

What we really need is another layer of abstraction, so that I can say class "menu-bar" should span 2 columns, where columns are defined as .... Stuff like the CSS3 Template Layout are looking kind of interesting, though a meta-CSS language or some crazy Genshi transforms to inject column definitions would be another interesting way to abstract the layout from the HTML.

Interestingly, one of the original authors of Blueprint CSS now dislikes its un-semantic nature and has written a simpler set of CSS stylesheets that are more a "starter-kit" than framework:
jjinux said…
Thanks, Matt.
jjinux said…
I was looking at, and I was thinking to myself, "Wow, that looks just like a 960 Grid System layout." It turns out, I was right ;)
jjinux said…
I just looked through css-boilerplate. It does as it promises. It fixes some CSS stuff, but without any builtin grid stuff. I don't see much documentation, however, it looks pretty simple. It resets everything and provides its own default stying.
jjinux said…
Blueprint provides:

* A CSS reset that eliminates the discrepancies across browsers.
* A solid grid that can support the most complex of layouts.
* Typography based on expert principles that predate the web.
* Form styles for great looking user interfaces.
* Print styles for making any webpage ready for paper.
* Plugins for buttons, tabs and sprites.
* Tools, editors, and templates for every step in your workflow.

The web page looks nice, and it looks like they're working on a real community.

I'm not sure I buy the idea that HTML should be 100% semantic and contain no layout. I think that's a laudable goal. However, we still have br tags. We still have div vs. span tags. The order of elements still matters. There are lots of little hints about layout built into the HTML. If you have an HTML page with 5 divs, it's hard to show them in a random order without using absolute positioning.

I think the point of CSS is to keep the HTML as clean as possible. If you strip away the CSS, you should get a plain looking, but functional page.

I agree that using things like class="span-7 colborder" isn't 100% ideal. However, the logic is in a class attribute. It's not permeating the HTML structure itself, like using a table-based layout does.

Using a class in this way doesn't seem very different from my other post in which I showed how FriendFeed completely decides which JavaScript event handlers to hook up based on the class. I.e. class="l_expandcomments".

Hence, the purpose of the class attribute is to loosely couple the HTML with the CSS and JavaScript. I guess it's a matter of taste whether something like "span-7" is coupling too tightly. The 7 does signify something about the width. However, it doesn't specify actual pixel values.
jjinux said…
960 Grid System appears to focus entirely on providing a grid system. It's interesting to note what the tutorial says at the end:

"Now that the prototype is finished,to take stock what has been done. You've manage to quickly prototype a design. Grid 960 easily created the grid for us. Where do to go from here? Naturally we would show the client and see what they think. There are a few caveats though. Have you tested this design in IE6 or IE7? No. Should we? No. This is a prototype. This is what it would look like in production. It is natural that any browser quirks would be worked out before production. What if the clients wants to create a more complex design? In this case, you will quickly start to see the limits of the framework. What if the design needs to be liquid or elastic? The framework will no do that. You would need to start from scratch. Remember that CSS Frameworks do not solve all your problems, but they do help with some. Grid 960 as well as others are great for throwing together prototypes. You can just as well use the concepts of Grid 960 in the production code, but it is not recommend sticking with a framework all the way through production. CSS frameworks are just like any tool, they have their uses. With that in mind, go forth and prototype!"
jjinux said…
It's interesting to note that Blueprint uses 23 columns, and 960 System Grid has a nicer looking web page ;) Aside from those two things, I think I like Blueprint more because it provides a bit more. Of course, what the heck do I know?

Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p