Great find Mark!! I’ve started to play with the excellent Code Igniter, and I can see that a CSS framework would help speed up development time even further! Will be downloading this ASAP!!

Thanks for bringing this to my attention, Mark! It is just what I need. I’ve already read most of the articles that the framework is based on, and have started using Eric Meyer’s browser reset. To have it all in one place is just fantastic.

Now, I just need another new client with a project to test it out on… ;)

Like Peter, I’ve already read most of the articles this is based on, and it looks really good.  Unlike Peter, I have a big project to test it out on. 

However, “Blueprint has not yet been tested in every browser. Please do not use this framework in any projects of grave importance at this time.” - I’m currently weighing up whether the amount of grief I might encounter due to this, will be less than the amount of grief I would encounter due to not using it and, ultimately, having to reinvent the same wheels myself.

I suspect it’s worth it but will that help me if the whole thing falls apart and my boss points at that disclaimer and asks WTF I was thinking...!

PS.  There’s no † symbol next to the email field, but it won’t let me submit the comment without it?

I know IE7 has support for resizing px values, but is it already being recomended we switch back from em?

Brilliant I’ll give this a go, I recently developed my own framework but due to lack of time I’ve not been able to get it working quite as well as it should do.

The sample website that they have for Blueprint doesn’t display correctly in IE 6.0. The right sidebar displays underneath the main content.

I keep seeing people state that the Yahoo framework is huge and bloated which is very misleading. The YUI CSS “framework”, which includes Browser Reset, Basic Typography, and Grids, weighs in at about 5.1KB unzipped. With gzip compression and caching you’re looking at under 2KB. Now, granted, the Yahoo “framework” might not be as extensive in terms of grid possibilities, or as refined in terms of typography, but it still provides a very good starting point for 5.1KB.

But isn’t there something to be said about customizing your code relative to your website?  I mean everyone keeps talking about reducing bloat, but if a framework claims to be applicable to all your sites - albeit as a starting point - isn’t it bound to be bloated?

Wouldn’t it make more sense to name selectors according to the specific elements to which they refer within the context of their website?  Like class="album-section” rather than something contextually meaningless like class="column span-2”? 

I guess that doesn’t accord with “Web Patterns”, but somehow it appeals to me.  I could of course go in and rename everything, but then what’s the point in using the framework?

I’ve been considering the same point as ZenBug. While I see the value of a css framework, it certainly contributes to class bloat and has no regard in terms of semantics. I realize an id could take care of the latter point but the former still remains unsolved for me.

With that said, I still like the progress.

I could of course go in and rename everything, but then what’s the point in using the framework?

Personally, I don’t see a problem with this. I have my own basic framework that has taken a lot of time to build. Renaming a mature framework would save loads of time.

As a fellow norwegian to mr. Bjørkøy, I must say this is a great piece of work. But I’m also a bit skeptical about using such generic layout specific class names. It will make it a lot easier to do prototypes and play around with layouts though.

I also don’t quite agree with using pixels for line-heights. Font size is okay, though you might want to specify it in percentages or ems for IE6.

"Let’s see if Markey likes it....” “He won’t like it he hates everything...” Hey look at Markey…
He Likes IT!
Save some for us Markey!

Just because Richard’s a fellow Brit, doesn’t mean he invented vertical rhythm - that’s my woefully inadequate pixel-based method listed in the credits! ;)

Kidding aside, it’s really excellent to see this level of interest and activity around making the basics of systematic design that much easier for everyone to implement on the Web. Just like with any framework, it’s always a balance between flexibility and “magic”, but the great thing about a CSS framework like this is that once you’ve got the building blocks it’s easy to go off on your own or rework everything from the base up.

Plus, it seems like projects like this will make great learning tools for new and intermediate web designers to build on what they already know without being overwhelmed by all the messy intricacies and browser edge cases.

