📒Class Theory
Leave behind the traditional methods of the past, and embrace a visual future.
1.0 Introduction
Class naming is one of the key differences you'll find with the Base System when comparing other Webflow systems. In fact, it's possibly the systems most polarizing aspect of the system - but it's one that we whole-heartedly believe embraces the power of visual development, and lets go of traditional methods without negative impacts.
1.1 Visual Development - Leaving the traditional behind
With the Base System, classes are named in plain English, with spaces and capitalization. Our core belief is that a visual development platform like Webflow should embrace it's position and let go of restrictions and guidelines inherited from traditional development appraches. The simple fact is, these classes are easier to read, and have zero implications on your websites. So why are we still making things harder for ourselves, our future developers and everyone in-between?
Key Advantages:
Classes are easier to read and less visually intimidating for current and future developers
Easily applied and pair across other platforms like Figma and Framer.
Aligns with the naming convention used by Webflow and Framer
2.0 General Approach
2.1. Consistency in Naming Conventions
Name conventions in the Base System
Ensure that your naming conventions are consistent across all components and elements. This includes using similar structures and capitalizations, like "Button Primary" or "Text Large."
2. Descriptive and Contextual Naming
Names should be descriptive enough to convey the purpose and context of the element. For example, instead of "Container Small," you might use "Small Card Container" if it’s specifically for card layouts.
3. Scalability Considerations
For components that have variations, consider a scalable naming approach. For instance, if you have multiple button sizes, you could use names like "Button Small," "Button Medium," and "Button Large."
4. Use of Modifiers
Use modifiers for variants of the same component. For example, "Button Primary" and "Button Secondary" for different styles of buttons.
Naming Colors
Chalk projects follow a simple in web design are another way to group and organize content on a web page. Similar to containers, sections are used to create distinct areas within a page, but they are typically larger and more visually prominent. The base system uses a 24px base for our sections, and their size is determined by top & bottom padding.
Sections are often used to divide a web page into meaningful chunks, such as different topics or sections of content. All sections include a defined top & bottom padding as well as the page left and right padding.
For unique sections don’t be afraid to create a new class. Simply duplicate the class from a root section and give it a name that describes the section, for example, Section Header.
Recommended: Keep the keyword ‘Section’ in this class name so we can easily reuse these for your future pages.
1.0 General Approach
We name classes using plain English words with spaces between words and each word capitalized.
We do not use underscores, dashes, acronyms, abbreviations, brackets, or forward slashes.
1.0.1 Examples
Small, Medium, Large not S, M, L
Vertical, Horizontal not V, H
Wrapper not wrap, '
Statistics' not 'Stats',
“X” not “Extra”
1.0.2 Benefits
Classes are easier to read and less visually intimidating for users.
Aligns with the naming convention used by Webflow
Can be applied across other platforms like Figma and Framer.
Webflow will automatically add hyphens and lowercase your classes. This means you can still target classes in custom code by using the lowercase, hyphenated version of your class.
2.0 Naming Structure
Class names go from general to specific.
Component category
The category the component belongs to such as Logo, Contact etc
If the class is 'global', and used throughout the project, it does not have a component category prefix.
Element name
A short descriptive word, such as Avatar, Card, Review, Stars etc
Modifier
Useful for giving additional content to a class and prevent class name conflicts
Examples
"Testimonial Card Small" ✅ "Testimonial Small Card" ❌
Benefits
Indicates whether the class belongs to that component or is used globally.
Identifies where the class is located
Helps the user to understand the classes purpose
If an element that is typically global is being used specifically for a component. The same principles apply and that class would be "Blog Container", not "Container Blog". We do not want to mix our commonly used global styles with component specific classes.
Deep Nesting Names
Naming deeply nested classes can lead to excessively long class names. Names should be descriptive so you know what they are doing and be unique but they should also be short and succinct. We do not believe it is necessary to do any deep level of prefixing as users do not need to rely on the class name to locate classes visually on the canvas.
Examples
“Testimonial Card" -> “Testimonial Author" -> "Testimonial Avatar" -> "Testimonial Avatar Image". ✅
Testimonial Card -> Testimonial Card Author -> Testimonial Card Author Avatar" -> "Testimonial Card Author Avatar Image". ❌
Benefits
Reduces unnecessary visual noise and clutter
Classes are quicker to read and understand
Page Prefixes
We do not use page prefixes in our names.
Reasons
Can lead to excessively long class names i.e "Company Testimonial Card Header"
Can quickly copy sections across pages without naming inconsistencies
Unnecessary as can easily see what pages classes are being used in
Resolving Class Name Conflicts
Often there arises class name conflicts, say there are two avatars being used in the testimonial component example above. Whether to add additional nesting or a modifier to a class depends on what would make the most sense.
If an avatar is nested inside a card while the other is used outside in a parent div, then we add additional nesting to avoid class name conflicts. For example, "Testimonial Avatar" & "Testimonial Card Avatar".
If the section has multiple different avatars that exist that are equally nested in cards, then we use a modifier instead of a nesting prefix. "Testimonial Avatar Large" & "Testimonial Avatar Small".
Blank Divs
Elements that don't have any styles applied should not have a class and be left as blank div blocks.
Benefits
avoids unnecessary class complexity by being Clear that it doesn't have any styles applied,
easy to quickly style without worrying,
does not add any unnecessary class bloat
Disadvantages
cant change multiple elements simultaneously if user wants to update design,
is not semantically meaningful what function the div block is providing .
Commonly used class names
Naming of classes is often subjective, with many synonyms for words that often lead to variation between every developer. This is a brief description of the commonly used words in our class names.
Wrapper
Wrapper is an element that is used to give a content structure, it is typically not the content itself. It is useful to avoid name conflicts with classes and is always a higher level than the element itself. For example "Card Wrapper" contains the cards but is not the card.
Grid
Outline
Outline is used to describe an element that has a border applied. For example, "Social Link Outline", "Card Outline". We do not use "Border"
Card
1. Consistency in Naming Conventions
Ensure that your naming conventions are consistent across all components and elements. This includes using similar structures and capitalizations, like "Button Primary" or "Text Large."
2. Descriptive and Contextual Naming
Names should be descriptive enough to convey the purpose and context of the element. For example, instead of "Container Small," you might use "Small Card Container" if it’s specifically for card layouts.
3. Scalability Considerations
For components that have variations, consider a scalable naming approach. For instance, if you have multiple button sizes, you could use names like "Button Small," "Button Medium," and "Button Large."
4. Use of Modifiers
Use modifiers for variants of the same component. For example, "Button Primary" and "Button Secondary" for different styles of buttons.
1.2 BYOC - Bring Your Own Classes
No system can provide you with every single class, and the Base System is no different. While we aim to provide you with about 70% of the foundational classes (sections, containers, typography, spacing etc). You are always encourged to create custom classes that follow our general naming framework.
Last updated
