The Two Ground Rules for Using a Framework

Post from March 26, 2015 (↻ January 12, 2022), filed under Web Development (feed).

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

1. Follow the Documentation

Whether internal or external framework, whether expert or beginner, read and follow the documentation.

This rule is paramount because the second source of quality issues with frameworks and the works created with them (after framework bloat) is user and developer error. Or user and developer misconduct! Some scenarios that illustrate this might be when a pattern is hacked to work, when something has been developed that’s actually already part of the framework, when things get overwritten without regard for framework updates, or when something has just been “made working.”

When using frameworks, always follow the documentation.

2. Don’t Overwrite Framework Code

For reasons that will become clearer [later in the book], never overwrite framework code.

Contributing to the expert’s dilemma with external frameworks, overwriting framework code can have unforeseen consequences and break things with future updates. Here’s an example:

Framework:

header {
  /* No layout declarations */
}

Overwrite:

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

Framework update:

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

The example, simplified as it is, shows how a seemingly innocent change can have acute consequences. Here, a header is moved by one em. (Note that the example constitutes an overwrite because the framework header is inherently “positioned” and also rests on the initial values for position and top.) The next framework update, however, switches to absolute positioning. As the overwriting rules come later in the cascade, they prevent the update from working (with the exception of left: 0;). In cases like this, overwrites are unpredictable. Overwrites should hence be avoided where possible.

The remedy: For internal frameworks, update the framework, or leave things as they are (as in, no overwriting). For external frameworks, leave things as they are, or create a separate pattern that does the job (like an alternative header, with different markup). Stay away from forking or “patch improvements”; solve issues at the core, or not at all.

As briefly as I could put it—in The Little Book of HTML/CSS Frameworks! (Needless to say, the book includes extra context to understand how these rules contribute to the quality I deem so important in our work.)

About Me

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.

If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!