Again from Jeremy’s great live blogging of An Event Apart San Francisco, here’s Eric on CSS frameworks. I’m glad to see someone else broaching this topic, and in general it looks like Eric did a great job of rounding ‘em up. A few bits and responses:
If you’re going to use a framework, it should be yours; one that you’ve created. You can look at existing frameworks for ideas and hack at it. But the professionals in this room are not well served by picking up a framework and using it as-is.
Generally speaking, I agree. I have made great use of Blueprint — but it’s worth nothing that almost all of the basic concepts were created by me (along with Nathan and Christian). As Blueprint has progressed, it’s gotten farther and farther away from what we created, and I’ve been less enthralled by it. The point is: something you created yourself is always going to be more useful to you than something you didn’t.
Four of them use psuedo-namespaced class names beginning with grid- or container- or span- (which you would apply to a div!?).
I’m not sure if the parenthetical is Jeremy or Eric speaking, but this is also worth noting: in the original CSS framework Nathan, Christian, and I created, you were not necessarily supposed to apply those classes to a div. The classes were for any element, and there was no encouragement to liter your markup with extraneous div elements. The original Blueprint retained this philosophy, but later changed it, asking people to always use div elements as columns. I find this to be incredibly wrong, and I always override this Blueprint functionality when I use the framework. If you are going to use a div for every layout column/row/unit/whatever, you may as well just use tables. I hope everyone knows and understands that when I was touting Blueprint, it was before the made the boneheaded decision to require the use of a div element for every column. Visit site »
I’ll be damned if it doesn’t seem like this whole Django 1.0 thing might actually happen. Be sure to read the release notes — there are several backwards incompatible changes (which are annoying, but it’s way better to get them out of the way before 1.0 than after it). Visit site »
GeoDjango is so far over my head that it doesn’t meant much to be, but I hear it’s awesome news, so I figured I’d link it up. :) Visit site »
I found this great writeup of Django’s signals on Twitter today. Signals are an incredibly useful tool in Django, and one that is way under-utilized. I used them a lot back when I wrote the second version of lost-theories.com, and I use them a little bit in the Savoy content publishing framework I’ve written at Blue Flavor. I especially make great use of the pre and post save, and pre and post delete signals. Check ‘em out. Visit site »
Yet another front-end web framework, consisting largely of CSS (but this one also has some JavaScript). I haven’t really looked into it yet, so I can’t really comment on it.
For my tastes, I’ve yet to see the “perfect CSS framework,” (Blueprint’s first release was the closest — since then, it’s moved away from many of my preferences), but I’m really happy to see the concept taking off, since I wrote about it in A List Apart. Despite some negativity from other prominent members of the web standards community, I still really believe in the ideas of code re-use and standardization amongst teams on things like class names and markup conventions.
It still baffles me that some of the same people who go on and on about microformats don’t want to see standardization in class name for other things. Weird. Visit site »
I’m not entirely convinced that Django’s recent popularity has much to do with web standards, nor am I that convinced that Django is “winning” in our community over Rails or other modern frameworks — but, it’s true that Django allows those of us who value web standards to do our thing quite easily, and it’s good to hear that people are noticing that. Visit site »
Nathan Smith talks about the 960 Grid System CSS “framework” (I say in quotes, since that word seems divisive when applied to CSS) he recently released. It all looks very impressive to me, and I’m quite tempted to use it over Blueprint. Blueprint has changed several things since the work Nathan, Christian, and I did at the Lawrence Journal-World, and much of it is not necessarily to my liking (that’s not to say it’s bad — just not now I want it). Nathan’s 960 is a bit closer to what I want, grid-wise (and is a bit lighter weight, as it doesn’t really bother with typography). I’ll definitely be giving it a closer look in the near future. Visit site »
The awesome Nathan Smith has released a CSS framework for grids. It’s very similar to Blueprint, but uses some different naming conventions and a 12 or 16 column default grid, instead of Blueprint’s 24 columns. Looks very useful. Nice work! Visit site »
Awesome news. The more Django books, the better. Congrats, Paul! Visit site »
Having played with a friend’s (mt) Django setup, I can say that it’s definitely well done. Neat, clean setup that works well. Personally, I’m sticking with [WebFaction(http://www.webfaction.com/?affiliate=jcroft) — they’ve always been great to me and I simply have no reason to switch. But, it’s great to see another reputable name in hosting jumping on the Django bandwagon. Welcome to the party, (mt)! Visit site »
Have to agree with James’ response to Twitter developer Alex Payne’s Shared Hosting is a Ghetto. Visit site »
Tons of new stuff in the latest release of YUI. I’m particularly stoked about CSS selectors. Awesome. Can’t wait to play with it. Visit site »
Webfaction, my favorite Django host, has drastically improved its plans (and redesigned its website). They now offer unlimited websites, domains, e-mails, databases, and applications on all plans — plus, they’ve increased the amount of bandwidth, RAM, and disk space each plan gets.
Besides being great at Django, WebFaction also does Rails, TurboGears, and several other modern development environments.
Booyah! Go getcha some WebFaction! Visit site »
Jonathan has a nice follow-up to the CSS framework discussion here. At one point, he says:
It seems for many of the arguments either for or against CSS frameworks have a related counter-argument, which could be the reason this debate has been circular for so long.
Indeed. What it boils down to is that the decision whether or not to use a CSS framework (or whatever you want to call it) is a personal one. Therefore, it’s probably a bad idea for anyone to say definitively, “you should/shouldn’t be using CSS frameworks.” It’s roughly the same as saying, “you should/shouldn’t be using Fireworks instead of Photoshop” or “you should/shouldn’t be using the CSS shorthand properties (i.e. background instead of background-image and background-repeat).
They’re all just tools, and which one someone choose to use or not use is just personal preference. We should all probably just let people have their preferences in piece. Visit site »
Nathan Borror (my friend and former colleague, who happens to be one of the best designers I’ve ever worked with) has released Boilerplate, a new CSS framework. He says, “I’ve started this. It’s a work in progress. I will explain later.” He also says:
A simple CSS framework that reduces redundant boilerplate code, imposing as little semantic suggestion as possible.
As initial author of Blueprint CSS I’ve taken a lot of my original code and some of the current iterations of Blueprint to form a stripped down simple framework that provides the necessary CSS essentials. There is very little semantic suggestion which allows you to craft good semantic markup.
Boilerplate does not include a grids component, from what I can tell (the grids piece of Blueprint is arguably the most useful piece, and certainly the most controversial and divisive).
Looks like a terrific start towards a framework for those who are concerned about Blueprint’s visual class names. Visit site »
In which I point to James Bennett’s terrific article on what frameworks are (and how they compare to “libraries” and “snippets”), and why people who are really good at building things with code tend to create, use, and publish them.
A really useful tool for anyone who finds “making Jeremy Keith feel warm and fuzzy inside” on their web site’s priority list. By Christian Montoya. Visit site »
In which I attempt to distill what we’ve learned from the comments on my last post.
In which I publicly ask the (mostly-British) cabal of folks who seem to despise the idea of CSS frameworks what it is that offends them so.