Closing this Chapter on CSS Frameworks

Posted: November 19, 2007 Comments(9)

A couple days ago, Jeff Croft posted an article titled What’s not to love about CSS frameworks? In the post, Mr. Croft simply asks for some reasoning behind why some people are suggesting CSS frameworks should not be used:

So it’s been made clear to me that these folks don’t like CSS frameworks and don’t think they should be used (except, in some cases, for rapid prototyping). What’s not clear to me is why they feel this way. So, I’m asking publicly, and hoping these folks will show up here to give me their answers: What is it about CSS frameworks that bothers you?

I think that’s a completely valid question to ask, and with it being asked by someone whom is heard by many, he was sure to get many answers. Within hours, the comments came pouring in from many designers and developers, each giving a personal reaction to their experience with CSS frameworks. There were also some notes included which may have strayed from the articles main topic of CSS frameworks, and I’m going to stray from commenting on that issue because it wouldn’t be fitting for this post.

The general problems with CSS frameworks

I was really happy to see how much of a reaction Mr. Croft’s article received. While many people simply can’t understand why there is so much talk on a seemingly tiny subject, personally I’m glad to see it. I’m glad to see that there is something which can come under debate and be well argued by both sides. That’s not something you often find when it comes to modern Web design among intelligent, professional designers and developers.

While reading through the comments, the consensus from those who choose not to work with a CSS framework was nothing that has not been said before. Some people find a CSS framework limiting to their process or design methods, and others mentioned problems that tie into any framework. Learning to the framework instead of the technology itself, for example. While it was great that people were responding to the article, Mr. Croft mentioned that after 30 comments, his question was still not directly answered.

That got me thinking, even though I had taken a minute to leave my thoughts, I thought I did answer his question in the best way I could. I mentioned why I personally wouldn’t use a CSS framework at this point and time, moreover included a bit of detail regarding why I wouldn’t recommend the use to a fellow developer quite yet. Other comments shared similar thoughts, while others completely opposite, but there was really no direct answer quite yet. This trend continued throughout the comment thread and really got me thinking.

Could the question be answered? I tried myself to come up with a definitive answer(s) why I’m not quite ready to adopt the use of a CSS framework, but found a rebuttal at least once in the comment thread alone. I then tried to put myself in the shoes of a developer who chooses to actively use a CSS framework and defend my camp from that angle. The same result occurred. It seems for many of the arguments either for or against CSS frameworks have a related counter-argument, which could be the reason this debate has been circular for so long.

At the end of the day, what is a CSS framework?

After reading both the original post by Mr. Croft, and then his Follow up on CSS frameworks (and each comment posted in reply), I’ve come to the conclusion that the majority, including myself, have associated the phrase ‘CSS framework’ with blueprintcss. That’s the first problem with the CSS framework debate as a whole. Mr. Croft pointed out that many people who opposed the use of a CSS framework (blueprintcss to be more accurate) were actually using one.

Mr. Croft mentioned that the definition he has had in his mind from the start has been:

… a set of tools, libraries, conventions, and best practices that attempt to abstract routine tasks into generic modules that can be reused. The goal here is to allow the designer or developer to focus on tasks that are unique to a given project, rather than reinventing the wheel each time around. Generally speaking, this is the approach taken by the aforementioned JavaScript and web application frameworks. To be clear, we’re not necessarily talking about something that is built, packaged, and released to the public. Rather, a framework may be solely for you or your team.

From this definition alone, it approaches silly to mention that [many] designers and developers aren’t doing such a thing already. I know I’ve said more than once that I use a preexisting set of folders and (sometimes empty) documents when starting a new project. While it is nothing compared to the level of blueprintcss, it is a reset style sheet, as well as a folder structure to save me a few minutes at the start of each project. At first, due to plain simplicity, it hardly occurred that such a system could be considered a framework, but I think that’s exactly the type of thing Mr. Croft is so diligently trying to defend.

We’re all on the same team

Many of the comments in response to the articles posted by Mr. Croft were a question why a topic such as this is debated so much. I can sympathize with that question, but at the same time, I’ve done my fair share discussing the topic because I find it interesting. There were many people on one side of the fence, seemingly just as many on the other, and a third group of people in the next field chatting about something completely different.

