Beautiful sunny afternoon here on Seattle!
Mmm taco del mar!
Seattle Children’s Hospital is looking for a web developer. Interested in moving up our way? Check it out! Visit site »
Really nice graphic tees here. Use my discount code, J2SB8Y, for 15% off your oder. Thanks, Garrett. Visit site »
Happy birthday, @simmy!
Heading into the office, finally.
.net magazine’s podcast, hosted by Paul Boag, has responded to my article on the Blue Flavor blog about Blueprint CSS. They say:
This week the guys over at Blue Favor have published an article extolling the virtues of Blueprint. Although their arguments of improved productivity are compelling Blueprint is not without its limitations. The grid system only work on fixed width sites and the nature of frameworks means it creates a lot of redundant code and un semantic markup. Despite the claims of the Blue Favor article, Blueprint seems to be more suited to rapid prototyping than final site production.
Some of this is valid criticism, and some of it isn’t. It’s true that Blueprint is currently for fixed-with sites only — it deals in pixels (for layout), and not ems (although it does use ems for typography). I believe it’s inaccurate to say that it results in un-semantic markup. It uses some visual class names, but that’s entirely different than being un-semantic. Un-semantic would mean using presentational elements such as b, i, u, or table (for layout). Blueprint isn't un-semantic. It just uses class names that don't add semantic value (but they also don’t take away semantic value).
Paul concludes that he would use Blueprint for rapid prototyping of layouts, but probably not for production sites. Basically, it seems that Paul, and some other people (who all seem to be Brits — weird!) consider HTML and CSS production to be a very delicate craft and they’d rather hand-do everything. I can respect that, but it’s not for me. HTML and CSS isn’t my craft — design is. I imagine there was a day when serious carpenters were really upset at the advent of power tools, too. Oh well.
I also think Paul ignores one of the biggest advantages of Blueprint (maybe because it doesn’t apply to him, in his work?): the way it helps teams of designers work together. If you’re a solo front-end developer, it may not be that useful. If you’re a team and you have t work on other people’s code a lot, having a consistent system (be it Blueprint or anything else) is a huge help.
Blueprint definitely isn’t for everyone, and Paul ultimately decided it wasn’t for him. That’s fine. I’m glad he checked it out and gave it a go. You should, too. Visit site »
Shit. Overslept.
Beth has a very nice blog post on the importance of formal education for web designers. Her conclusion, which I completely agree with, is that college education probably isn’t necessary, but some sort of training — even self-training — on traditional design principles is still sorely lacking in a lot of the corners of the web. Visit site »
A very complete-looking web development framework. Too bad it’s based on PHP. Other than, it’s perfect.
(Yes, this is a joke.) Visit site »
Is frustrated and hungry.