Class Naming
Class management can be a real source of confusion for teams working together on a project. Classes might be named so generically that they don’t convey any purpose of the class, like <class>Div 16<class>. Or otherwise, they might be named so specifically that they reference content that may impermanent, like <class>Cat Photo<class>. There’s nothing more confounding than coming across a photo of a dog with the class <class>Cat Photo<class> after the content was updated. But these things happen because figuring out the ideal name for dozens or hundreds of elements can be exhausting.
Knockout's atomic class library should be sufficient for the vast majority of use cases, relieving the developer of the naming burden. And it also eliminates the need to reverse engineer complex classes via the styles panel to understand what they're accomplishing. A compound like <class>Headline<class> <class>M<class> <class>Text - Primary<class> <class>Uppercase<class> is readily apparent to any team member who views it. And while it may be tempting to combine these classes into a single complex class, doing so would reduce the clarity and modularity of the build. Maintaining the atomic classes, while it may at times seem unwieldy, is important for the long term maintainability of the project. It eliminates redundant style declarations and avoids a bloated stylesheet.
But where a need is not addressed by the class library, a new class will need to be created. This may be a class that defines the size & margin offset for an absolutely positioned item (<class>Background Element 01<class>). Or it may reference a modular animation (<class>Anim - Card Flip<class>). Or it might even be an extension of the Knockout atomic class library(<class>Padding - XXXXL<class>). In any of these cases, it's important to consider whether a client or another team member would understand the naming convention. So it can be important to reference the item's use, rather than its content or location, and to retain consistency with existing classes. Consider that a class may be reused in a different component, on a different page, or with different content.
On Formatting
Webflow will convert class names to lowercase and convert spaces to underscores in the stylesheet, so some developers like to use lowercase and hyphens in their class naming to maintain parity between the Webflow interface and any custom code. And that can be a great strategy if your client is going to be engaging regularly with the custom code. But we try to keep any content the client will be engaging with inside of the Webflow interface. And we've found that success erring toward clarity and readability, relying on our developers to make those formatting translations rather than forcing clients to adopt a more technical naming convention.