Hehe, no worries. Richard’s devotion to dragging good typesetting kicking and screaming onto the web has been stronger longer and more fruitful than mine.

Agreed about the value of the documentation. Having written and tried to documenta few of these myself I know that the second part usually falls by the way. It’s nice to see some of the hard work that goes into those internal projects get some loving care to turn them into resources for the community.

I submit this to your attention:
http://www.rightclick.ro/archives/launch-of-stylus-css-framework-v01
It’s also a CSS framework, you will find it more approachable & more accessible.
Thank you.

didn’t yui’s reset css came first before blueprint?

There is one thing that scares me from viewing css. Stuff people knew/know but didn’t publicly document> the seemingly obvious > yui reset > eric’s reset (+ user comments) > blueprint > ?
How far should attribution go? if people contribute to Blueprint is file size going to increase? attribution’s not a bad thing but there should be a better way?

Separation of content and presentation is totally violated by this method.

Semantics! Semantics! Semantics!

This is obviously a carefully crafted piece of work but why oh why does everyones long proffered ideals about the importance of semantic markup go instantly out of the windowwhen someone comes up with a way of making the task of creating a website that little bit easier?

I know I’m just echoing points made above but I feel this is really important. Creating markup in this fashion is no different from the comedy example given in a previous post on 456bereastreet (sorry can’t find it now) where the html structure was a whole bunch of divs, outermost with the class ‘table’, then class ‘tr’, ‘td’ etc. etc.

class="column-span-8"? aaarrrggghhhhh! help me!

I’m fairly sure that the idea whole concept of a css framework is mutually incompatible with the ideal of well crafted, semantically descriptive HTML. Don’t get me wrong - this may be a valuable learning tool but I’m not sure it has much of a place in the everyday toolbox of professional web designers.

Dreamweaver’s WYSIWYG editor makes it pretty quick to create webpages too, but 99% of true professionals would never use it - in part because of the non-semantic vomit that it turns out as an excuse for code.

People should look at the ideas behind projects like this - vertical rhythm, typography etc and learn how to do it themselves - not just shortcut the process by sticking a load of someone else’s code into their projects. Teach a man to fish and all that!

<blocquote>I’m fairly sure that the idea whole concept of a css framework is mutually incompatible with the ideal of well crafted, semantically descriptive HTML.</blockquote>I don’t think I agree. The HTML used by a site built on blueprint is going to be the same as the HTML used on a site where the CSS has been lovingly crafted by hand - you’ll still have the same divs nested in the same way. All that differs is what goes in the class attribute.

What you end up doing then is something like this:

div class="column first span-3 sidebar”

div class="column span-2 navigation”

You don’t lose any semantics, but you gain improved maintainability of the code.

Semantic and structural classes are not an either-or proposition: you can have both.

I see what you are saying Simon - that all we have to do is use this (blueprint) and then superimpose semantic class names over the top, but doesn’t it still bother you? Don’t we try to avoid using classnames like ‘bluetext’ in case one day it needs to be changed to pink? ‘column’, ‘span-2’ and the like just seem a little too close to presentational descriptions to sit easily with me. And I’m not convinced that having essentially presentational terms like these in my markup makes a site any more maintainable.

Semantic and structural classes are not an either-or proposition: you can have both.

Of course! But to me a true semantic, structural class is one whose name describes the content of the element that it is applied to, whilst it’s rules determine the styling and position (the structure) of that element.

To be honest it does bother me - but what bothers me more is how incredibly difficult it is to writemaintainable CSS that can be updated and managed by a team of people. I’m convinced that true separation of content and presentation using CSS is a myth - outside of academic exercises like the Zen garden it simply doesn’t work, and you always end up needing to update your HTML in line with your CSS. Dynamic generation of HTML using server-side templates is a much more effective way of solving that problem.

