There are two main ideas behind the Knockout Weblow CSS framework: simple, self-evident class naming, allowing nearly anyone to jump into the build & make updates, & the atomization of components, which allow for styles to be updated universally but components to be adjusted on a per-case basis.

This, of course, isn't the only way to approach a Webflow project. And a number of efficiencies can be gained by using a system like BEM provided your team is familiar with the system & is comfortable creating & naming new classes. But the goal of Knockout is to reduce that friction.

For instance, consider you might have a header component that's used across multiple pages. But the headline on one page is much shorter than the others & you'd like to make it larger to fill space. If the text's classes are named with the block-element format (<span class="class">header-headline</span>), any adjustment to the base class will cascade across all other instances of the block. You can add a subclass modifier (<span class="class">header-headline-large</span>), but the same style may have been created previously as <span class="class">header-headline-short</span>. It takes some trial & error or research to achieve the desired outcome, & the risk of creating duplicate classes between team members with slightly different naming instincts is relatively high. This can be overcome with some training, but why train when you don't have to?

With an atomic class system, the styling is contained to the page. You can change the text classes from <span class="class">Headline</span> <span class="class">M</span> to <span class="class">Headline</span> <span class="class">L</span> without worrying about how it might affect other pages or without any context as to what modifiers have been created for a specific block. Additionally, you can add classes like <span class="class">Uppercase</span> or <span class="class">Text - White</span> to try out different styles risk-free.

This is empowering because it reduces the risk of breakage during optimization or experimentation. It also provides some governance over styles because it filters the choices for headline sizes to a pre-defined set. And while many measurable efficiencies can be gained using other systems, the one thing that is tough to measure is team member confidence. And eliminating the process of creating/naming modifiers & reducing the risk of affecting other components when adjusting CSS declarations can speed up site updates tremendously on the basis of reducing uncertainty, especially when a user has a marketing or design background, rather than a development background.

What's more, you still have the option of making global changes by, for instance, changing the font assigned to the base <span class="class">Headline</span> class. Or by adjusting the exact shade of <span class="class">Text - White</span>. Or by adjusting the sitewide font size of <span class="class">Headline</span> <span class="class">L</span>. The atomic class system maximizes globalization & localization of styles at the same time, eliminating the need to make sweeping changes block-by-block as well as the style deviations between blocks that tend to crop up when you have multiple team members creating new classes.

This approach isn't for every project, but when the team managing the site has mixed backgrounds (like design or marketing) or minimal dev experience, it can be the ideal system for maintaining an orderly site long term.