Theory
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.
Class 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.
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
Last updated
