A quick guide to HTML/CSS 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 knows, with overlap, the following button types:

• Default

• Primary

• Icon

• Active

• Disabled

• 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 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:

<link rel="stylesheet" 
href="https://maxcdn.bootstrapcdn.com/bootstrap/
3.3.1/css/bootstrap.min.css">

Now that we compared frameworks to fully functional pattern libraries, here’s another view. Frameworks can also be seen as just 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 is 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 or not 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 is a difference between internal and external frameworks—the external ones are those that typically get referred to as frameworks. Then, there is a difference between using and developing a framework (note that developers can be users, which makes for some blurriness). And finally, there is a difference between experts and amateurs.

Let’s chart this up.

What do you think? Should either type of framework be managed either way, by either group?

Here’s what I think. Let’s compare.

Please note that developing an internal framework and making it public, as we could even apply to blog themes, is here not considered developing an external framework. 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 will later describe), it is the beginner who would not even 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 web documents and apps. Internal beats external every time because external cannot, by definition, know all the needs of the organization and 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; he may discern few impacts in quality, and he may not yet have a long-term vision for his project.

Popular Frameworks

There are many dozens of HTML/CSS frameworks that developers have found useful. Here is a representative selection, to give you an impression of what the world of external frameworks feels like:

• 960 Grid System

• 1140 CSS Grid

• Base

• Bijou

• Bootstrap

• Blueprint

• Cascade Framework

• Columnal

• Compass

• CSS Smart Grid

• Fluid Baseline Grid

• Foundation

• Gantry

• Golden Grid System

• Goldilocks

• Gridiculo.us

• Gridless

• Gridlock

• Gumby

• Groundwork

• HTML KickStart

• HTML5 Boilerplate

• IceCream

• Ingrid

• InuitCSS

• IVORY Framework

• KNACSS

• kouto swiss

• Kube

• Layers CSS

• Less Framework

• Metro UI CSS

• Mueller Grid System

• Profound Grid

• Pure

• Responsee

• ResponsiveAeon

• Responsive Grid System

• Salsa

• Semantic Grid System

• Simple Grid

• Skeleton

• Susy

• Titan

• Toast

• Tuktuk

• YAML

(Some readers will remember Choke, too, although that humor may have been rather crude.)

These frameworks all vary in functionality and scope. Some focus on base layouts, while others go all the way into comprehensive print and mobile themes.

Such a list of frameworks is the type of information that goes stale quickly. While some frameworks, most notably YAML (not to be confused with YAML Ain’t Markup Language), have been around for many years, other frameworks come and go. It’s more useful to obtain said impression from this list, regard it as a snapshot, and, perhaps, make it a starting point to experiment.

1. A Framework Should Be Tailored

We defined tailoring as “producing and adjusting to precise dimensions and needs.” Producing refers to developing a framework—whether internal or external—while adjusting commonly means fitting an external framework. The key here is “precise dimensions and needs.” We need to know our needs—otherwise we can neither produce nor adjust something to fit.

One view of tailored code, by the way, is to compare needed code with overall code. That can be hard to measure, because the number of characters or lines in our code doesn’t do the trick. But conceptually, tailoring means using as little and yet as effective code as possible, and not more.

What can we do to tailor? The approach depends on the origin of the framework, and that origin makes for a big difference.

An internal framework is relatively simple to tailor: We develop to the needs of our project from the beginning. These needs may be defined by comps (comprehensive layouts) and mocks (mock-ups) or, better, a style guide. Once all needed page types and elements have been specified, they’re coded up. If they’re all used by the later site or app, the code cannot be anything but tailored (although it can possibly still be optimized and compressed).

An external framework, however, is much more difficult to tailor (by the receiving side, because it’s impossible for the originator). In a basic sense, we need to deduct all needed functionality from all offered functionality, and then remove the code that remains. That leads us to the key issues with external frameworks: removing code may not even be possible, and tailoring then depends on the quality of the framework code and its documentation (e.g., tailoring will require testing, might break the framework, and could make the same work necessary for later updates, if not outright thwarting the ability to move to newer frameworks).

These are big issues that make for good reasons why few people actually go to the length of customizing or tailoring external frameworks (or any external code, for that matter). Yet the outcome—non-tailored and lower-quality code—is not very expert-like, and inferior. And so we see with more clarity why in a professional context, external frameworks shouldn’t be preferred. They promise to save cost, only to come with a stiff hidden tax or else bring down the quality of our work.

Now, some frameworks like Bootstrap or Gumby have begun to address these problems by offering sophisticated customization wizards. This is smart, because it significantly alleviates the issues of non-tailored solutions. Framework developers should offer and users use such functionality.