If we’re dynamically generating our HTML, the question boils down to what we can do to make our client-side code maintainable, accessible and effective across multiple devices. Structural class names appear to cover all three bases, so it’s hard to come up with a good argument against them other than “they make me feel uncomfortable”. You can still use the semantic classes as well - interestingly, the Microformats community have been advocating the fact that you can add microformat classes to existing classes and markup for years.

The fact that we are having this discussion at all illustrates a fundamental problem with CSS. If CSS had some kind of macro system the solution would be obvious:

div class="nav"

cssmacro(’nav’, ‘column span-3 prepend-1 first’)

But in the absense of such a thing, adding structural classes directly to our markup appears to be the best alternative.

I suppose it is just the purist in me speaking, and I can see the application of something along these lines in bigger, dynamically generated, multi-person edited environments, as you describe.

But smaller projects? Smaller sites with just one or two people working on them? I would urge people in that situation to not just pick up a framework as an alternative to gaining the knowledge and skills to create layouts like this themselves. For sites like these the end result will be more concisely semantic markup and an advance in personal ability of the person coding them.

Any frameworks of any kind, css, javascript, php or otherwise are best and most effectively employed from a position of knowledge rather than to fill the gaps in a person’s knowledge.

That’s something I agree with entirely: a CSS framework is no replacement for knowing CSS, in the same way that a JavaScriptor PHP framework is no replacement for knowing the nuts and bolts of those languages. Unfortunately there’s no way to introduce a tool for experts without less experienced users using it out too, but I don’t see that as a reason to avoid expert level tools altogether.

I agree with Simon on the points above. Life’s a trade-off, and there’s some really great benefits available here which can’t be ignored.

If we’re concerned about the separation of content and presentation (which I have to admit, part of me is), it occurs to me that we could literally combine the ‘separation principle’ approach and the usefulness of a CSS grid framework with something like

div id="nav" class="column span-3”

div id="main" class="column span-5”

etc.

That way, we have both semantic meaning (in the id) and the less-semantic grid information as well. You could apply certain key styles to #nav and #main, and leave the grid layout stuff cleanly to the framework. In a hypothetical site, removing the grid classes would leave a perfectly acceptable, designed and branded but grid-free, linearised layout. Separation is still there. Sort of.

It’s a bit like Jeremy Keith’s idea of ‘plugging the holes in CSS’, in his case using JS. In this situation, until something like the cssmacro features that Simon mentions arrives (which won’t be soon), using classes in this way might be a pragmatic way to fill in the gaps.

It might feel better to have a quick way to isolate or search and replace your framework classes, so that they truly worked like add-ins to the semantic HTML rather than intrinsic parts of it. Hmmm.

Mark (Perkins), if you study the code closely it doesn’t use class="column-span-8", it uses multiple classes and as Simon said you can still keep it semantically correct, so it’s not really anything like “divititis” - like you’ve mentioned.

Using those class names doesn’t make semantically correct HTML any less semantic, or am I missing something?

It might feel better to have a quick way to isolate or search and replace your framework classes, so that they truly worked like add-ins to the semantic HTML rather than intrinsic parts of it.

I’ve been thinking the same thing. One of the best arguments against structural class names (one which I haven’t seen anyone raise yet, surprisingly) is that they break down if you try to serve up media stylesheets - for mobile devices for example.

One way of solving that would be to include a prefix on the structural classes that reflects which media type they are relevant to:

div class="navigation screen-span-3 screen-prepend-1 mobile-span-2”

Then the CSS file for the screen media type would define the screen-* classes, and use them to lay out the page for screen viewing. A separate mobile CSS file could target the mobile-* classes.

It’s a bit verbose, but it seems to tackle the screen/mobile problem. Personally I prefer the idea of serving up a mobile-specific site from the same backend content though, since the needs of mobile users differ from regular users in more than just presentation.

I think I am batting for the wrong team on this one! ;-)

In my eyes being semantically ‘correct’ has to some degree also to do with being semantically concise. If you drown your markup in classnames with one poor semantic one orphaned somewhere in the list then I am not sure that is ‘semantic’ in the true sense of the word.

