It's recommended! Not everything can fit in a global system - and usually it should not fit into a global system. If you lock yourself into a global system, changes are more difficult and the learning curve on your website increases. Global class use should be used when styles need to be managed on a global level. If there's no reason to update the class on a global level, or it doesn't speed up your build process, then it shouldn't be global. It should be custom!
Creating custom classes is encouraged for inner page elements. There are many benefits to creating a custom class, even if a global class system can be used. The biggest advantage is the ease and speed of updates. Custom classes can help in lowering the learning curve for your build. Custom classes with human readable words can help someone who is inexperienced with Webflow better understand your Webflow build.
If I see the class services-item-background-texture, I know what that class is created for and what its primary purpose is, to manage styles for “a texture that’s on a background image of a services item.” When I make a change to the styles on the class, I can be sure that they will be including this element on the page.
We may be able to create the same end result with 3 stacked classes. For example, background-absolute opacity-low texture-1. When combined, these three classes give us the same outcome as services-item-background-texture. In traditional CSS convention, this would be seen as a win. We do not add to our CSS file and we can control everything globally with these classes.
Here’s why we don’t do this in Webflow
You increase the learning curve.
If a knowledgeable dev visits your site, they should understand these stacked classes are giving the element shared styles from the three classes. And a beginner Webflow developer may not know this. Your client probably doesn’t know this. It’s going to be more difficult for them to update this elements style. Forbid… a… new combo class styling based on 3 stacked global classes. This becomes an unorganized mess. Giving custom classes will allow your clients to play with Designer styles panel with minimal damage.
Inability to reorder styles in Designer styles panel
How terrible is it when you have to swap or remove a class that is first in the list of a multi-class combo styling. This is a bad workflow and an inherent issue with Webflow UX. Using custom classes will limit this happening in your workflow. Instead of digging through a long combo, use the power of Webflow’s fast CSS styling UX.
Writing CSS in Webflow is fast
It’s understandable that traditional CSS frowns upon new class creation. It takes time to hand write styles to a CSS style sheet. And the code would be managed by a developer. Global classes make sense. Now we’re in Webflow. Writing CSS is fast and efficient through the styles panel. Take advantage of it. Creating a new class and applying styles is usually less time consuming than figuring out and maintaining a deep global class system.
Who cares about a tiny CSS savings?
What’s the real difference in load time between a 52kb CSS file vs. a 59kb CSS file? Is it worth making your site less accessible and scalable?
Don't be afraid to use custom classes
... as long as they're organized. Always use clear, meaningful words when naming your custom classes.
Use component naming when you can. Use prefixes for organization and search. Be descriptive of the element.
Sometimes these components can be reused on different pages. Their name can be more general, like list-3-col_component. This type of class can be used throughout the build. It's not specific as to the section it is being used for. Since 'list' is a common keyword in our system, we can assume this is a reusable class that creates a 3 column list.
Sometimes components are specific to one page. Their name can be more specific, like .pricing-calc_component. Now we can organize our classes inside our pricing-calc. For example, pricing-calc_add-button, pricing-calc_display-value, pricing-calc_cta-email
Using component naming helps us understand that a set of elements come together to create a custom UI element. Together they are all creating a visual style for the component.
Components are defined as a group of page elements that create a complete ui element. For example, a newsletter signup, team grid, pricing calculator, reusable 3 column grid, or a clients list.
When a class is specific to a component, we use a [component]_ prefix followed by an underscore. The component keyword and underscore tells us the class style is specific to a recurring component that can be used site-wide.
What is a component? Components are defined as a group of page elements that create a complete ui element. This component may or may not be built into the symbol system of Designer.
Sometimes these components can be reused on different pages. Their name can be more general, like list-3-col_component. Inside this is component, we find elements such as, list-3-col_title list-3-col_hover-icon and list-3-col_background-layer. These type of classes can be used throughout the build. It's not specific as to the content section it is being used for or the page it's on. It can be reused elsewhere on the site without confusion.
Sometimes components are specific to one page. Their name can be more specific, like pricing-calc_component. Now we can organize our classes inside our pricing-calc. For example, pricing-calc_add-button pricing-calc_display-value pricing-calc_cta-email
Using component naming helps us understand that a set of elements come together to create a custom UI element. If a client wants to create a new page, they can use the Client-first outer page structure + components to build it.
Use [component-name]_component as the outer/master div holding the entire component. Repeat the component name and underscore prefix for each element inside.
The nav menu seen on every page
A recurring testimonial slider
The newsletter signup bar before the footer
The team grid list seen on About and Careers pages
The team grid list seen on About and Careers pages
The horizontal logo bar seen scattered throughout the build
When these items can be reused throughout the site, create a Webflow Symbol for this component so clients can easily make updates to the component with override fields. Only create a symbol for elements that will be recurring in multiple instances throughout the build.
.[element]- or .[style]-
Not everything is a component. There are some elements that are truly unique or relate to something more specific that is not within a component.
When a class is specific to an element or style, we use an [element]- or [style]- prefix. Note that the only difference is the underscore and the dash. Our classes that are not specific to a component will get a dash after the prefix keyword.
Here we see elements on the page that are not components. We use our best judgement to name them so we can give as much context about it. Below are two examples.
Form elements that are seen throughout the build and are not inside a single recurring form component.
Shapes and accents in the headers of the website.
We may want to create a global class for each common background color seen on the website. Every section either has default white, black, blue, or gray. We use the background- prefix so we can search for our background color options in the styles panel.
Background color css style that should remain global by class.
There are no hard strict rules with Client-first. Use your best judgement and make decisions that will be clear for others viewing your project. Your site may require a different set of prefixes and globals. Client-first helps you organize your site for your project.