A Few Words on HTML/CSS Frameworks

Published on August 5, 2008 (↻ July 14, 2023), filed under (RSS feed for all categories).

Before you read this post, I threw all the frameworks experience I could muster into a little book on the matter: Check out The Little Book of HTML/CSS Frameworks (updated) for a fresh look at—frameworks.

Public, or open, or external, HTML/CSS frameworks are rarely a good idea.

Why? Because framework developers are outside of your organization and cannot know your needs. This simple fact, the inevitable ignorance of a third party, means that frameworks require too much markup in your templates and documents and too many rules in your style sheets. Public frameworks are always inferior to a tailored, internal solution. Using public frameworks can only be okay if you couldn’t care less, just starting, maybe; using them is not advisable if you want quality. Which is the assumption here.

Public frameworks don’t offer what you need. They can’t. And hence much of the stuff they come with means either extra work for you (removing it) or extra ballast for your visitors (downloading it).

Observe the tailor metaphor: A professional web developer is like a tailor, and public frameworks are like ready-made clothes that only fit loosely. You pay more for the perfect website just like you would for a suit; more than for a mass-copied template or a mass-produced garment. On average, ready-made clothes fit better though, than their framework equivalents, meaning you get the worse deal with frameworks. There is a rather limited set of shapes and sizes of body parts, but a less limited number of page elements.

When Frameworks Work

Frameworks truly only work internally, that is, when you build them yourselves and can tailor. When you know all page types and elements to be able to cater for all probable use cases, to create a “real” framework. For such internal development, the following “Golden Rules” apply:

  1. Use as little HTML and CSS as possible. Code minimalism helps performance, code efficiency, maintainability, and comprehension.

  2. Focus on developers. Make it as easy as possible to use—code with—the framework. Avoid unnatural markup constructs wherever you can. Avoid IDs and classes wherever you can. Make it as cognitively simple as possible to work with the templates, without need for a manual, so that ultimately, not only developers and their organizations benefit, but end users.

  3. Support only page types and elements that are used 90% of the time. This seems to contradict the idea of covering all cases with a framework, but aims to avoid featuritis. Say yes to extensions (if you’re dealing with many unique page elements, an extension mechanism might be the only solution—just don’t include extensions in the framework core), but say no to adding everything, unless it’s used several times. Never develop for “everything.”

This should provide good guidance around frameworks, to help build better, since customized, frameworks. So that next time, we can talk about the term “framework,” the possible misnomer.

Was this useful or interesting? Share (toot) this post, or support my work by buying one of my books (they’re affordable, and many receive updates). Thanks!

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences. (Be critical, interpret charitably, and send feedback.)

Comments (Closed)

  1. On August 5, 2008, 22:05 CEST, Ben Carlson said:

    Your tailor analogy is good, but how many people buy tailored clothes? Very few. Mass production works for many reasons. I see no problem with frameworks so long as the client ends up with a good site. Why does it matter what method you used to get there?

  2. On August 5, 2008, 22:48 CEST, Sean said:

    @Ben
    But you are being paid to tailor a website. It isn’t like you are making the same site over and over again. Each is unique to the client. Sure, there are some standard elements that go across designs, and all designers would be smart to create a catalog of those to use when you need them.

    But the problem with frameworks (and Jens point) is that you carry all the catalog of things whether you need it or not. Or you spend time deleting the things you don’t, which then begs the question why were you using a framework in the first place?

  3. On August 5, 2008, 22:54 CEST, Kristy said:

    Yeah, I found that frameworks don’t really work well if you build sites for content management systems. I pretty much had to come up with my own set of CSS and HTML to make it all work. So, yes, be cautious using HTML CSS frameworks on special projects.

  4. On August 5, 2008, 23:13 CEST, Duluoz said:

    Here’s a framework for you to enjoy.

    * {margin:0; padding:0;}

    Oh, and those grids you love, but don’t want to have to bother with complicated division to come up with those wacky ‘custom measurements’ for your columns
 ask an 8 year old down the street to help you out.  đŸ˜‰

  5. On August 5, 2008, 23:17 CEST, Arjan Terol said:

    If you want to use frameworks thats fine by me if it suits you and if its fits in your workflow. I use frameworks mainly as a reference and for study. The bits I like I turn into snippets I put into Snippely (small Air app) and reuse these bits if they fit into a specific project. I agree that every project needs its own approach and personally think that if a framework is your starting point your off on the wrong foot.

  6. On August 5, 2008, 23:23 CEST, Walter Wimberly said:

    Frameworks can, and often should, be custom “tailored” to work best for an environment. Think of it as a starting point.

    I developed a couple of basic frameworks for myself early on, just to eliminate adding the same basic divs which always existed, and css styles to go with it.

    Used well, they are a tool to help, used poorly, like anything else, they are a weight holding you down.

  7. On August 6, 2008, 18:23 CEST, Vladimir said:

    Today I published one article “When to use CSS framework? “ . And maybe we are arriving to the same conclusion: It is not always good idea to use CSS Framework. I love your “tailor metaphor” but I must add something If you are using CSS Framework you can always “re-tailor” the css code (modify or delete the CSS code that you don’t use). The “Golden Rules” are great, I totally agree. The main problem that I have like CSS Framework creator is to involve the CSS community to help(suggestion, debugging, testing) for building better more user friendly project.

  8. On August 6, 2008, 21:58 CEST, Jens Nedal said:

    Frameworks work for just that, when you need something fast, a working solution, that you do not have to think about.

    But as with anything there is an upside and downside. The downside with frameworks is, that as soon as you want to go out of the framework box, you will have to adapt it. Then you have to measure whether the adaptions still make it worth to use the framework or use your own custom styles.

    There are certainly times when you will want to use them and then again not.

    About *{margin:0; padding:0;}: if meant seriously and not sarcastically i could not agree less. Why? During my work with alot of different CMS solutions i have found some, which do not use a custom CSS that you can set to be used specifically within the usual WYSIWYG Editor, but will in fact take reference from the stylesheet attached to the output file. Resetting the values here, would totally ruin the whole display.

    So i change styles in the areas needed, and otherwise leave everything at default.

    Also i liked the funny comment about measurements in em. Calculating those can give you a headache, but they can certainly be rewarding when trying to accomplish a design that scales when enhancing the font size of the browser (no not zooming).

    regards, Jens

  9. On August 7, 2008, 6:13 CEST, Duluoz said:

    @Jens Nedal - I’m of course making jest. But whats wrong with *{margin:0; padding:0;} foo{whatever:blah !important;} where as ‘foo’ is whatever is having the problem. Simple đŸ˜Š Didn’t take a magical framework to fix that.

  10. On August 7, 2008, 7:03 CEST, Nick said:

    I think this article, when-to-use-css-framework, has a better perspective.

  11. On August 7, 2008, 18:55 CEST, Ben Carlson said:

    Yeah, I dunno. I can agree with most of the things you guys are saying, but it seems that you make it out to be almost the end of the world if a framework is used. I will admit that I haven’t used many CSS frameworks, so I don’t know how bloated some of them may be (only one I’ve used is 960.gs), but I still feel that if the final product is quality (and significant time wasn’t wasted on it), then it’s no big deal.

    I don’t think a beginner should start with a framework; learn the code first. But if a framework helps me quickly (and cross-broswer-ly) build a web site, then I’m going to use it.

    *Shrug*

  12. On August 8, 2008, 11:31 CEST, Alan Gresley said:

    I do believe frameworks were developed by certain high profile people since they just didn’t know how to address IE CSS bugs.

    Eric may have given us the edge but frameworks and resets just keep authors ignorant of why there are UA default style sheets in the first place.

  13. On August 8, 2008, 18:05 CEST, Ben Carlson said:

    @Alan Sorry if I don’t buy in to frameworks and resets making developers ignorant. There are universal standards to products all over the place. What would happen if screw-making and screwdriver-making companies didn’t comply to the flat head and Phillips head screwdrivers? What if I made a PMP that had Z represent the pause button, Q represent next, 7 represent previous, etc.

    Sure, proprietary development has merit (Apple’s doing fairly well with it
), but that doesn’t mean anything but is ignorant. Puh-lease.

  14. On August 9, 2008, 17:30 CEST, Alan Gresley said:

    @Ben,

    The longer these frameworks and universal resets are evangelized by a few, the longer authors will not know that UA default style sheets for the various browsers are becoming much the same. Yes, a level playing field.

    You write,

    There are universal standards to products all over the place.

    This is a world of many many standards. When you see through the smokes and mirrors, you may see this. But first you may want to consider why your argument included the word Product.

  15. On August 9, 2008, 19:25 CEST, Estelle said:

    Duluoz -

    * {margin: 0; padding: 0;} is not a good idea for two reasons: the universal selector applies to all elements, including buttons, and other interactive form elements, when the default styling really may be the best idea. Also, it applies to all elements, so your browser your browser is redrawing the padding and margins on inline elements that had no padding or margin to begin with.

    !important, on the other hand, is really hard to overwrite đŸ˜‰ If you feel you need to write “!important” you can either debug and find out what is causing the issue, increase your specificity to overwrite the CSS causing the issue, or, if all else fails, add a class or ID to the misbehaving element. You’ll find doing it right the first time will save you headaches down the road when you find your !important declaration is targeting something you wish it weren’t.

  16. On August 10, 2008, 5:06 CEST, Ben Carlson said:

    @Alan So you’re telling me browsers aren’t products? Sure, not in the traditional sense that a product sells for $X, but they’re still products. Oh well, trying to argue this is fruitless. =) You’ve convinced me! Frameworks suck.

  17. On August 10, 2008, 7:49 CEST, Alan Gresley said:

    @Ben

    There nothing wrong with using Frameworks. Those along with other open source code is free.

    I guess my 40 years has made me see that we live in an age of commercialism and everything is sold as a product. Since the world is becoming quite surreal we can only hope.

  18. On August 10, 2008, 23:07 CEST, Duluoz said:

    @Estelle - I disagree as to the effectiveness of universal selector reset. Regardless of form element issues, its still less cumbersome to address the form elements after the fact than to implement a bloated framework. Can we agree on that? As to the comment about ‘!important’; that was an answer to a previous post and not something I would make habit.

  19. On August 10, 2008, 23:10 CEST, Duluoz said:

    I would also like to add, if I may, that the point of this article was not to say frameworks were wrong, but to suggest they were a highly bloated, inefficient, possible maintenance headaches, and an unnecessary means to an end.

  20. On August 11, 2008, 12:30 CEST, Jens Oliver Meiert said:

    Interesting discussion (glad to discover a few interesting sites along with it, like Estelle’s). I think that there’s no need to become “religious” though, as the key point should be non-controversial: It’s hardly possible that a framework author knows and addresses the needs of multiple unrelated sites, which means that using a framework can hardly mean a quality solution.

    I would also like to add, if I may, that the point of this article was not to say frameworks were wrong, but to suggest they were a highly bloated, inefficient, possible maintenance headaches, and an unnecessary means to an end.

    Essentially, yes.

  21. On August 19, 2008, 17:35 CEST, Sunlust Designs said:

    Thanks for the post mate, I was looking for the “Choke Web Development” post actually and found this resource, I only used frameworks few times, I did use templates many times tho.

    I agree that there’s nothing as good as hand coded website from scratch, it’s just best to work on your own code where you have only what’s needed.

  22. On August 19, 2008, 19:13 CEST, Jay Gilmore (smashingred) said:

    I’ve used frameworks and resets and I don’t use ready to use frameworks anymore for HTML CSS but I do work with small business and do use many regular elements and do use common elements w/in many designs and therefore I have my own basic set of files. There is no bloat and I use HTML snippets along with CSS snippets to drop in horizontal nav or vertical nav and so I am not rewriting things over and over.

    Eric Meyer says not to use his reset as is but to customise it for the project but many people make religion of what certain leaders say and do. Eric is a guy who knows alot about web design and maybe nice (seems it; only conversed via blogs).

    I do use his reset to create a basis for clearing the default ua styles in some cases but I know that there are things that will cause the UA to behave in undesired ways for my project and I remove, change, modify. I also recommend not using it and then overriding the type styles in another sheet. That’s a waste of bytes and time.

    BTW on the tailor analogy, tailors take custom measurements to fit the wearer but they use bodyforms, templates and patterns and then customize them for the person they don’t ignore possible optimizations for some ideal. The difference between tailors and users of RTU frameworks is while tailors do customize each part as necessary to ensure fit and many RTU framework users use them like templates for a production line.

  23. On August 22, 2008, 2:54 CEST, John Faulds said:

    I’ve used frameworks and resets and I don’t use ready to use frameworks anymore for HTML CSS but I do work with small business and do use many regular elements and do use common elements w/in many designs and therefore I have my own basic set of files. There is no bloat and I use HTML snippets along with CSS snippets to drop in horizontal nav or vertical nav and so I am not rewriting things over and over.

    As Jens said at the start, public frameworks probably aren’t a good solution, but any good developer should be doing something like this - creating their own framework of commonly used chunks or snippets of code. This is exactly what I do whether it be HTML, CSS, or basic templates for whichever CMS I happen to be working with.

  24. On August 23, 2008, 8:26 CEST, Xtfer said:

    Im not convinced. Frameworks can be a huge timesaver, get all your team on the same page, accommodate different skill sets, and stop some of them from running off on their own and building unmaintainable code.

    The Tailor analogy is accurate, but like any other technical vocation only the best tailors make the best clothes, and I doubt you’d find a real Tailor who wasn’t using a pattern (or a framework) to start with.

    If you work on your own maybe a Framework is a waste of time. You know your code and only you have to fix it, but a team situation is different.

  25. On October 3, 2008, 13:18 CEST, Chetan said:

    I am the guy who post List of Frameworks in my Blog, Personally i use fameworks for CSS Tricks & Tips, it helps us to learn some new techniques about CSS, but personally i dont like to use any whole CSS Framework directly in my Porject. đŸ˜Š

  26. On May 8, 2009, 10:59 CEST, Shahriat Hossain said:

    CSS frameworks are made for corporate using so better never use any framework until detecting the corporate one đŸ˜‰

  27. On July 23, 2009, 23:12 CEST, Ryan v. said:

    When it comes to frameworks, I tend to generally avoid them. Although they can speed up the initial “frameworking” of a site (hence the name) once you get passed that things tend to slow. There tends to be an abundance of unused classes and clunky code. Like most above me have said, stick to creating your own snippets of code along the way and reference back to them in the future.