But I think one of my main issues was the presentational smell that the class names inevitably gave off.

I really wasn’t trying to writeoff Blueprint altogether - merely suggest that we have to be careful that frameworks like this don’t undo the hard work done by the standardistas in getting people to understand and apply the concept of markup that describes the content and not the presentation.

Of course you can add in more classnames to a blueprint-ed site to give them more meaning, but I would say that it is highly likely that a lot of the people who download it and use it would not even think of doing that, and instead construct their markup using only the non-semantically descriptive blueprint terms.

I guess all I really wanted to do was issue a warning that frameworks like this should be used with caution, and that we are careful not to let the standard of our markup slip by blindly using powerful tools without pause for reflection.

I’ve found that frameworks tend to work within the scope in which they were conceived. I used mine on dozens of sites within the mainstream commercial genre but I’ve always had to go back and start again for apps. I suspect the same will be true for the Yahoo one and Blueprint. Still, conventions go a long way…

I suspect that the magic required to produce something flexible will be a hindrance to beginners. I wouldn’t like to have learned Javascriptby reading the jQuery source, if you see what I mean. Once you’re over the basics though, it looks like Blueprint rolls in a lot of best practice points so I reckon it’ll come into its own with more experienced devs.

On the semantics front, I tend to use a hybrid of semantics and structural naming. You’ll find class="clearfix" all over everything I do, for example, but discreet portions of content get a useful id (e.g. search, nav, footer). Then elements will get generic class modifiers (e.g. highlight, advert, widget, message) to get them properly styled.

Blueprint promotes laziness. (I’m allowed to say that because I am one of the originators of a lot of its code and methodologies). My biggest beef is with the Grid styles. The rest are a godsend, however, the grid styles greatly frustrate me because they promote class bloat. After using it during its creations and for a few months after I turned away because I felt like I was using tables all over again.

It really isn’t that hard to define a site layout with columns using proper semantics nor is it bad for the legacy of the site.

Newbies: use Blueprint, get a feel for what’s going on, then take some Gas-X and writeyour own CSS.

Seems like harshness is the only thing that draws attention these days :)

If you’re working with a suite of sites like the BBC’s or even the LJWorld’s it only makes sense to develop a common library of styles. The problem I began to notice was all our new sites looked the same. They started taking on the same characteristics of LJ which kind of bothered me. I attribute it to the ease of laying something out with existing code.

Is this a bad thing? I dunno, communism sorta sucked. (excuse my harshness, I just had a double espresso)

I could see the benefit if the framework were actually a framework (i.e. a lightweight scaffold base) - but blueprint looks like a fully fledged (yet open source) website template.

Pretty much anything you might want to change to create your own website will involve a large amount of code duplication and overhead.

Personally I think the semantic issue is moot - data is abstracted anyway, but how well does the work as a framework on a real website - how much css is going to be rewritten and duplicated. I think this is more pertinent to the success of the framework.

Are there any published goals for blueprint? Its an exciting idea, but I atm can’t tell the differance from any other template…

The problem I began to notice was all our new sites looked the same. They started taking on the same characteristics of LJ which kind of bothered me.

I would agree that htis was a problem at the Journal-World, but I’m not so sure I agree that it was because of the framework.

> I could see the benefit if the framework were actually a framework (i.e. a lightweight scaffold base) - but blueprint looks like a fully fledged (yet open source) website template.

That’s definitely not accurate. It’s absolutely a framework and not a template.

I suppose my essential point is that a framework shouldn’t get in the way of the goal. My fear is that blueprint looks like its going beyond the basics and too far into the area of style for many elements that will need to be overriden in a working site.

