The Little Book of HTML and CSS Frameworks (2015)
Dedicated to the Google Webmaster Team under Dennis Hwang
Introduction
Many commercial websites these days are based on frameworks, and many personal websites use them, too. Yet what are frameworks, why and when do we need them, and how do we best use or build them?
This little book explores frameworks that govern HTML and CSS (and JavaScript) code. It focuses on HTML and CSS because these are at the heart of every web project. The principles outlined in the book, however, can also apply to other forms of frameworks.
The goal of the book is to share solid, higher-level ideas around frameworks, trading some specificity for long-term usefulness. We could analyze all the different frameworks that are out right now, but if you wanted to make up your own mind or write a framework yourself, how useful would such review be if you picked this book up again in five years?
While the book attempts to cover all bases, it glosses over some of them, too. Web development has become a large field. Also, as we’ll see shortly, framework development pivots around tailoring, and tailoring depends on circumstances. We don’t know every project’s circumstances, so we can’t generalize everything.
Although written in simple language, the book is geared toward expert web developers; the people who decide whether to use a framework, how to use it, and whether to develop one.
It has likewise been written by a web developer. I, Jens, have during my career architected frameworks for OPENKNOWLEDGE, GMX, Aperto with their government and business clients, as well as Google. In that time, I haven’t managed to outwit the fast pace of our industry, but I’ve found that some principles, methods, and practices contribute to longer-lasting code. That has benefited the frameworks I wrote, and I hope it will benefit you through this book, too.
Acknowledgments
I’d like to thank the following people for their help with this book: Tony Ruscoe for reviewing and advising to the first draft. Asim Janjua, my good friend, for sharing some of his thoughts. Eric Meyer for the generous foreword [for the original edition]; if it wasn’t for Eric’s work, a huge part of the web development world would look grim today, technically speaking. Simon St.Laurent and Meg Foley for guiding the book down the right track at O’Reilly. The O’Reilly staff, particularly Kristen Brown, and the many other friendly, supportive people involved in making this information accessible and enjoyable. Julia Tang for her always loving support. The W3C and WHATWG groups, the Google Webmaster Team, and the people I’ve worked with over time who made me a better web developer. Thank you.
Key Concepts
Before we dive into frameworks, let’s first go over a few general ideas. We don’t have to agree on everything; all we want is to prevent misunderstandings over the course of this book.
First, there are a handful of terms that may be used differently in other contexts:
- External (also known as public or open): Anything that comes from outside ourselves or our organization and is out of our control. In web development, social site widgets or frameworks are often external.
- Internal (or in-house): Anything that originates from within our organization and is within our control. In web development, site designs, or site style sheets, are often internal.
- Pattern: A classical design pattern. In web development, the individual elements of a document or app are patterns, but so are document types like a three-column article page.
- Cost: A measure of any negative consequence. Typically expenditures of work, time, or money, but possibly negative changes in, for example, perception, satisfaction, or reputation. In web development, for instance, any element added to a page has a cost in terms of reduced page performance.
- Tailoring: The producing and adjusting to precise dimensions and needs. In web development, tailored code is the code that’s needed by a project, but not more.
Second, some assumptions:
- Code has a cost. For example, there's the cost of development, performance, maintenance, documentation, process, quality, and conversion (though not all of them always apply, and not all of them affect the same groups). Unnecessary code has an unnecessary cost.
- Site owners and developers want to save cost. In particular, they want to save unnecessary cost.
- Tailoring code means removing or, better, not even writing or embedding unnecessary code.
- Good code is code that's of measurably or arguably high quality, where arguably means conforming to common best practices.
High-quality code can be said to be tailored, but it doesn’t follow that high-quality code saves cost, at least not as a general rule. Tailored code itself, however, always saves cost. With this first insight, let’s begin.
Understanding Frameworks
What Is a Framework?
“Framework” is a broad term, often misunderstood. Conceptually, a framework in the web development sense can be likened to a library: a library not of books but of design patterns, complete with all needed functionality.
For example, the Pure framework features the following button types:
- Default
- Disabled
- Active
- Primary
- (Customized)
Functionality usually means presentation (styling via CSS) and sometimes also behavior (scripting via JavaScript). The advantage of using a library is that we don’t have to code this functionality ourselves, or do so repeatedly. We instead follow the library’s instructions for the structural side (markup via HTML).
For example, YAML requires the following HTML code for a horizontal navigation menu:
<nav class="ym-hlist"> <ul> <li class="active"><strong>Active</strong></li> <li><a href="#">Link</a></li> <li><a href="#">Link</a></li> </ul> </nav>
The only missing piece or, literally, link, is connecting the library so as to have it apply the functionality to the chosen patterns, on basis of the mandated markup.
For example, to use Bootstrap, we must reference something like:
1 <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.1/css/boo\2 tstrap.min.css">
Just as we compared frameworks to fully functional pattern libraries, here’s another view. Frameworks can also be seen as the style sheets and scripts they are, and external frameworks as shared style sheets and scripts that get lifted to a higher status. We could indeed pick any style sheet or script or both and declare it a framework!
The implications of this second insight are far-reaching. Although rather trivial, it’s one of the keys to understanding frameworks. We’ll keep the term “framework” to use common industry language but will at times look at the idea of elevated style sheets and scripts for guidance.
Why Frameworks?
Frameworks promise to save both development and design time. The thinking goes that many of the things site owners and developers want have been done a thousand times, and thus there's no need to reinvent the wheel. Internal frameworks commonly enjoy a more sober regard, so this particularly applies to external frameworks.
If frameworks come with this promise, the question arises whether they live up to it. The answer boils down to a cost calculation that is, unfortunately, different for every framework and project. How much development cost was saved? How much was, in turn, spent on training, customization, and upgrades?
Apart from suggesting that we do the math and think through every project, the following pages cover frameworks in the necessary detail to empower everyone to form their own theory about the raisons d’être of frameworks.
Types and Uses of Frameworks
While all frameworks provide patterns, we must note general distinctions. For one, there's a difference between internal and external frameworks—the external ones are those that typically get referred to as frameworks. Then, there's a difference between using and developing a framework (although developers can be users, which makes for some blurriness). And finally, there's a difference between experts and amateurs.
Let’s chart this up.
Expert | Beginner | |||
---|---|---|---|---|
Use | Develop | Use | Develop | |
Internal framework | ? | ? | ? | ? |
External framework | ? | ? | ? | ? |
What do you think? Should either type of framework be managed either way, by either group?
Here’s what I think. Let’s compare.
Expert | Beginner | |||
---|---|---|---|---|
Use | Develop | Use | Develop | |
Internal framework | ✅ yes | ✅ yes | ✅ yes | ✅ yes |
External framework | ⛔ no | ✅ yes | ✅ yes | ⛔ no |
Developing an internal framework and making it public, as we could even apply to blog themes, is not considered developing an external framework here. The decisive factor is the goal during the initial development process. A thorough revision and overhaul of an framework to make it external or internal-only, however, constitutes a development phase, and would be acceptable.
Reflected in the table is the idea that frameworks can be used and developed liberally, with two exceptions. One exception is that experts shouldn’t use external frameworks; the other is that beginners shouldn’t develop external frameworks.
The two exceptions stem from a violation of quality standards: While the external framework violates the ideals of the expert (which I’ll describe later), it’s the beginner who would not yet know the necessary ideals to create a quality framework.
The internal framework is safe to use or develop in every case because that’s the preferred way of developing websites and apps. Internal beats external every time because external cannot, by definition, know all the needs of the organization, and therefore fails many quality standards. Second, internal solutions are the better route for both experts and beginners to stay sharp and to learn, since their mistakes have a smaller impact.
The development of an external framework is safest only with an experienced web developer, who can, following the principles outlined in this book, skillfully build and document it so that it has a better chance to be useful, at a low cost-benefit ratio. For the less experienced developer or the one in a hurry, use of an external framework is thought to be more viable simply because things matter a lot less for him; they may discern few impacts in quality, and they may not yet have a long-term vision for their project.
Compilation Frameworks
Compilation frameworks are frameworks that include third-party style sheets and scripts. These may be public reset style sheets, but can extend to elaborate UI elements. Skeleton, for example, used to build on Normalize.css, while Blueprint is thought to incorporate Eric Meyer’s CSS reset. WrapBootstrap and Flat UI Pro are arguably compilation frameworks because they extend Bootstrap, but we typically find the compilation framework species internally, when institutions build their own frameworks based on existing public ones.
We don’t cover compilation frameworks in more detail because they expand on the external frameworks we do cover. But to err on the safe side: Composite frameworks mean composite problems, and there’s extra work involved in testing and maintaining. Special attention is in order.
Popular Frameworks
There are many dozens of HTML/CSS frameworks that developers have found useful. Here is a selection, to give an impression of what the world of external frameworks feels like:
- 1140 CSS Grid
- 960 Grid System
- Base
- Basscss
- Beard
- Bijou
- Blueprint
- Bootstrap
- Brutalist Framework
- Bulma
- Cascade Framework
- Columnal
- Compass
- CSS Smart Grid
- Fluid Baseline Grid
- Foundation
- Golden Grid System
- Goldilocks
- Gridiculous
- Gridless
- Gridlock
- Groundwork
- Gumby
- HiQ
- HTML KickStart
- HTML5 Boilerplate
- IceCream
- Ingrid
- InuitCSS
- IVORY Framework
- KNACSS
- kouto swiss
- Kube
- Layers CSS
- Less Framework
- Materialize
- MetroUI
- Milligram
- mini.css
- Mueller Grid System
- new.css
- Picnic CSS
- Pico.css
- If they don’t, we may be on to the one framework. The one framework for us. Well done.