Breakpoints add another layer of inheritance, as declared styles cascade outward from the Desktop viewport (down to Mobile and up to 1920). It’s important, therefore, to always begin declaring styles at Desktop viewport, treating smaller and larger viewports as varying degrees of exceptions.
Many styles declared at the Desktop viewport won’t need to be changed at other viewports. Styles like fonts, colors and borders don’t often change from viewport to viewport. But styles like sizes, padding and positioning often will need adjustments in order to accommodate smaller or larger screen sizes. It’s best, then, to define these exceptions as needed.
A good way to think of style inheritance across viewports is like a mountain climbing team, with each member tethered to the next on the summit. The Desktop viewport is like the team leader, so his behavior directly impacts the entire team. And the behavior of the Tablet viewport, second in line, will impact the Mobile viewports, who bring up the rear. For the team to efficiently ascend the mountain, this hierarchy needs to be observed, relying on the team leader for direction and only deviating when necessary with the understanding that each member’s deviations impact all the climbers behind them.
Because of inheritance, it’s important to be aware of the viewport you’re in when making style declarations. It’s easy to accidentally make adjustments to styles in the Tablet viewport that will also need to be redundantly applied to the Desktop viewport. In this case, future updates to these styles will require adjustments at both viewports unless the original Tablet viewport declarations are removed to allow for inheritance. This is all a lot of extra work when the styles could’ve simply been applied once at the Desktop viewport.
It's important that styles aren't simply different across viewports, but are instead optimized for that viewport. Which means making as few changes as possible in order to give the user the best experience. Styles that accomplish the look and feel of the project (fonts, colors, etc.) will often remain the same, but things like sizing (fonts, spacing), layouts (columns become stacked rows) and navigation may need optimization. Additionally, it may be necessary to put content inside hide/show components or slideshows on mobile in order to avoid conspicuously tall layouts.
You might think of optimizing for smaller screens not as shrinking the design, but instead as reducing the dynamics. Body copy, for instance, might remain the same size, but the headlines may all become smaller to accommodate less horizontal real estate, and smaller link copy may need to be enlarged to optimize for touch interactions. This compression means less differentiation between headline types, for instance, so it's important to consider the impact on hierarchy.
Styles inherit up from the Desktop viewport the same way they inherit down. But using Knockout, the amount of optimization that has to be done at larger viewports should be minimal. Knockout's style library is designed to retain the proportional design of the 1440px design up to 1920px, where it will max out and stop expanding.
This is done by converting any pixel measurements to VW units at 1440, & converting them back to pixels (except 33% larger) at 1920px. This is the case for all spacing classes, as well as typography.
If you'd like to remove the 1920px max-width and have the design expand infinitely, the Finsweet Chrome Extension
will allow you to remove the 1920 viewport styles. Just remember to also remove the 1920 calc functions from the Large Viewport Type embed element in the Custom Code symbol.