By the way, there’s another problem we need to consider: while we’re benefiting from either our decision to save cost or to improve quality, our end users benefit mostly from quality. Technically speaking, they are rarely on the list of beneficiaries if we decide to deploy a framework that’s bloated but easy to churn out.

To tailor internal frameworks:

• Be clear about needs.

• Build the framework to these needs.

To tailor external frameworks:

• Be clear about needs.

• Customize or modify the framework to these needs (or abstain from the framework).

2. A Framework Should Be Usable

A good framework is not only tailored but also usable. But what is usability for frameworks? It starts with applying the common definition of usability: ease of use and learnability. And with a universal rule: keep it simple. Simplicity helps everything.

But that’s not quite a complete answer, and so we need to differentiate again. The distinction that serves us here is not one between frameworks, but between roles: framework users and framework developers.

For the framework user (who may be a developer himself but is now concerned with working with the framework), a usable framework is also easy to understand. That ease of understanding is primarily achieved through clear framework documentation and, where applicable, concise code.

For the framework developer, there’s much more emphasis on usable code. Luckily, there are two things we can firmly link with helping code usability: maintainability practices and code conventions (coding guidelines). Adherence to maintainability practices and consistent style are the backbone for usable code.

With slightly smaller boundaries than developer experience, I generally believe there is a subfield of usability: developer usability. It could be defined as “the ease of use and learnability of code.” Perhaps this field doesn’t get much attention because usable code goes under different names, as we just found, but perhaps it would benefit from being treated separately.

To make frameworks more usable for users:

• Keep it simple.

• Follow usability conventions.

• Perform usability tests.

• Provide documentation for framework users.

To make frameworks more usable for developers:

• Keep it simple.

• Aim for self-explanatory code.

• Format code legibly and consistently.

• Follow maintainability best practices.

• Provide documentation for framework developers.

3. A Framework Should Be Extensible

The final attribute to underscore is extensibility. Extensibility for a framework means that it’s not just possible, but well-defined and easy to extend it.

Extensibility is necessary for two reasons. First, external frameworks in particular won’t offer everything we need, so there needs to be a way to add functionality. Second, especially in large projects, there’s a tendency for new patterns to pop up. The problem with these is their uncertainty and uniqueness: they may only be used once or twice and don’t warrant a place in the framework core or even near more common extensions. Both their location and handling have to be thought of.

To make up for lacking functionality in a framework, users typically help themselves by pretending they don’t use a framework in the first place. That is, they have a style sheet or script that handles everything the framework doesn’t cover. That’s actually quite OK; the point here is to be clear about how such “non-framework functionality” or extensions are handled (and we notice how extensibility is also a user responsibility). If nothing else, extensibility stresses the need for the most basic of all code safeties: a namespace (a framework-specific ID and class name prefix, and the same namespace in JavaScript).

Next, new and rarely used patterns are a challenge that runs in the best families. There tends to always be a need for something new, and there are always document types or elements that are used infrequently. They’re one of the biggest contributing factors to code bloat. They are hard to control if they don’t get watched and reigned in vigorously. Though I could give a longer dissertation about the matter, an effective counter-practice is to either designate style sheet and script sections for new and experimental code, as well as rare elements—or to even put aside a separate style sheet and script for such purposes. The framework developers should anticipate this and make recommendations, but users should come up with their own guidelines if this piece has not been covered. A documented standard for new code allows better monitoring and better decisions on whether to keep (and relocate) the code, or to remove it.

We’ve very successfully applied this principle with Google’s HTML/CSS framework Go—not to be confused with the programming language, which was conceived two years later. Go came with a “backpack” library, Go X, which included elements that we used only occasionally. This kept the core very small—4,250 bytes including the Google logo—but offered the use of additional, common-enough elements. Project-specific code made for a third layer that had to be carried by each project style sheet itself.

To make frameworks more extensible:

• Use a framework namespace.

• Define handling of non-framework code.

• Specify where new and rarely used code should be located (also a framework-user responsibility).

• Regularly review new and rarely used code, to either make part of framework or remove (also a framework-user responsibility).

Choosing a Framework

The “pro-quality” choice has been explained as using or developing an internal framework, and choosing a framework generally applies to external ones. The choice of an external framework depends on two factors:

1. Which one meets our needs the best?

2. Which one is of the best quality (that is, which one is as tailored/customizable, usable, and extensible as possible)?

These questions underline the importance of knowing our precise needs. It is even important in order to pick a framework, as knowing our needs helps determine which framework fits better (tailoring) and comes closer to our extensibility needs (though simple needs don’t require extensibility as frequently as comprehensive needs).

The Two Ground Rules of Using a Framework

