Blueprint CSS Framework vs YUI Grids #
I did recently compare YUI with a competitor, and I don’t want this to turn into a “YUI vs. X” blog. It’s a very limited topic that quickly becomes just one guy’s opinion—and you probably already know that I’m a big fan of YUI, so it would just turn into somewhat heavy-handed marketing. There are more interesting things I could blog about, and so I plan to only compare YUI with a rival framework when there is some relevant point to make besides YUI iz teh hotness lolzzzz!!!!!11111
Also, Matt Snider already does a good job of comparing frameworks, a much better job than I could, so that niche is filled. While I write this, I have another half-finished draft about a YUI component sitting in my Wordpress dashboard. What can I say? I make web pages at Yahoo, so I use it a lot. But it’s not a “YUI vs. X” article.
CSS frameworks in general, and grids.css in particular, have taken some heat, but I think that the basic concept has been accepted. The “non-semantic class names” argument is specious, in my opinion, since the meanings are defined by the grids microformat. The “more code” argument is also a bit off, since the verbosity is actually easier to parse and manage once you get used to it (speaking as a 90’s-era table-master.) Also, downloading code is usually faster than parsing/displaying it—and divs typically render faster than tables.
A recent thread in our internal web development mailing list compared YUI’s Grids CSS with a hot new kid on the CSS framework block, Blueprint. As I’ve said before, I feel like the YUI Javascript components seem to be created by developers who love the language and want to use it, rather than other frameworks that seem intent on re-inventing Javascript or turning it into some other language. The same can be said, I think, for YUI Grids as compared to Blueprint; but in this case, the love/hate is towards standards, semantic markup, microformats, and the “spirit” of CSS layouts. As its primary author states, Blueprint “brings print design on the web one step closer.”
Haven’t we all be working to convince our bosses and stakeholders and users and fellow developers that “print design on the web” is a fundamentally misguided goal? Isn’t that what the whole “web standards movement” has been about, really?
I think that Blueprint is interesting, but it has some pretty major problems as a CSS framework.
Pixel-based fonts
In principle, using a px measurement for font-size is not a good idea. A handful of browsers will prevent the font from being resized by the user if you do this. Others will set a minimum pixel font size, which means that, for example, your 8px font and 12px fonts, which should be different sizes to convey differing importance, could both be 12px.
The goal of having a consistent vertical grid is a good idea, and very pleasing visually. I did it on this site, and without a single px font size (except a single setting on the HTML element while debugging, which was removed later.)
They were wise to attempt it, but misguided in the implementation. You can do that with flexible fonts just fine, if you’re willing to do just a little bit of math. It won’t always round perfectly, but it’ll be mostly right most of the time in most browsers, which is all that we can ever hope for as webdevs.
(To be fair, it looks like support for fully flexible fonts is on the road map.)
It’s a bit bloated
I’m not so sure about the complaint that the YUI CSS is bloated—next to the CSS that most simple blog templates contain (including this one), it’s teensy, especially when served gzipped and concatenated with your other stuff. Unless you’re working on some very-high-volume streamlined-to-ridiculousness site, there are probably better ways to optimize. Do any kind of profiling on most sites, and you’ll find that the CSS and markup is a very small fraction of the loading time. If the requests are minimized, it’s almost instantaneous. Check out the bloated stuff that we wrote for the Yahoo! Harry Potter site. The images take a while to download, but the CSS and markup is there faster than you can say “He Who Must Not Be Named.”
On the other hand, Blueprint CSS is 3 files, one for each of screen and print, and another for IE hacks. While some will say that having a separate file for IE hacks is a good thing, I much prefer to put all the information for a particular element in one place. Having a single CSS file makes it easier to concatenate and minify with your own stuff. And it’s just one request, whereas Blueprint is 3.
Tabular class names like “span-2” or “append-4”
While YUI Grids is often accused of using non-semantic class names, I think that it is actually quite tame in this area. It uses a microformat-style approach, so that the structure of the data is (ideally) expressed in the class names as they are defined in the microformat, and the visual treatment is defined in the CSS to reflect that structure. This is in fact the purpose of the div tag and class attribute, and it is wrong to say that it’s non-semantic or classitis. Nate Koechley said it better than I can.
On the other hand, while Blueprint CSS results in a shallower hierarchy of nested divs, it uses class names with colspan-esque names like “span-2” and “append-4”, or definitive “stylistic class names” like “.clear”, and so on. Have we come so far from the sound wisdom that stylistic class attributes are problematic?
This is exactly why we don’t use tables for layout any more. Blueprint CSS ends up rendering faster than a layout table, but it still has most of the same problems as layout tables.
If it is important enough to define your grid layout in the markup, then you should be using a table. The whole point of CSS layouts is to separate the layout information from the structural semantic markup.
Takeaways…
I use YUI grids on production sites. I love it. Other webdevs who are familiar with it can pick up my stuff and run with it easily. It’s a great thing. I know some who “only use frameworks to prototype,” but I think it’s best to write production-quality code for prototypes. (Perhaps your front-end isn’t wired up to live data, but I strive to make all the code I write meet a certain level of quality.) If it’s useful in prototyping, what’s the argument to not use it in a live environment? Is the 6k of gzipped CSS really such a burden on your page? If we all use the same framework, then we all know what’s going on in one another’s code. This doesn’t matter for prototypes, but is crucial for live products that need to be maintained.
All that being said, it would be nice if there was a YUI typography CSS that provided an easy way to achieve consistent vertical spacing without resorting to pixel-sized fonts. Functionality-wise, that’s where Blueprint beats YUI Grids, but I don’t think it’s a very good implementation, overall. I’m not 100% sure if such a thing is planned for YUI, but I would be surprised if no one on that team has at least thought about it. As I said before, it’s possible without stabbing semantics in the face and setting the standards movement back 10 years.
A message to all would-be framework developers out there: Please don’t rewrite my languages! I became a web developer because I care about this craft and enjoy doing it. CSS, HTML, and Javascript are powerful tools to manipulate this very flexible and exciting development platform. Please don’t think that you can make things better by turning them into something else. Abstract out some of the commonly used functionality, or show us how to do more with what we have, or set a standard that we can all agree upon; that’s all fine. But don’t turn my DIVs into TABLEs, or my SPANs into FONTs, or my Javascript into Ruby.