updated: November 21st, 2007 / Ross Johnson / 7 Comments

How CSS Frameworks should work

It seems people are still up in arms over CSS Frameworks, and specifically blue print css. Monday By Noon takes a step back and looks at the two sides of the argument.

It seems that many people take issue with frameworks due to the bloat that goes along with them, not the thought that you should have some sort of structure to help improve development time.

This could be fixed however if the boiler plate in development was modular, each section a different file based on what it does. Upon the need to launch the site included files could be combined into one to prevent the extra server requests. This could be done manually, or compiled by a program.

If someone wanted to develop said program (*hint*) it could include additional features such as compressing and combining of html/css/javascript files as well. Think of it as an all in one way to speed up any website when going from development to launching.

7 thoughts How CSS Frameworks should work

  1. I don’t think bloating (file size) is the issue; Blueprint’s main CSS file is only 7k compressed. Also, some people are hung up on semantic class names, but I think that’s an internal decision.

  2. Good point Dennis,

    However 7k is pretty significant considering most of my CSS files range in the 2-3K range. I guess if that is the major problem someone could rework blueprint and turn it into “semanticprint” eh?

  3. I really don’t see file size is the issue, as Dennis says Blueprint is only 7k compressed, 12k not compressed. Although your CSS files are typically only 2-3k are you including a file for the reset, that is 2k alone. You could always drop the typography.css, which is 4k and include your own but I’m guessing you are going to end up creating your own that has almost that much file space also, if you are going to be doing all the baseline grid what not.

    I have never seen an issue with multiple CSS files and server load time. Every site that I work on has multiple CSS files and no ones ever complained. I mean you PREV POST Image is 4k alone, even though thats not a great example since it isn’t that important to the site but still shows how little 4k is. I think this blog’s CSS is around 5k.

    The true matter in which people are upset and have reasons to complain about CSS frameworks is the bloated html file sizes due to so many non semantic classes.

    Looks like you will have some stuff to talk about at are next Refresh meeting also :). I found it pretty funny that right before our presentation on CSS Frameworks, their becomes such a heated debate on the web.

  4. Oh I forgot, maybe I’ll have to make my coworker make a little script to do the compression you are talking about, but I’m guessing there is already one out there.

  5. Extra non needed CSS and HTML code means more loading time and extra gray hairs for people who have to modify and understand it!

    Its the same as when you have to modify someone else code which is full of rubbish and extra bloat!

  6. Thanks for the input Dan! I have seen tests where the major factor in page loading time is not so much the size of the files themselves but rather how many server requests a page has to make (ie more files are linked).

    But you are right, 7k is not huge… and using tons of padding classes is really ineffective also.

  7. Pingback: will work for design blog

Comments are closed.