Theory
Hero
Header
`Navigation
Testimonial
Gallery
Team
Logo
Footer
Blog
FAQ
Newsletter
CTA
Timeline
Contact
404
Features
Form
Filter
Carousel
Banner
Wrapper
Card
Grid
Input
Content
Image
Footnote
Button
List
Item
Slide
Icon
Heading
Tabs
Link
Dropdown
Select
Divider
Details
Description
Large
Small
Primary
Secondary
Tertiary
Ghost
Disabled
Active
Filled
Empty
Featured
Left
Center
Right
Top
Bottom
Error
Success
Wide
Tall
FAQ
Q: Can I use lowercase or underscores instead of capitalized words and spaces?
→ Yes. At Flowbase, we use plain English with capital letters and spaces for readability, but the Base System works with any style you prefer — kebab-case, camelCase, or snake_case.
Q: What if something doesn’t fit into the system? → That’s totally fine. Use your best judgment — or reach out to us for help if you're unsure.
1.1. Global Classes
Some classes are meant to be reused across the entire site — such as those for typography, buttons, sections, or containers.
These are considered global classes, and they should still follow a consistent naming convention. For example:
Section LargeContainer SmallButton Primary
The Starter Project includes a helpful set of global classes, but you’re encouraged to create more as needed.
Appendix
Class Name Examples
Combo Classes
There are two types of combo classes, combo classes that are tied to the and 'global' combo classes.
Global Combo classes have a number of frustrations in Webflow.
If you rename a global combo classes, everywhere that global combo class is used will break as its referencing a class that no longer exists.
If you copy paste an element which uses global combo classes, it will break as it no longer has the global combo class to reference it
If you go to a smaller breakpoint and try to change a style, you need to remove the combo class
Lets use variables instead
If you rename a regular combo class thats tied to another class then it will update that name.
Responsive Units
In Webflow, you can use either pixels (px) or rem units to define sizes for elements, typography, and spacing. Pixels are an absolute unit, meaning they provide fixed sizes that do not scale with user preferences. This makes them ideal for precise control over elements when a fixed layout is required, but it can limit flexibility and responsiveness. As the default unit, pixels are easier to use without needing to convert our units to rem or work with large decimal values.
On the other hand, rem (root em) is a relative unit based on the root font size of the document, which is typically 16px by default. Using rem allows for better scalability and accessibility, ensuring that text and spacing adjust dynamically based on user settings or browser defaults.
When working with typography in Webflow, using rem is generally recommended because it ensures that text sizes remain consistent and adaptable across different screen sizes. For layout and spacing, Webflow primarily defaults to pixels, but switching to rem can improve responsiveness, especially when working across multiple breakpoints. To set rem values in Webflow, simply enter the desired value followed by “rem” in the style panel, such as 2rem for a size that scales with the root font size.
For reference, if the default root font size is 16px, then 1rem equals 16px, 2rem equals 32px, and 0.5rem equals 8px. Using rem ensures a more fluid and scalable design, making it a great choice for modern, accessible web development. However, for cases where exact sizing is needed, pixels may still be the better option.
If you prefer working with REM, the Base System provides a REM Starter Project tailored to those needs, allowing you to adopt your preferred approach. You can also choose between copying components from Flowbase in either REM or Pixels.
The Base System uses plain English words, with spaces and capital letters. We believe using natural language makes class names more readable and intuitive.
Naming Theory
The Base System uses plain English words and avoids using "code-speak" formats like camelCase, snake_case, kebab-case, or special characters such as acronyms, underscores, slashes, or hyphens. This may seem like a controversial decision but there are a few reasons behind this approach.
1. Aligning with Webflow’s Core Philosophy
Webflow is a visual development platform, designed to empower designers and non-coders to build sophisticated websites without needing to write code. By naming classes in plain English, we fully embrace this philosophy. Traditional coding formats—such as camelCase, snake_case, and kebab-case—are remnants of text-based programming, which Webflow abstracts away. There's no longer a need to decipher style sheets, allowing us to make class names more intuitive and accessible.
2. Enhancing Readability and Collaboration
Using natural language for class names makes Webflow projects easier to understand at a glance. Instead of seeing something like btn-primary or grid--two-col, a class named "Button Primary" or "Two Column Grid" reads like a sentence and is immediately clear to designers, developers, and stakeholders alike. This approach mirrors how tools like Figma and Framer allow users to name elements descriptively, creating a seamless workflow between design and development.
3. Webflow Handles Hyphens Automatically
One might assume that spaces in class names would create issues, but Webflow automatically converts spaces into hyphens. This means that while we type and read "Primary Button Large" in the UI, Webflow still maintains the correct syntax (primary-button-large) behind the scenes. Regardless, we recommend separating style (class names) from functionality (attributes). Instead of relying on class names for scripting, using custom attributes (like data-button="primary") makes the project more flexible and avoids class name dependency. This keeps our styles clean and ensures our scripts remain unaffected by class name changes.
Variables Theory
1. Consistency and Scalability
Design systems evolve over time. Without a structured approach, managing design updates can become chaotic.
Primitives ensure consistency: A primary color should always be the same shade of blue across all components. Instead of manually applying hex codes, we reference a variable, ensuring uniformity across the project.
Semantic variables improve maintainability: If we need to tweak how a brand color is applied, we only need to update the mapping of "Background Brand," not search for every instance of a hex code.
This separation allows the same primitive colors to be reused in different contexts, enabling design flexibility without redundancy.
2. Making Design Intent Clear
A major advantage of semantic variables is clarity in design decisions. Instead of seeing an arbitrary #f5f5f5 value and wondering why it was applied, semantic variables explain the purpose behind each choice.
For example:
Background Primary → The main page background
Background Secondary → A subtle contrast for sections
Background Tertiary → An even more subdued background for less prominent elements
Background Brand → The brand’s key accent color
This makes it easier for teams to understand, use, and modify the system without guessing why a particular color was chosen.
3. Faster Adaptation to New Themes & Branding
One of the biggest benefits of semantic variables is their ability to adapt without disrupting the entire system.
If a company rebrands, we don’t need to manually update every instance of "Primary Blue." Instead, we remap the Primary semantic variable to a new color, instantly updating all relevant elements.
If a website has dark mode, we can redefine "Background Primary" from white to dark gray without touching individual components.
Semantic variables allow for global updates with minimal effort, making it easy to support multiple themes.
4. Why We Use Variables for Border Radius, Sections, and Headings
Beyond colors, we apply the same principle to other design properties such as:
Border Radius: Ensures uniformity across buttons, cards, modals, etc. If we want to tweak the global radius, we only update one variable.
Sections: Consistent padding and spacing scales keep layouts aligned.
Headings: A predefined hierarchy prevents inconsistency in typography styling.
By defining variables for every key design decision, we create a system that is cohesive, scalable, and easy to manage.
Structure Theory
1. Embracing Established Layout Practices
Many design systems introduce extra layers like page wrappers to make copying and pasting layouts easier. However, in the Base System, we focus on simplicity and flexibility—keeping nesting to a minimum. If a page wrapper is needed, users can add one, but it's not enforced by default.
At the core of most web layouts are sections and containers, both of which are familiar concepts used across Webflow, Figma, Framer, and traditional web development. Sticking with these foundational structures makes it easier for designers and developers to build layouts without unnecessary complexity.
Structure Theory
2. Using Flex Gap Instead of Margin Wrappers or Spacing Blocks
Spacing is one of the most debated topics in web development. Different systems handle it in various ways:
Margin wrappers introduce extra divs solely for spacing.
Spacing blocks require users to manually insert elements for padding.
Combo-classes or utility classes can get deep and difficult to manage.
Instead of these approaches, the Base System uses flex gap as the primary method of handling spacing. This approach is more efficient, intuitive, and adaptable.
Why Flex Gap?
Minimizes Unnecessary Classes and Wrappers
Instead of adding extra divs for spacing, flex gap lets you apply spacing directly to the parent element.
One utility class applied to a parent controls the spacing between all child elements, reducing class clutter.
Increases Reusability and Flexibility
With flex gap, elements can be rearranged and reused without manually adjusting margins.
No need to override styles when moving elements across different sections.
Aligns with Figma’s Auto Layout
Many designers are used to Frames and Auto Layout in Figma, where gaps are applied at the parent level.
The Base System replicates this structure:
Columns act as Figma Frames.
Spacing is applied through flex gap utility classes.
This familiarity makes it easier for designers transitioning from Figma or Framer to Webflow.
Creates a Clear, Intuitive Structure
Flex gap encourages better hierarchy by grouping related elements together in the Layers Panel.
It ensures paired elements remain visually and structurally aligned, making designs more organized and predictable.
Prevents Deep Combo-Class Stacking
Traditional margin-based spacing often requires stacking multiple combo-classes to achieve the right spacing.
Flex gap eliminates this need, making layouts easier to manage for both beginners and advanced users.
3. Why We Don’t Use Pre-Defined Flex Classes Like "V Flex" or "H Flex"
Some systems use pre-applied vertical or horizontal flex classes, but these can create limitations: ❌ If you want to change an element to no longer use flex, you must remove or override the class. ❌ These classes often introduce unexpected layout shifts, making them harder to control.
Instead, the Base System provides simple utility classes for flex-based spacing that allow you to apply flex gap without locking an element into a rigid layout structure.
4. CSS Grid vs. Flexbox for Spacing
While CSS Grid is a powerful tool, it's not always the best choice for simple one-dimensional layouts. Flexbox provides: ✅ Better performance in Webflow (Webflow grids add extra layers that can slow down page rendering). ✅ More intuitive alignment and wrapping behavior for common use cases like buttons, content blocks, and forms.
For more complex grid-based layouts, Grid is still an option, but for spacing and content alignment, flex gap is the simpler and more efficient choice
The Base System does not seek to reinvent the wheel. It is intended to be incredibly familiar
Familiar industry standard development practices
Useful global variables
familiar, and fast, making it easy to learn and adopt without
We avoid deep nesting combo classes, and stacking multiple divs in favor of clear, purposeful, custom classes. We can leverage modern Webflow features like CSS variables, flex gap, custom properties, and scoped CSS to build layouts with fewer elements and cleaner code.
Overview
How do we name plain English class names, with a
These modifiers make it clear that both classes serve the same function, but with meaningful differences. We should keep names short and meaningful. Avoid mimicking the full DOM structure, which leads to overly long class names. Shorter, flatter naming works better in a visual builder like Webflow, where structure is already visible.
Class Naming
By default, classes are named using plain English words, with spaces and capital letters.
We believe using natural language makes class names more readable, accessible and intuitive. Visual builders like Webflow abstract away the need to decipher style sheets. Webflow automatically converts spaces into hyphens. This means that while we type and read "Primary Button Large" in the UI, Webflow still maintains the correct syntax (primary-button-large) behind the scenes. Generally, we recommend separating style (class names) from functionality (attributes). Instead of relying on class names for scripting, using custom attributes (like data-button="primary") makes the project more flexible and avoids class name dependency. This keeps our styles clean and ensures our scripts remain unaffected by class name changes.
Appendix
Starter Styles
Section
Section X Large
128px / 8rem
96px / 6rem
Section Large
96px / 6rem
64px / 4rem
Section Regular
64px / 4rem
48px / 3rem
Section Small
48px / 3rem
40px / 2.5rem
Section X Small
32px / 2rem
{Custom} Section
Container
Container X Large
1280px / 80rem
Container Large
1120px / 70rem
Container Regular
960px / 60rem
Container Small
800px / 50rem
Container X Small
640px / 40rem
{Custom} Container
{Custom}
Column
Column 2X Large
40px / 2.5rem
Column X Large
32px / 2rem
Column Large
24px / 1.5rem
Column Regular
16px / 1rem
Column Small
12px / 0.75rem
Column X Small
8px / 0.5rem
Column 2X Small
4px / 0.25rem
{Custom} Column
X
Column Center
align-items: center, text-align: center
Column Left
align-items: left
Column Right
align-items: flex-end
Column Space Between
justify-content: space-between
Row
Row 2X Large
40px / 2.5rem
Row X Large
32px / 2rem
Row Large
24px / 1.5rem
Row Regular
16px / 1rem
Row Small
12px / 0.75rem
Row X Small
8px / 0.5rem
Row 2X Small
4px / 0.25rem
{Custom} Row
X
Row Left
justify-content: flex-start
Row Center
justify-content: center
Row Right
justify-content: flex-end
Row Space Between
justify-content: space-between
Row Wrap
flex-wrap: wrap
Max Width
Max Width X Large
832px / 52rem
Max Width Large
640px / 40rem
Max Width Regular
512px / 32rem
Max Width Small
384px / 24rem
Max Width X Small
320px / 20rem
{Custom} Max Width
X
Appendix
Heading
H1 Heading
64px / 4rem
48px / 3rem
1.3
H2 Heading
56px / 3.5rem
40px / 2.5rem
1.3
H3 Heading
48px / 3rem
32px / 2rem
1.4
H4 Heading
40px / 2.5rem
28px / 1.75rem
1.4
H5 Heading
32px / 2rem
1.5
H6 Heading
24px / 1.5rem
1.5
Paragraph
Paragraph X Large
20px / 1.25rem
32px / 2rem
Paragraph Large
18px / 1.1125rem
28px / 1.75rem
Paragraph Regular
16px / 1rem
24px / 1.5rem
Paragraph Small
14px / 0.875rem
20px / 1.25rem
Paragraph X Small
12px / 0.75rem
16px / 1rem
Subheading
Subheading X Large
20px
36px
Bold
Subheading Large
18px
32px
Bold
Subheading Regular
16px
28px
Bold
Subheading Small
14px
24px
Bold
Subheading X Small
12px
20px
Bold
Overline
Overline X Large
20px
36px
All Caps
Overline Large
18px
32px
All Caps
Overline Regular
16px
28px
All Caps
Overline Small
14px
24px
All Caps
Overline X Small
12px
20px
All Caps
Font Weight
Text Weight Black
900
Text Weight Extra Bold
800
Text Weight Bold
700
Text Weight Semibold
600
Text Weight Medium
500
Text Weight Regular
400
Text Weight Light
300
Font Color
Text Color Primary
text-color-primary
Text Color Secondary
text-color-secondary
Text Color Tertiary
text-color-tertiary
Text Color Light
text-color-light
Text Color Dark
text-color-dark
Text Color Brand
text-color-brand
Text Color Inherit
color: inherit
Font Style
Text Underline
Underline
Text Strike
Strike
Text Italic
Italic
Buttons
Button Primary
Main call to action button
Button Secondary
Secondary call to action button
Button Outline
Button with a border
Button Ghost
Button with no background or border
Button Link
Text Link
Form
Form Field Label
Default <label> style
Form Input
Default <input> style
Form Text Area
Variant of <input> for <textarea>
Form Select
Variant of <input> for <select>
Form Checkbox
Default <input type="checkbox">
Form Radio
Default <input type="radio">
Form Success Message
Form Error Message
Icons
Icon X Large
32x32(px)
Icon Large
28x28(px)
Icon Regular
24x24(px)
Icon Small
20x20(px)
Icon X Small
16x16(px)
Icon
No fixed size, used to center icon.
Badges
Badge Large
16px / 24px
4px
10px
Badge Regular
14px / 16px
4px
8px
Badge Small
12px / 16px
4px
8px
Avatars
Avatar X Large
64px
100%
Avatar Large
52px
100%
Avatar Regular
42px
100%
Avatar Small
32px
100%
Avatar X Small
24px
100%
Last updated