The idea behind the grid is a very good solution and very intuitive, but it is only one of a thousand options that may need to be called upon, even a slight deviation would cause terrible code bloat. -Override it and you have lost the benefit a framework should offer you. That’s the big one, but you have to reset lots p are pre styled to be justified, that is not something that should be defined as it should be left to the user to choose - there are many many examples for this.

I’m just not conviced it is a framework in the sense that it oversteps in many ways. It seems to me to be several somewhat agreed upon common set of practises that will need considerable customisation. A framework, imo isn’t something that needs to be partially dismantled for every project.

I suppose my essential point is that a framework shouldn’t get in the way of the goal. My fear is that blueprint looks like its going beyond the basics and too far into the area of style for many elements that will need to be overriden in a working site.

I agree that the framework should not go beyond the basics and into much style that needs to be overrideen. Having used Blueprint, I don’t really think it crosses that line. But I guess everyone’s “line” is in a different place.

The idea behind the grid is a very good solution and very intuitive, but it is only one of a thousand options that may need to be called upon, even a slight deviation would cause terrible code bloat.

If you don’t need the grid, don’t include grids.css.

I would agree that one essential peice Blueprint is currently missing is a way to customize the grid. That is, to be able to say, “I want 10 units of 80 pixels each with 30 pixel gutters.” When we built the grids componenet originally at the Lawrence Journal-World, it had this abaility, through a Python scriptthat used Django templates to generate the grids.css file. While this worked wonders for us, it’s probably not the ideal solution for inclusion in Blueprint—Blueprint shouldn’t have a requirement of Python or Django. But, something along those lines is essential, and currently missing.

I guess I’m not sure what you mean by “override” the grid. If you’re saying you want a different grid, then yes, Blueprint is not flexible enough for you today. If you’re saying you want to use the grid, but have a chunk of HTML that doesn’t align to it, Blueprint definitely won’t get in your way of doing that.

I’m just not conviced it is a framework in the sense that it oversteps in many ways.

If it oversteps your personal lines, that’s fine. No one is requiring you to use it. It’s just one tool for getting a job done. If it doesn’t do what you way or work well for your particular job, find (or create) another tool.

We created the grids component because it was extremely well-suited to the job we were doing in Lawrence. We never expected anyone to release it publicly. As such, it definitely may not fit other jobs as well. If it works for you, aswesome. If not, just ignore it.

A framework, imo isn’t something that needs to be partially dismantled for every project.

I agree. In my opinion, you should never have to modify the files contained in the framework. You may have to override some default settings (you certainly do in Django and other web app frameworks), but never actually modify the files. Blueprint can, and should, be used this way.

Autogeneration of the code is obviously one of the essential parts that is missing to make it a truly flexible framework.

I can imagine using sass (or someother scripting language) to generate the columns.
!colunm = 60
!gutter = 5
Span-2 = (!column*2 + !gutter*1) + !unit

I think grid.css is the most interesting part of blueprint, but as a static files that might need to be overidden will cause problems. I can imagine having a selection different options (for each area), but ultimately the static nature is going to be limiting and or problematic.

I think the project will need a very delicate hand in navigating the fine line between bloat and usefulness, that said it is nice to see an up to date set of good practises in one place.

Using a filter to generate the code would certainly help with the current bloat to cut through all the comments / instructions and also with compacting the file ... which would be a real asset to development. (instead of having one compact and a set of development files).

So, who’s up for a real next level css framework!?

(and if it wasn’t clear from my comments - thank you for releasing/promoting grid.css - and for promoting real world practises, I thought it was quite humbling for AHC to eat their words on the AIGA site :)

Thank you.

I’ve downloaded the latest BP framework and will try it on my new project. Thanks

Thank you to show this. Very helpfull.

Wow surprised at how mixed the comments are on this, seems extremely useful to me.

I see that a CSS framework would help speed up development time even further! I will download the blueprint and check how it works for my latest projects! btw. Thanks Mark for another great article!

hmm.. Its going down the road of prototype.js…

Will have a play but not to sure..