A Few Words on HTML/CSS Frameworks
Published on AugĀ 5, 2008 (updated JulĀ 14, 2023), filed under development, html, css, frameworks, minimalism (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:
Use as little HTML and CSS as possible. Code minimalism helps performance, code efficiency, maintainability, and comprehension.
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.
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
Iām Jens (long: Jens Oliver Meiert), and Iām a web developer, manager, and author. Iāve been working as a technical lead and engineering manager for companies youāve never heard of and companies you use every day, 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.)