You’d never start a landscape painting by etching in blades of grass, one-by-one, with a very fine paint brush. It’s not only laborious and time-consuming, you’d also have a very difficult time cleanly filling in the blue sky between the blades at the horizon.
Instead, a painting begins with very broad strokes — perhaps a large swath of blue for the sky, or some green for the grass — that make up the base of the painting. Maybe a splotch of red on top for an old barn or some brown for a country road. At this stage, the painting may seem abstract, but the tones and the perspective have already been established, upon which more specific strokes can express the details. Maybe a gray barn roof is next, or the beginnings of a fence along the road. The details slowly begin to materialize, and by the time you’ve selected your detailing brush to paint in the blades of grass, you’re only filling in highlights, shadows and shapes — the exceptions to the broader greens underneath. These layers, building atop one another, decreasing in scope and increasing in specificity, blend together into a finished product: a portrait of a sleepy little spring morning in the countryside.
There are good reasons to approach a Webflow build in a similar manner, which are amplified when working in a team setting. You can accomplish more in less time by starting with broad strokes and minimizing the use of very specific or redundant declarations. And the resulting spartan build will be much easier for other team members to understand, add to and update. This means leveraging the hierarchy of inheritance and only applying classes when absolutely necessary.
The broadest stroke you can make is to apply style declarations to the Body (All Pages) element. Many of these styles will cascade down to other elements, setting the general style of the project by defining things like a global page background color and global body font styles. These declarations should be made first, like a painting's first broad strokes directly onto the canvas, atop which more specific declarations will be made.
For instance, we might want our site’s body copy to display in Open Sans, rather than the default Arial. Making this adjustment at the Body (All Pages) level means that each text element (headlines, paragraphs, text blocks, lists, labels, etc.) will default to Open Sans. If our brand is updated at a later date, requiring a new body font or an update in font size, we only have to adjust the declaration to Body (All Pages) to achieve the update. If, instead, we had declared the font styles on each paragraph, each headline and each list, the update could require a full site audit and updates to dozens of classes.
We may not want all of our site copy to be the body copy style, however. And we can declare specific styles on an element-by-element basis. For instance, we may want a more graphic font like Brandon Grotesque for headlines. If we make the adjustment to All H1s, we’ll override the Body declarations and all of our H1s will use Brandon Grotesque. Just the same, we may want a specific line height for paragraphs. If we make that one adjustment at All Paragraphs, all of our paragraphs will update with the new line height.
But we may not want all of our headlines or paragraphs to display in the same styles, either. A specific paragraph may need to be centered, or a specific headline may require all caps. To define these exceptions to the element-level styles, we can add a class to apply them to individual elements on a page. This can be a simple utility class (such as “Center”), a combination of utility classes (“Center” “All Caps”), or a complex class that groups a number of different styles into one class (“Large Intro Paragraph”). (We’ll cover these different types of classes in more detail in Session 6.)
The goal, however, is to declare the styles at the broadest level that makes sense, and only apply classes as exceptions to the element-level styles. We want to minimize the number of style declarations and, as much as possible, avoid redundant declarations, thereby minimizing the number of updates required to change a style across the project.
A worst-case scenario is a team member creating a new complex class for each paragraph with a slightly different style. If the body font isn’t defined at Body (All Pages), it could end up being redeclared each time any font style needs to be adjusted, overwriting the default 14px Arial. Even though duplicating classes in Webflow can make relatively quick work of creating these classes, the work that would go into making updates to all of these classes would be tremendous, and the change could otherwise be accomplished by making one adjustment to Body (All Pages).
Tip: Discovering a style’s source of inheritance is as simple as clicking on the orange style property label.
Known Issue: Webflow is sometimes buggy when it comes to inheriting line height for text blocks. The Style Panel may display that it’s inheriting the line-height of 150% from the Body (All Pages) element, but it’s actually displaying 150% OF the Body (All Pages) font size. For a text box to employ a line height relative to its own font size, that needs to be declared.
Note: Building the web sometimes requires some trial-and-error. Even seasoned developers often have to try different combinations of styles in order to achieve the behavior they’re after, especially when it comes to styles that can create different behavior in different situations, like position and display types. However, when settling on the element’s default behavior, it’s important to remove the redundant style declarations, relying on the inheritance. If the redundant style is left declared, future changes made further up the hierarchy will not be inherited.
Think of your viewpoints as a mountain climbing team (stay with us) — there’s a leader, a second-in-command and other subsequent climbers, and each of your actions affects the climber behind you. This methodology rings true in the relationship between desktop, tablet and mobile, as well.Take me there