.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.
001 // Stephen Van Dahm // 11.16.2007 // 4:06 PM
I’m a programmer and not a designer, so I might be missing something very basic. That said, I think it sucks that Blueprint takes the blame for problems that wouldn’t exist if CSS weren’t so limited. All of the controversy surrounding Blueprint would go away if designers could just do something like this:
But you can’t, so you’re left with something like:
Blueprint provides language to describe grid-oriented page layout, and it seems very natural that it should exist, since designers are starting to think that way. I don’t like the clutter that the Blueprint classes add to the HTML markup, but given that HTML and CSS are what they are, there’s nowhere else to put them, and it seems really backward to throw away such a useful tool.
002 // Jeff Croft // 11.16.2007 // 4:17 PM
I agree completely. Blueprint basically just takes care of things that should be in CSS, but aren’t. Some of them are in CSS3, though, so in 2018, when CSS3 is implemented in all browsers, the need for Blueprint may go away.
003 // Keith // 11.16.2007 // 5:09 PM
I’ve got no real opinion on BlueprintCSS whatsoever, as I’ve never used it.
However, I have looked into it and I worry a bit that this .net article (and others like it) might be mixing opinion with what they claim to be fact. Semantic markup is, to a certain degree any way, subjective. And there isn’t anything wrong (standards-wise anyway) with fixed width design. AND as you say, there isn’t really any redundant code, only potentially unused code, which…meh, who cares, every framework has some of that.
From what I can tell, it’s perfectly fine for final site production, as long as you know what you’re getting into. I’m sure for some things it’s no good, but for others it’s probably fine.
I’m not pro- or anti-Blueprint, for the record, it’s just a tool. I’m just pointing out that .net isn’t really painting the full picture here.
004 // Kev Mears // 11.17.2007 // 6:07 PM
I’ve just come back from a workshop in Leicester, in the UK, where another brit, Andy Clarke, agreed with the proposition that CSS frameworks are not to be used on live sites. I am unsure where I stand at the moment.
I agree with Keith, that the semantics are subjective.
In my team we are keen to use frameworks to speed up our CSS tooling to hopefully, raise our game on the design side. We just have to decide how much of the framework to tailor to our specific prejudices and requirements. At the moment Django and Rails make it possible for our developers to create sites faster than we can style them, so any tools to help with that are welcome.
005 // Jeff Croft // 11.17.2007 // 6:14 PM
Man, I sure wish these guys would come out and say why they are so aganist the idea of CS frameworks. Many of these guys are really into JavaScript frameworks and backend frameworks (Rails/Django/Cake/whatever), so it completely baffles me how they can see the benefit there, but not with CSS.
I feel a blog post coming on.
006 // GoossyBeags // 12.27.2008 // 9:20 PM
Complimenti per idea del sito. Anche noi siamo amanti del trekking. Perche non organizziamo un incontro di appassionati per delle escursioni insieme? Magari non piu di 6-8 in tutto? Un saluto. eskimotube car game immagine dragon ball frasi d a