Jens Oliver Meiert

The Two Ground Rules of Using a Framework

Post from March 26, 2015, 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:

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 the Author

Jens Oliver Meiert, photo of July 27, 2015.

Jens Oliver Meiert is a developer (O’Reilly, W3C, ex-Google) and philosopher. He experiments with art and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences.

There’s more Jens in the archives and at Amazon. If you have any questions or concerns (or recommendations) about what he writes, leave a comment or a message.

Read More

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

Or maybe say hi on Twitter, Google+, or LinkedIn?

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

Flattr? Found a mistake? Email me, jens@meiert.com.

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

Last update: March 26, 2015

“The end does not justify the means.”