And of any framework at that. These two rules are golden:

header {
  /* No layout declarations */
}

header {
  position: relative;
  top: 1em;
}

header {
  left: 0;
  position: absolute;
  top: 0;
}

Principles

We’ve already done our assignment and fleshed out the principles for framework development. A framework should aim for the highest quality standards, and then:

1. A framework should be tailored.

2. A framework should be usable.

3. A framework should be extensible.

These shall serve as every framework’s core values (for which we can use the avenues outlined earlier).

Customization, as identified under 1. A Framework Should Be Tailored, plays a special role here, for it is the secret weapon—and last line of defense—of the external framework developer. Offering framework customization options is the only way to get closer to tailoring for outside users, users whose projects we will never know.

I decided against including a section about customization because it’s not a magic pill for external frameworks, and can stack the whole deck against the framework developer instead of the framework user. This is because the more customization options there are, the more complex the framework gets. Yet that’s still only talking framework development. The framework and all its customized subversions, as we’ll see shortly, still need to be tested, quality-managed, maintained, and so on.

Prototype

The single most important thing we need to build a successful framework is a prototype. Here we benefit from our recognition that we’re really only talking about plain-vanilla style sheets and scripts. Large projects—projects like those for which we now talk frameworks—have always benefited from prototypes.

What do we mean by prototype? In its simplest form, it is a static (internal) website or demo site. It should contain all document types and elements we need in production: the prototype is where we code all the structure (HTML), presentation (CSS), and behavior (JavaScript). And the prototype should include realistic (occasionally intermingled with extreme) sample contents: that’s how we test that everything works.

A prototype is an irreplaceable testing ground that we need to obtain the end result we want.

Prototypes follow their own principles, however. They must be, as I attempted to summarize in earlier years (slightly reworded):

• Complete

• Current

• Realistic

• Focused

• Accessible/available

• Managed with discipline

• Maintained

• Communicated/promoted

• Documented

Each of these points is important, but the first three are critical. The prototype has to include everything (all document types and elements), it must be current (any functionality changes must be reflected immediately), and it needs to be realistic (the sample data must be an as-good-as-possible approximation of how the framework is going to be used outside of the prototype).

Quality Management

In order to be sure that we deliver the quality we’re committing to as professionals, we need to verify it. This is done through quality assurance (which aims to prevent issues by focusing on the process), and quality control (which aims to find and fix issues in the end product).

Web development, as a still rather young discipline, knows more quality control than quality assurance. Good examples are validation, accessibility, and performance checks, of which there are plenty. On the quality assurance end, the most prominent example is the enactment of coding guidelines, but some organizations and individuals go so far as to use elaborate infrastructure to continuously test and improve their code. (This is all related to web rather than software development, since in software development, there is a longer history and strong tradition of working with tests.)

For quality assurance, it’s useful to:

• Establish coding guidelines

• Define output quality criteria

• Run regular tests (over prototype and live implementations)

For quality control, test:

• Accessibility

• Links (if applicable)

• Performance

• Responsiveness

• Maintainability

• Validation

• Linting

• Formatting

(Incidentally, I run a website hub dedicated to web development testing tools. Check uitest.com/en/analysis/ for a large selection of them.)

To take a page out of Google’s book, it’s best to automate such checks. Reviewing tool documentation can give valuable pointers, as a number of tools can be installed locally or come with an API. In addition, there are instruments like Selenium and ChromeDriver that facilitate automated browser testing. As with many of the more complex topics, this book will resort to just showing directions.

Maintenance

We’ve so far noted how principles, a prototype, and quality management are important in framework development. The last key item to stress is maintenance. Maintenance here primarily means (similar to prototypes) a strong commitment to move forward with a framework. This is important for two reasons.

For one, in the case of external frameworks, maintenance is crucial because publishing a framework is a promise to the user base. That promise is precisely that it’s going to be maintained. It’s also a promise in how it’s going to be maintained, in that we do everything in our power not to change any structure, but only the framework style sheets and scripts.

For another, in any framework, a commitment to maintenance acts like another form of safety. The general idea in web development is that the HTML is most important to get right, because it’s more expensive—think our cost definition—to change than style sheets and scripts. An explicit commitment to maintenance will keep us from discarding a framework to just “build another,” and thus lives up to the vision of CSS-only design iterations and refactorings. (Of course, true structural changes will still always require HTML changes, and with that, eventually, CSS and JavaScript edits.)

A framework, solving widespread and complex development and design issues, comes with an express obligation to maintenance.

Documentation

Though not technically a part of the development process, documentation must be discussed. Anchoring documentation where the development happens has many advantages, from increasing the chances that it’s actually done, to being more comprehensive and accurate because it’s fresh on the mind.

