Comments on: Impressions of the Blueprint CSS Framework http://wildbit.com/blog/2008/10/29/impressions-of-the-blueprint-css-framework/ Thoughts on building web apps, businesses, and virtual teams Fri, 11 May 2012 16:40:55 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Dan Kubb http://wildbit.com/blog/2008/10/29/impressions-of-the-blueprint-css-framework/comment-page-1/#comment-2534 Dan Kubb Wed, 29 Oct 2008 18:33:18 +0000 http://www.wildbit.com/?p=268#comment-2534 I don't really use Blueprint (yet) but I have done a bit of research on it and it appears some of the cons you mention are being addressed. The compress utility included with Blueprint allows you to map semantic names like #header and #footer to map to .span-24 for example. You configure the mapping in a YAML file and run the compression script to process the source Blueprint files and output a customized version. As far as unused rules go, that doesn't sound like a particularly difficult problem to solve programatically. Last year I wrote a small utility that scanned the HTML on a page and figured out which CSS rules were not being used: http://gist.github.com/15470 Using the same basic approach a bot could crawl the site (or a list of files), keep track of which CSS rules are used, and then rewrite the CSS to include only those rules. You could have a list of rules to keep that may not necessarily appear on a crawled page (like styles for error messages). It could also filter out duplicate rules, so that the later rules overwrite the former ones.. that way you could alter the styles without actually changing the Blueprint source. I don’t really use Blueprint (yet) but I have done a bit of research on it and it appears some of the cons you mention are being addressed.

The compress utility included with Blueprint allows you to map semantic names like #header and #footer to map to .span-24 for example. You configure the mapping in a YAML file and run the compression script to process the source Blueprint files and output a customized version.

As far as unused rules go, that doesn’t sound like a particularly difficult problem to solve programatically. Last year I wrote a small utility that scanned the HTML on a page and figured out which CSS rules were not being used: http://gist.github.com/15470

Using the same basic approach a bot could crawl the site (or a list of files), keep track of which CSS rules are used, and then rewrite the CSS to include only those rules. You could have a list of rules to keep that may not necessarily appear on a crawled page (like styles for error messages). It could also filter out duplicate rules, so that the later rules overwrite the former ones.. that way you could alter the styles without actually changing the Blueprint source.

]]> By: Ian Bicking http://wildbit.com/blog/2008/10/29/impressions-of-the-blueprint-css-framework/comment-page-1/#comment-2533 Ian Bicking Wed, 29 Oct 2008 18:05:03 +0000 http://www.wildbit.com/?p=268#comment-2533 I've been a little frustrated when I look into CSS frameworks, because the core of the idea is good -- even important -- but the implementations don't seem to live up to the potential. Instead of controlling your layout with specific classes and ids you put in the page, the classes and ids should be fairly static and should be accompanied with the appropriate stylesheet. That is, a framework should be a set of stylesheets, or some kind of stylesheet builder, along with conventions about how you mark up your HTML. That would probably also handle the problem of bloat, as you could choose the CSS features you want. An even better system would be one with markers in comments so these modules could be added or removed from the stylesheet after it has been edited. A toolchain that accepted CSS variables (maybe more constrained than the actual spec, but at least resolving intrastylesheet variables) would also help avoid expected edits directly to the stylesheet, and thus make upgrades easier. I’ve been a little frustrated when I look into CSS frameworks, because the core of the idea is good — even important — but the implementations don’t seem to live up to the potential. Instead of controlling your layout with specific classes and ids you put in the page, the classes and ids should be fairly static and should be accompanied with the appropriate stylesheet. That is, a framework should be a set of stylesheets, or some kind of stylesheet builder, along with conventions about how you mark up your HTML.

That would probably also handle the problem of bloat, as you could choose the CSS features you want. An even better system would be one with markers in comments so these modules could be added or removed from the stylesheet after it has been edited. A toolchain that accepted CSS variables (maybe more constrained than the actual spec, but at least resolving intrastylesheet variables) would also help avoid expected edits directly to the stylesheet, and thus make upgrades easier.

]]>