Jens Oliver Meiert

A Few Words on HTML/CSS Frameworks

Published on Aug 5, 2008 (updated Jul 14, 2023), filed under (feed). (Share this on Mastodon or Bluesky?)

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.

About Me

Jens Oliver Meiert, on November 9, 2024.

I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve worked as a technical lead and engineering manager for small and large enterprises, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), 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. (I value you being critical, interpreting charitably, and giving feedback.)