There are several ways to document, but one of the more effective ones is using a prototype for this purpose too. Sample contents can be turned into documentation describing the page types and elements they’re forming, but it’s also possible to use hover-style info boxes that share background information and explain the code. (A properly maintained prototype enriched this way may even do most of the lifting of any framework site!)

Documentation begins in the code, however, and there, too, we need to exercise discipline. Our coding guidelines should underline this; documentation standards like CSSDOC and JSDOC, as well as tools that automatically pull such documentation from our code, can be of great help.

The idea behind documentation is to make life easier for ourselves, our colleagues, framework users, and any people interested in the work. Thus, making it part of the development process goes a long way.

Logistics

Our journey, now that we diligently worked through everything relevant to frameworks, is soon over. A bonus aspect concerns logistics. We have covered a few pieces that can be considered logistics:

• Coding guidelines

• Quality-control tools

• Documentation

What we haven’t touched are:

• Framework development plans or roadmaps

• Version control systems (like Git, Mercurial, or Subversion)

• Request and bug management systems (like Bugzilla)

• Framework sites (public for external frameworks) with news feeds

• Mailing lists for

  • Developers (framework development team)

  • Users (open to everyone interested)

  • Announcements (low-volume essentials which should go to the developers and users lists, too)

• Trackers for live implementations

A framework site and an announcements list are particularly noteworthy, as they can pay good dividends to framework owners and developers. The site serves as a hub for information and documentation. An announcements list is indispensable to inform customers about new releases and guide framework users.

Support also falls into the logistics category. It does not get more attention here because, for one, we “embed” support at several landmarks along the way—in quality goals and principles, in documentation and logistics—and for another, support is more of a tangential topic that depends on the complexity and circumstances of the framework and the problems it tries to solve.

Lack of Discipline

One of the most severe issues is lack of discipline. For the user, this most commonly means not using frameworks as intended and violating the two ground rules (following documentation and not overwriting framework code). For the developer, this usually means becoming sloppy with quality standards, the prototype, or documentation. The result is the same: sabotage, just from opposite sides of the table.

The solution is not easy to come by. Users of external frameworks are free to do what they want anyway; they may not even notice that an external framework is very difficult to ride in the first place. It’s a bit easier internally, where rules can be established, communicated, and enforced. Personally, while I have observed many issues in practice, I haven’t found a cure for this one yet. People are just very creative, and watching how frameworks end up being used is like looking right into the face of human nature (and Murphy’s Law).

Lack of a Prototype

Not having a prototype is an equally critical problem, for all the benefits outlined in Prototype. Apart from the fact that framework development is so much harder without a contained environment, maintenance complexity increases by the minute if there is no prototype. A framework without a prototype is essentially freewheeling, out of control. As suggested earlier, a mere collection of static pages—as long as it’s complete, current, and realistic—does help.

Lack of Maintenance

If we do not maintain (or stop to maintain), outside of major structural changes or prolonged resource shortages, we miss great opportunities. In the case of external frameworks, it can damage the reputation of those providing the framework. In the case of internal frameworks, it can mean giving up control over the framework-managed docs and apps, and thus slowly being forced into a costly, full-blown relaunch.

Maintenance doesn’t mean we should continuously change a framework—that may even be hurtful, especially for external frameworks because of the nuisance it creates. Rather, we should regularly monitor, test, and tweak the framework to keep it current. Such care pays off in many ways, be it because it reduces the need for more drastic changes (relaunches, which are pricey) or because everyone’s staying in touch and familiar with the framework.

Lack of Accuracy

An assumption we’ve made thus far is that what our frameworks do is accurate—that is, that they match the underlying needs and designs. That latter part can be a potential source of error if the frameworks we coded or found ourselves using don’t match the specs our designer friends sent us (if we’re not the designers ourselves). This can lead to all kinds of issues: from not being able to accommodate the original plan (no use for our external framework) to needing structural changes (ouch) to asking the designer folks to rationalize and Photoshop the differences away instead of fixing the framework. We need to watch out for design and style guide divergence.

Lack of Guts

The last big issue is to not have what it takes—even if that’s manager support—to pull the plug. Clinging on to something that’s not relevant anymore. Something that’s not used anymore. That’s used wrong. That’s a construction ruin. That can’t be maintained or extended. Something like that.

Sticking with a broken framework, a failed one, or perhaps a glorious one that has just reached the end of its lifetime can be a challenge. When that happens to us, we need to get over it. As professionals, we have big goals and we want our code to last—but sometimes we fail, and then we need to…suck it up.

Fortunately, there’s always more code to write. The next framework—or style sheet, or script—is already waiting for us.