Jens Oliver Meiert

The Two Ground Rules of Using a Framework

Post from March 26, 2015 (↻ June 8, 2021), filed under .

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.

The cover of “The Little Book of HTML/CSS Frameworks.”

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:


header {
  /* No layout declarations */


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.)

Tweet this? (If it changed your life, you delight me with a coffee.)

About Me

Jens Oliver Meiert, on April 29, 2020.

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

If you have questions or suggestions about what I write, please leave a comment (if available) or a message.

Read More

Have a look at the most popular posts, possibly including:

Looking for a way to comment? Comments have been disabled, unfortunately.

Cover: The Web Development Glossary.

Perhaps my most comprehensive book: The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.

Stay up-to-date? Follow me by feed or on Twitter.

Found a mistake? Email me,

You are here: HomeArchive2015 → The Two Ground Rules of Using a Framework

Last update: June 8, 2021

Professional frontend developers produce valid HTML and CSS.