Jens Oliver Meiert

Get 15% off on select books on Gumroad—use discount code “testdrive”.

The Two Ground Rules for Using a Framework

Post from March 26, 2015 (↻ January 12, 2022), 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.)

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens, and I’m an engineering lead—currently manager for Developer Experience at LivePerson—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 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!

Read More

Maybe this is interesting to you, too:

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

Cover: The Web Development Glossary.

Get a good look at web development? Try 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? Learn about new posts by feed or on Twitter.

Found a mistake? Email me,

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

Last update: January 12, 2022

Professional frontend developers produce valid HTML and CSS.