I’m glad Mr. Croft sparked what may act as the last great discussion surrounding CSS frameworks at this level of maturity. While I don’t see the debate dying out any time soon, I think these two articles, paired with their comments, are a great collection of thoughts after the initial introduction of blueprintcss (which put CSS frameworks on the map).

If you haven’t had the pleasure of doing so, take a few minutes soon and read over the articles and comments. Take some time to think about whether or not something as particular as blueprintcss or something as general as a reset style sheet is going to help you. The great thing is, designers and developers have reached a level where we can really begin to think about helping ourselves as much as possible. At the end of the day, we’re all on the same team, working for the same goal. Everyone has a different way of doing things, time and experience will certainly put any questions to bed. As the title of this piece explains, I think what has been said about CSS frameworks is quite comprehensive for this stage of maturity, but I’m more than willing to discuss the idea at any time.

Get my newsletter

Receive periodic updates right in the mail!

  • This field is for validation purposes and should be left unchanged.

Comments

  1. When I saw this post getting some “air time” I decided not to chime in, partly because I do not write CSS for a living and so I do not feel I am an expert on the subject.

    However, after reading your post here – I feel this is a much more fundamental question underlying this entire issue – that of the use of frameworks altogether.

    Since this is a comment, and not an entire post, I will keep my thoughts as short as I can.

    I believe this entire issue can be resolved by one ideal; everyone needs to choose their own path.

    There are benefits and drawbacks from the use of Frameworks – there is no way to argue that. Sure there are going to be some people that will learn a framework rather than relying on learning best methods and we will end up with professionals with a narrow expertise – but I’m ok with that personally. If others aren’t, I see no reason that they shouldn’t be able to voice that opinion.

    This comment has been reedited five times since I wrote it, it was much longer, but I feel as though too much has been said on the subject already. Allow people to choose, that is the important thing.

    One thing I do find slightly ironic and humorous about the entire situation though – is that a well designed CSS for any site is actually a mini-framework for the site’s design. Reusable code, or style rules, that can be applied to any markup to eliminate the need of recoding or ending up with verbose in-line styles. Teehee!

  2. @Colin Devroe: I think you’ve nailed it. You’ve come to much of the same conclusion as myself; the real issue is the idea of a framework in and of itself. That removes much of the ‘sillyness’ people have seen in the CSS-centered discussion as a whole. I agree with your assessment that it really comes down to a personal choice. Either way, the decision should be respected, as frameworks (at least as far as I can see) have proven useful to the many people who chose to employ them.

  3. As I said over at Mr. Croft’s site, the only reason people have strong feelings against CSS frameworks is the grid.css files. If you were to remove the grid.css file and leave everything else, the naysayers would have nothing to complain about because the files left are exactly what most of them use or have created themselves to help start development quickly in their projects.

    Nobody bashed Eric Meyer when he decided to create a well thought out reset file, as I am sure most people wouldn’t bash anyone who releases a nice base typography.css to start from.

    Until CSS support is there for the grids, then the way most of these frameworks have set up their grid files it is really the only way possible to add the extra bonus of creating grids on the fly.

  4. There is one other benefit to using CSS Frameworks that I haven’t heard mentioned. My apologies if this has been said in a previous post.

    If you are a developer and you outsource the design + html templates, you will save yourself a lot of time integrating the work into your Content Management System by having a set of XHTML conventions laid out by the CSS Framework.

    Although some languages or scripts such as Pearl, Javascript, and CSS are incredible because of their flexibility, it sometimes can be very time consuming trying to extend or modify someone else’s code because it requires learning their style of coding. Javascript for example does not require strict typing which can be a blessing when trying to solve a problem using an unconventional solution. The difference can actually save a developer 50+ lines of code. The downside of course is that the burden to later modifly/extend that code lies on the new developer who has to understand that “5” was first used as a string but later used as a number as well.

    Although neither YUI or Blueprint are perfect frameworks. They’re definitely moving towards the right direction. It would also be nice to create a system where a developer no longer has worry about IE 5, IE 5.5, IE 6, IE 7, and any other future version of IE. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *