HTML/CSS Frameworks: Useful, Universal, Usable, Unobtrusive

Published on November 18, 2009 (↻ July 14, 2023), filed under (RSS feed for all categories).

This is not necessarily all wrong but somewhat dated. I threw all the 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.

A high quality HTML/CSS framework needs to have four attributes: useful, universal, usable, and unobtrusive. The four U’s.

Useful

If an HTML/CSS framework doesn’t do what sites and the people behind the sites need, it’s useless. Garbage. Most HTML/CSS frameworks aren’t useful. They solve problems nobody has (for example, an infinite number of columns), or they ignore problems everyone has (for example, core maintenance after n months). For an HTML/CSS framework to be useful it must only address problems more than, say, 90% of all target documents have. That excludes framework customization—see Usable.

Universal

A high quality HTML/CSS framework wants to be used by as many documents as possible. And given that it might be, it then doesn’t want to do any harm. That is, it does not play havoc with any on-top layout, and it doesn’t significantly slow things down, either—see Unobtrusive. It is fine to limit the scope of “universal,” for example to a company. Public frameworks don’t limit their scope. All of them fail at being universal. (Stay with me.)

Usable

A usable framework is easy to understand and can be dumped into pretty much any document, all of this without customization. (This doesn’t mean people should do it.) You’ll see enough crazy things happening once the framework is in production. People don’t want to customize, and of those who want, most will do something you don’t expect, and be it to modify their local copy of the framework in creative ways. To make a framework usable, use as few IDs and classes as possible, narrow layout options to the most probable ones—see Universal—, and generally keep it simple.

Unobtrusive

The best framework cannot even be seen. You barely feel it. It’s like a ghost stroking your hair. It doesn’t slow documents down. It blends into the source code. It’s almost invisible. Alas, you can smell the most popular frameworks from a mile away. Maybe it’s because the document is showing in the status bar that it’s loading something from a foreign hostname. Maybe it’s because the fancy 12 column grid is only offered by framework x. Maybe it’s just paranoia. In order to make an HTML/CSS framework unobtrusive, you need to keep things simple once again, and pull out every “best practice” card you have.

❧ Now that we think about it, maybe the universal margin and padding reset—the one I had to tweet about again for simplicity reasons—is the only HTML/CSS “framework” that ever gets close to these requirements. (Choke certainly does not.)

I at least, the grim web developer, am too much in love with tailored solutions. And so I might share more about this framework I wrote for Google, maybe, the one that I referenced so subtly in July. (And yet this is still a personal post.)

Was this useful or interesting? Share (toot) this post, become a one-time nano-sponsor, or support my work by learning with my ebooks.

About Me

Jens Oliver Meiert, on November 9, 2024.

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 experiences and views. (Please be critical, interpret charitably, and give feedback.)

Comments (Closed)

  1. On November 18, 2009, 19:23 CET, Neovov said:

    Thanks for the ending teasing

    This go.css made me do some regular expression to make it readable (but still uncomprehensible).

    Nice post, but I’m still wondering if a great HTML/CSS framework can exists (depending of the “framework” definition). Maybe if you have to make a billion pages for an huge customer. But for different customers?

    Through the time I made a kind of HTML/CSS squeletton I use in each project I work on. But I find it still uncomplete
 (I’m sure you can help đŸ˜‰ )

    BTW, isn’t there a problem with the Choke’s file weight in your post ? (Choke 1.0 (ZIP, 189,210,670 KB))

  2. On November 18, 2009, 22:08 CET, Vladimir Carrer said:

    Interesting thoughts.
    If I should define CSS Framework in one sentence I will say: CSS Framework is making high level reusable CSS Code

  3. On November 20, 2009, 10:39 CET, Thomas @ DailyThomas.com said:

    Maybe, one day, I’ll start using a html/css framework. For now, I just don’t see the benefit of it. Maybe I’m just too conservative
 I also still use wsftp95 for uploading my files
 lol !

  4. On November 24, 2009, 14:34 CET, Richard said:

    There will probably never be an ideal HTML/CSS framework but often it is a case of just avoiding reinventing the wheel (even if the wheel we are using is a little wonky and doesn’t handle corners well, ha ha).
    Do you have have any recommendations on frameworks that meet or come close to your ideals?

  5. On November 30, 2009, 15:12 CET, Alan Gresley said:

    Just give me some pieces of 4 by 2 (timber), nails and a hammer and all is well. I build up code fragments like this in NoteTab.

    <code &lt;  &gt;
^!InsertHtml <CODE>&lt;^&&gt;</CODE>

<li><a href=""
^!InsertHtml <LI><A href="">^&</A></LI>

    This produces this in the source.

    <code>&lt;&gt;</code>

<li><a href=""></a></li>

    You can create some very large code fragments and even optional selection boxes. Take some time to build up though.

    Frameworks look so bloated in comparison.

  6. On December 23, 2009, 18:54 CET, Alan said:

    Meiert’s four U’s sounds like a good principle to me, Maybe i should be concentrating on the last one since it looks like google will be leaning more and more on the speed of websites after adding the speed section to the webmaster tools.

  7. On May 10, 2010, 15:13 CEST, Webstandard-Blog said:

    Sounds good Jens, but a lot of those HTML-& CSS-Frameworks includes a lot of code-overhead you don’t really needs (mostly). Therefore I reduce it, as much as I can and the web-projetc needs.