Folders and

naming decisions

fs-play-icon
Coming soon
Close video
Finsweet introduces a folder system add-on for Client-first. Organize your project's classes with folders.
fs-structure-icon

Intro to Folders

(The short version of this page)
Folders are virtual self-organization tool to group and visually manage classes inside your Webflow project.
We can visualize a folder structure for our project's classes inside Webflow Designer by following a simple naming convention. By using the underscore character, we are able to create a virtual folder system with Client-first.

Know that this does not require any core workflow change in Client-first. Folders is a pure add-on that is optional to use on top of your existing Client-first workflow.

There are two types of folders: Custom class folders and Automatic utility folders.

1. Custom class folders
Use the underscore character to create folders for your project's classes. With this new naming convention, Finsweet Extension automatically generates a virtual folder structure inside Designer.

Folders work like this
folder_
nested-folder_
element-name
Here's an example of a Webflow project's classes organized by folder. Selected is the nav_primary_logo-wrapper class.
Let's break it down. In the above example we have a first level nav_ folder.

Nested inside is a primary_ folder.

Nested inside that folder is the element identifier, the _logo-wrapper.

The full class name to create this folder structure would be nav_primary_logo-wrapper.

Note that this folder system is specific to custom classes.

A custom class is a class created for a specific component, page, grouping of elements, or single element. For example, a class to style the team slider or a class to style the global headers for the project.
Custom classes use an underscore in the class name.
2. Automatic utility folders
First let's understand what a utility class is in Client-firstA utility class is a class created with a specific, usually simple, combination of css properties that can be applied to elements across the project. For example, a class for background-color or a class for font-size.
Utility classes will not use an underscore in the class name.


Client-first starter cloneable comes with classes in the project. These are utility classes! Utility classes have a special and automatic folder process outside of the underscore folder system for custom class folders.

Any class without an underscore goes into the "Utility Classes" folder. We can clearly define our utility classes by using the '-' symbol only. No underscores.

Since we can define a utility class, we can categorize it. All of these classes are categoriezed in the automatic Utility Classes folder.
Finsweet Extension will automatically group classes with a matching first keyword. Below is a screenshot of the Client-first starter cloneable project. The classes are carefully organized.

Inside the Utilities Classes folder, we can further classify utility classes by using the first keyword of the class name.
Ok, short version done. Now let's be pros with the new Client-first Folders feature!

Custom class folders

Custom class folders are indicated by an underscore in the class name.

folder-one_folder-two_element-name
Imagine folders in Client-first like folders on your computer. We give a name to a folder and put items inside. This is how we organize our computer.

In our Webflow project, we can use folders in the same way we use our computer's folders. Folders can have items in them and folders can be nested in other folders.

Items inside folders are html elements that make up our web page. Folders help us group, search for, and access the html elements. We can use a folder system that helps us access the styles of specific html element in our project.

A folder in Client-first is grouping of custom elements that exist to create [something].

This [something] can be a:
- Tiny group of elements on the page
- Small part of a section
- Section
- Group of sections
- Page
- Group of pages
- Recurring element

The approach you take to group your elements depends on your project specs. The specs, the size, and many other factors can influence how you organize your folder structure for that project. Each project is different and therefore should be organized differently.

How many pages are in the project?

Is the design and layout for each page unique?


Are there recurring elements?

The answers to these questions can greatly influence the way you organize your project's folders.

Similar to our web project, a computer's files are different from other computers. Each computer should be organized based on what files are on the computer. A computer with 10,000 files would have different folder organization than a computer with 100 files. In your Client-first project, the amount of folders and levels of organization should relate to the amount of items you need to put in them.

Folders can be nested to achieve maximum flexibility for folder use. We may want to have a well-crafted multi-nested folder structure for larger websites with more organization requirements. We may want more simplified single level folders for smaller more custom websites.

There is no limit to how many folders you have in your class name. The organization rules are your choice as the developer.

Don't abuse folders with unnecessary nesting

Don't nest just to nest. We're making Folders are the new cool in Webflow. That doesn't mean use them everywhere. Only nest folders if it's meaningful for the project. Over nesting or nesting with no purpose can make your project difficult to manage.

Having too many folders for a small amount of items makes navigation of your items more difficult on your computer. Searching through nested folders can be frustrating. The same applies with folders in Client-first. We want to be able to quickly find elements, not search through nests of folders. Use folders responsibly and with purpose.

Always remember the definition of folders in Client-first — Folders are a self-organization tool to group and manage custom classes in the project. Make sure to use them to best manage your Webflow project.

Folder underscores

Folder underscores are for custom classes, not utility classes

A folder is created with an underscore. The underscore character is your ultimate folder creation tool.

Although folder underscores can be used for any type of organization, Client-first will focus on creating folders for custom classes, not for utility classes.

A custom class is a class created for a specific component, specific page, specific grouping of elements, or a single element. For example, a class to style the team slider or a class to style the global headers for the project.
Custom classes use an underscore.


A utility class is a class created with a specific, usually simple, combination of css properties that can be applied to elements across the project. For example, a class for background-color or a class for font-size.
Utility classes will not use an underscore.


Let's triple confirm we understand the difference between utility classes and custom classes in Client-first. It's crucial in properly using the new Folders feature.

Example of utility classes

No underscore. Classes to apply one or two css properties.
text-color-black
text-color-white
text-color-blue
text-size-large
text-size-medium
text-size-large
padding-top
padding-large
page-wrapper
page-padding

Example of custom classes

Uses underscore. Classes for something specific in the project.
home-testimonials_wrapper
home-testimonials_headshot
home-testimonials_text-small
header-top_content
header-top_image
header-top_accent-left
careers_custom-padding
careers_title-animation
careers_scroll-trigger
This is no change from the initial release of Client-first. "Components" are indicated by an underscore and "global classes" are indicated by dashes only. This is the same rule. There is no core change in how you use Client-first.

We're just better defining the way we talk about elements — "components" and "global classes" are now more broadly defined as "custom class folders" and "utility classes".

Components  >>>  Custom class folders

Global classes  >>>  Utility classes

The folders feature will allow an additional layer of organization and custom class management. Folders add a new dimension to custom classes, components, and visual class management inside Webflow.

Creating a folder

We create folders with underscores.

One underscore ( _ ) equals one folder

Below we show class names and how those class names translate to folders. We can see the "home-testimonials", "header", and "careers" folders.

Class names

home-testimonials_wrapper
home-testimonials_headshot
home-testimonials_text-small
header-top_content
header-top_image
header-top_accent-left
careers_custom-padding
careers_title-animation
careers_scroll-trigger

Generated folders

The name of the folder is generated based on the the keyword(s) that comes before the _.
We have many options for how to name folders and how to organize them inside our project. Similar to your computer, we have many options for how we organize the files on our computer.

Some websites may be better organized with one folder level. Others may be better with two folder levels. And others may be better with a mix. We will better understand how to approach this in the Strategy section.

Creating a nested folder

We create a nested folder by adding a second underscore.

Let's continue with the example above. Below we have two sets of custom classes each with a different folder structure. Our one folder level example has one underscore. Our two folder level example has two underscores.

Example of one folder level

home-testimonials_wrapper
home-testimonials_headshot
home-testimonials_text-small
header-top_content
header-top_image
header-top_accent-left
careers_custom-padding
careers_title-animation
careers_scroll-trigger

Example of second folder level

home_testimonials_wrapper
home_testimonials_headshot
home_testimonials_text-small
home_header-top_content
home_header-top_image
home_header-top_accent-left
home_careers_custom-padding
home_careers_title-animation
home_careers_scroll-trigger
By adding a second underscore, we are nesting a folder.

The "home" folder is the first level folder. There are three nested folders inside "home" — "testimonials", "header-top", and "careers".

Custom class folders can be named, nested, and organized in any way.

Automatic utility folders

Utility folders are indicated by no underscore in the class name.
Dashes only!

firstkeyword-identifier-otheridentifier

Example utility classes

text-color-black
text-color-white
text-color-blue
text-size-large
text-size-medium
text-side-large
padding-top
padding-large
page-wrapper
page-padding
Identifying a utility class is as easy as this —

No underscore = utility class.

All utility classes will go in a folder called "Utility Classes" inside your folder list. This folder is automatically generated for your project and it will always be the first folder in your list of project folders. It can't be changed or renamed.

In the above class list, Finsweet Extension will automatically create nested utility folders, "text", "padding", and "page". These are the first keywords of each class name.

These automatic nested folders will hold the classes of that keyword. As seen below. The "text" folder has "size-small", "size-medium", "size-large", and more.
Nested folder names inside the Utility Classes folder are strictly generated based on the first keyword of the utility class name. Finsweet Extension creates a nested utility folder when there are two or more utility classes that share the same first keyword.

We can continue to add or remove nested folders from our auto-generated Utility Classes folder. Following Client-first naming convention, we can continue creating grouped utility classes.

For example, a class grouping to style box-shadow:

shadow-box-large
shadow-box-small
shadow-circle-large
shadow-circle-small

With these classes, we have just created a "shadow" folder.

Below is a screenshot of the Utility Folder of a fresh Client-first starter cloneable + the above example that was created after cloning the project.
We can more easily manage the classes that are shipped with default Client-first, as well as any new utility classes added to the project.

Strategy: Custom class folder organization

Most of this article is about the custom class folders. Using these strategies can give more clarity to our Webflow projects.

Different projects have different requirements. There are different designs with different layouts. Different post-project maintenance strategies. All of these factors can go into our folder naming strategy for the project.

This folder add-on to Client-first was built to offer flexibility in how you name and organize folders. Remember that Client-first is "One naming convention for every person, for every project." We mean it when we say it. For this to be true, we need flexibility in our naming system.

There is often no right or wrong to naming. There is only more and less efficient.

High efficiency in Webflow is best achieved when your build strategy is customized for the project you are developing. Below we show many different naming strategies with different folder organization styles.


Examples below

Below are many different examples and use cases for different folder naming strategies. It's important to understand that you should not use all of the strategies in a single project. There should be some unification of strategies when you implement your folder naming convention. Ideally, there should be an overall plan for the folder naming convention before your start developing.

Let's review each example and explain when we may want to use it.

One folder level, general folder name

Useful for creating components that are not specific to any page or content. As naming becomes more general, it can be more clear that the folder is used globally throughout the project. This is great for core recurring elements in the project.
one-folder_name-of-element
nav_
nav_component
nav_logo
nav_logo-link
nav_cta
header_
header_component
header_background
header_content
slider_
slider_component
slider_arrow
slider_page-count
slider_mask
slider_slide
... and 2 more
form_
form_component
form_outer-wrapper
form_inner-wrapper
form_input
form_label
...and 8 more
footer_
footer_component
footer_content
footer_link
footer_logo
footer_column
...and 1 more
styleguide_
styleguide_page-wrapper
styleguide_content
styleguide_header-title
styleguide_header-description
styleguide_example-wrapper
... and 74 more
contact_
contact_header
contact_cta
contact_title-custom
contact_pre-footer
contact_phone-link
... and 21 more

One folder level, specific folder name

Useful for creating any type of custom folder, regardless of project size. Add the page name to give context into its relation to page. Add content-specific keywords to give more information about the reason for the class.

An entire website can be named with this strategy alone. Before the release of Folders, all Client-first projects were organized with this one folder strategy. If you view your folder structure in a pre-Folders Client-first project, and you've correctly followed Client-first, you will see an organized folder structure filled with single level folders.
one-specific-folder_name-of-element
home-testimonials_
home-testimonials_component
home-testimonials_headshot
home-testimonials_name
home-testimonials_title
home-testimonials_layer-3d
... and 3 more
about-testimonials_
about-testimonials_component
about-testimonials_long-layer
about-testimonials_short-layer
about-testimonials_feature-item
about-testimonials_headshot
... and 12 more
featured-clients_
featured-clients_component
featured-clients_list
featured-clients_item
featured-clients_header
featured-clients_scroll-trigger
... and 22 more
clients-slider_
clients-slider_component
clients-slider_arrow
clients-slider_page-count
clients-slider_mask
clients-slider_slide
... and 6 more
contact-form_
contact-form_component
contact-form_outer-wrapper
contact-form_inner-wrapper
contact-form_input
contact-form_label
... and 8 more
case-study_
case-study_header
case-study_title-wrapper
case-study_title
case-study_header-video
case-study_section-break
... and 32 more
blog-nav_
blog-nav_component
blog-nav_logo
blog-nav_logo-link
blog-nav_subscribe
blog-nav_input
... and 16 more

One folder level, page name as folder name

Useful for creating a folder of classes that are specific to an identifiable page. If you are creating a new page, and that page has custom components completely different from the rest of the site, these components may be best classified inside a a single page folder.

This is a good strategy when there aren't many custom classes for the page. If there are 50+ classes for the page, or complex components on the page, organizing all of them into one folder may be not be the best approach.
page-folder_name-of-element
home_
home_testimonials-headshot
home_testimonials-name
home_testimonials-title
home_testimonials-layer-3d
... and 3 more
about_
about_testimonials-long-layer
about_testimonials-short-layer
about_testimonials-feature-item
about_testimonials-headshot
... and 12 more
featured_
featured_clients-list
featured_clients-item
featured_clients-header
featured_clients-scroll-trigger
... and 22 more
clients_
clients_slider-arrow
clients_slider-page-count
clients_slider-mask
clients_slider-slide
... and 6 more
contact_
contact_form-outer-wrapper
contact_form-inner-wrapper
contact_form-input
contact_form-label
... and 8 more
case-study_
case-study_title-wrapper
case-study_title
case-study_header-video
case-study_section-break
... and 32 more
blog_
blog_nav-logo
blog_nav-logo-link
blog_nav-subscribe
blog_nav-input
... and 16 more

One folder level, page name as element prefix

Useful for creating unique variations of a component by page, while still staying in the default class structure for the component.

For example, every slider in the project has the same styles applied to it. The homepage has a unique variation of the arrow UI. This variation is not enough to call it a unique slider or to create an entirely different folder specifically for this variation. It's still styled like the rest of the sliders, with a few small exceptions.

With these variations we may want to use a page prefix as the first keyword of the class identifier. We can identify the page that the custom class is specific to, without creating an unnecessary new folder.

Can't I use a combo class for this? folder-name_arrow is-home

Yes, this strategy is similar to a combo class implementation. There may be a reason why you do not want to use a combo class implementation around this variation.

For example, the home arrow is so unique to the slider that it should not inherit any of the styles of the default slider arrow. It may be beneficial to start from a fresh class rather than try to update a class that has no relation to the styles you want to apply. In Client-first we prefer to create a new fresh class instead of force a combo class restyling on a base class. Simple rule — if the variation doesn't need to inherit the styles of the base class, don't create a combo class for the variation. We cover this topic in more detail later.

Instead, you can use this folder naming strategy.

Again — "There is often no right or wrong. There is only more and less efficient." It's your decision as the developer to decide which is more efficient based on the use case.
one-folder_page-name-of-element
slider_
slider_component
slider_mask
slider_slide
slider_content
slider_home-arrow
slider_home-arrow-trigger

... and 3 more
testimonials_
testimonials_long-layer
testimonials_short-layer
testimonials_feature-item
testimonials_about-headshot
... and 12 more
tabs-feature_
tabs-feature_list
tabs-feature_item
tabs-feature_clients-header
tabs-feature_clients-scroll-trigger

... and 22 more
slider_
slider_component
slider_page-count
slider_mask
slider_clients-slide
slider_clients-arrow

... and 6 more
form_
form_outer-wrapper
formI-inner-wrapper
form_input
form-contact-label
... and 8 more
footer_
footer_col-wrapper
footer_title
footer_link
footer_case-study-line
... and 32 more
blog_
blog_nav-logo
blog_nav-logo-link
blog_nav-subscribe
blog_tags-nav-input
... and 16 more

Two folders, page folder first

description
page-folder_keyword-folder_name-of-element
home_testimonials_
home_testimonials_component
home_testimonials_headshot
home_testimonials_name
home_testimonials_title
home_testimonials_layer-3d
... and 3 more
about_testimonials_
about_testimonials_component
about_testimonials_long-layer
about_testimonials_short-layer
about_testimonials_feature-item
about_testimonials_headshot
... and 12 more
clients_featured_
clients_featured_component
clients_featured_list
clients_featured_item
clients_featured_header
clients_featured_scroll-trigger
... and 22 more
clients_slider_
clients_slider_component
clients_slider_list
clients_slider_item
clients_slider_header
clients_slider_scroll-trigger
... and 22 more
contact_form_
contact_form_component
contact_form_outer-wrapper
contact_form_inner-wrapper
contact_form_input
contact_form_label
...and 8 more
case-study_template_
case-study_template_header
case-study_template_title-wrapper
case-study_template_title
case-study_template_header-video
case-study_template_section-break
... and 32 more
blog_nav_
blog_nav_component
blog_nav_logo
blog_nav_logo-link
blog_nav_subscribe
blog_nav_input
... and 16 more

Two folders, any organization

Remember we thrive on flexibility. Above show some clear use cases, but it's a fact that not every naming decision is clear. Sometimes we can fit perfectly into one of the above strategies. Sometimes we need to do something different to fit our use case.

You can use folders for anything. There are no strict rules when it comes to custom class naming conventions. Anything works, as long as it's clear what the organization strategy is accomplishing.
anything_anything_name-of-element

How we can take advantage of folders

We will use the two folder examples below for the explanation.

Specific keyword folder

clients-slider_
clients-slider_component
clients-slider_arrow
clients-slider_page-count
clients-slider_mask
clients-slider_slide
... and 6 more

Page folder with a nested specific keyword folder

work_clients-slider_
work_clients-slider_component
work_clients-slider_arrow
work_clients-slider_page-count
work_clients-slider_mask
work_clients-slider_slide
... and 6 more
  • Explain the purpose of the class

    We get context into the reason the class is inside our project. This is arrow class exists because of the clients-slider. The folder on the right shows thee page identifier version. We know the arrow exists because of the clients-slider on the work page. There is a lot of important information about this arrow element from the folder naming. This is the reason the arrow exists in the project.
  • Group or categorize related custom classes

    Make groups of classes that do [something] together. Folders allow us to organize our elements and classes into groups. In the above example, have made a group of classes called clients-slider. If this is enough context we need for our project, we can keep 1 folder layer. If our project is very large or has several unique clients sliders, we may want another folder level. We can add work_ to create another layer of grouping and categorization.
  • Search for custom classes

    We can use Webflow Designer styles panel like a folder directory. We can search "clients-slider_" in the Designer styles panel to see every class in our clients-slider folder. We can search through multiple levels of folders in the styles panel to easily find classes throughout our project. For example, typing "work_" to see all of the classes related to our work page.
  • Define complete copy-paste structures with components

    A "component" in Client-first is a special way group elements. A component is a group of elements that create a complete visual ui element. Use _component as the element name to define a complete component. In the example above, we have our clients-slider folder. By setting the class clients-slider_component on the wrapper of all clients slider elements, we are declaring the wrapper as the outermost layer of the component. Copying this _component layer is copying the entire clients-slider_ component folder. It's the official wrapper of the entire structure. _component can be used but is not required for every folder. We may want to add _component to our clients-slider_, about-testimonials_, header_, and nav_ folders since these are created specifically for a complete visual ui element. Being able to define a folder as a _component gives us a lot of context into why this folder exists. More on components below.
  • Understand location with page names

    Define elements usage by including, or not including, page names in the class name. We can understand where classes are located in our project with a clear naming convention around it. Is the class specific to a page page? Is it general and potentially used globally? By adding the page name to page specific classes we can give location context. If there is a Work page on our website, we will understand that the work_clients-slider_component is specific to the Work page. If we have many client sliders on our project and have a class of clients-slider_component, this may be a global component used throughout the project. If there is no page name in the class name, we have a clue that the class is not specific to a page.
  • Improve the build while scaling

    We can improve the scalability of our project by renaming folders while we build. If we start using work_clients-slider_ folder classes on the case study page, we can decide to spend a few minutes renaming the work_clients-slider_ folder name to clients-slider_. It's no longer specific to the "Work" page. We can turn folders that used to be page specific into global components by simply* removing the page identifier in the folder name. As we are building more pages, it's valuable to have more non-page-specific folders and components available for use as we build pages.

    *Using our new Finsweet Extension feature, you're able to bulk rename classes and reorganize Client-first folders inside your project.
  • Better define custom classes vs. utility classes

    Using underscores in the class name, we can define a custom class. We get a lot of context about a class if we understand if it's a utility class or a custom class for a specific element. If custom and utility classes are properly named, our Client-first folder strategy automatically separates and organizes these classes for us. This can help us work quicker with better sense of project organization.

Page names in class name

The decision to add a page name in a class name is powerful. We have many ways to organize where the page name shows in the class. As with naming the folders on our computer, there is no right and wrong — only more and less efficient.

To summarize the examples above when using pages, our clear options are:

1. Page name as folder name
[page]_element-name


2. Page name + keyword as folder name
[page]-keyword_element-name

3. Page name folder, nested keyword folder

[page]_keyword_element-name

5. Page name as element prefix
keyword_[page]-element-name

Below we will go through questions to ask ourselves with each project. We will understand when to use page names and how we can take advantage of them.

We can give more clarity and context to our components by adding the name of the page. We can tell ourselves, and the next developer, that this class is specific to a page.

We can give equally as much context by not using the page name for our components. We can tell ourselves, and the next developer, that this class is not specific to a page and can be used globally on any page.

Page names may go in the in the component name. They may not. Keywords can be mixed with page names. Keywords can exist alone without page names. The answer always depends on your project and organization strategy.

To make better decisions for page name use, we can ask ourselves these questions:

Is this element styled for this page only?

If there is a class that is created specifically for a certain page, it may be best to use that page name in the class name. The class has a specific purpose to do [something] to an element on that specific page. Adding the page name is giving a lot of context into why this class exists on the site.

Here we show three examples of page names in the class name. Each example has two naming options — one folder level and two folder levels.

page-topic_element-name or page_topic_element-name


1. home-slider_arrow or home_slider_arrow

2. team-slider_arrow or team_slider_arrow

3. portfolio-slider_arrow or portfolio_slider_arrow

Remember that adding the page name is your decision. Your ultimate end goal is to create a project that makes your job easier and allows the next user to edit the Webflow project effectively. If the context of the page name will help you use the project better, then add the page name.

Is this a reusable element throughout the project?

If reusing components and elements across the project is required for your build, it may be best to not use the page name in these class names. You may be best using the keyword as the base level folder name.

We don't want to define our components as specific to a page if the component is not specific to a page. If it is meant to be used elsewhere in the project, there should be some indication of this in the class name.

Here we show several examples of reusable elements that are not specific to a page. Based on the project they are used in, their naming is general enough to make it clear they are reusable.

specific-topic_element-name

slider_arrow

header_image-right

subscribe-form_input

clients-logos_row

When naming is very general with no page name is present, I can make better assumptions as a new developer entering the project. The class slider_arrow is very general and can likely be used on all or most sliders. With the Styles panel stats, I can see this used 2 times on this page and on 4 other pages. I have enough information to assume that this is a reusable element in our project.

If I was building a new page in the project, I would be comfortable using this class without renaming it. I would also be sure to not accidentally edit other instances with styles unique to the new page.

With page name in the class name, I can confirm that this class is specific to this page. It will not conflict with other pages. Without page name in the class name, I will approach this class as a global class in the project.

When to use page name (or specific keyword) as the element prefix?

Let's continue with the example in the previous section. We have our slider_ folder that is meant for use across our project.
slider_
slider_component
slider_mask
slider_slide
slider_content
... and 3 more
As discussed above in the folder examples section, we will learn when to avoid using a combo class and instead use the page name as the element prefix.

Imagine there is a variation of the slider on the testimonials page/instance. The testimonials page testimonial has a different arrow setup. It is a variation that is completely unique from the default slider_arrow. Everything about it is different.

This testimonials slider shares all of the core styles of the slider component, except for the arrows. Since it is such a minor variation from the entire component, it does not make sense to rename everything as the testimonials-slider_ component. We still want to use our default slider styles to stay consistent across the project. The variation is not significant enough to create a new component. We only need custom arrows for the testimonials page.

We can either use combo classes or a new custom class with the page name as the element prefix. First we will show the custom class approach.

This shows the slider component with two testimonial specific classes. We are not creating a unique folder. We are further specifying the element inside the default slider_ folder.

Both slider_testimonials-arrow and slider_testimonials-arrow-trigger use the word testimonials as first keyword of the element name.
slider_
slider_component
slider_mask
slider_slide
slider_content
slider_testimonials-arrow
slider_testimonials-arrow-trigger

... and 3 more
Why we may not want to use a combo class

In this same example, we can alternatively apply a is-home add-on class for the slider_arrow class. The combo class would be:

slider_arrow is-testimonials

This will use the base styles of the slider_arrow and then customize styles further with the combo class. This works really well if we want to use the base styles of the slider_arrow and add on top of them.

If we want to inherit the slider_arrow styles for the testimonials instance, we use the combo class method.

If we do not want to inherit its styles for the testimonials instance, then we should not use a combo class.

In our example, the arrows were described as completely different. They do not require any of the styles that are used in slider_arrow. Inheriting styles that are not needed for the element variation leads to a difficult build to manage. In Client-first, it's recommended to use a fresh custom class for the variation rather than use a combo that reverts all or most of the styles of the base class.

We lose a lot of power when our base styles are incorrectly supplying inherited CSS property declarations to elements across our site.

Imagine our slider_arrow has display: block applied to it. slider_arrow is-testimonials inherits this style and it has no influence on the layout for the testimonials instance. Now you change slider_arrow to display: flex and all elements with slider_arrow are changed to display: flex, including the testimonials instance.

This change breaks the layout of our testimonials instance, and this layout break is not immediately known. We may publish our website not knowing that we broke the layout on the testimonials page. In this example, we can avoid this layout break by using a initially using a custom class for our instance-specific element.

One folder vs. two folders

Folders must be used with purpose. Just because we can nest folders doesn't mean we should always nest folders. The size of your project and level of organization required should be the two core factors in the decision for levels of folder nesting.

If your clients folder has 100 different items across different instances, it may make sense to use a nested folder to further organize these classes. It may be beneficial to have an additional layer of organization for those 100 different items.

If your clients folder has 12 items in it, it may not make sense to have a nested folder. Do we need to further organize the 12 items? Maybe, but likely not.

The decision to use one or two folder levels for your project is completely up to you. Understand that you can have parts of your project that use one folder level and parts that use two folder levels. The amount of folders can be customized in any way that you want.

Example using computer analogy

Let's look at an example using the computer folder analogy.

Example: We have an excel file with all of our university test scores. We need to organize this file on our computer.

>We have base level folders "School", "Work", "Side-hustle", and "Personal"
>> Inside the "School" folder we have "Primary", "University", "Masters Degree".
>>> Inside the "University" folder we see our file "university-test-scores.xls"

This is a folder structure that makes sense for a lot of computers. Different parts of your life get a different base level folder. There are hundreds of files inside each of the "Primary", "University" and "Masters Degree" folders.

Trying to group all of the files into one folder called "School" would not be organized. If we wanted to find files specific to "University" it would be difficult if all three schooling levels were in the same folder. It would be difficult to fund our one file out of hundreds of files. Creating the second level of folders gives us a further level of organization that works really well in this use case.

Now imagine a computer of a young primary school student. They don't have work or a side-hustle. They only have "School" and "Personal". There is far less files on the primary school student's computer than the masters degree student who has been using their computer since primary school. For our young high school student:

>We have base level folders "School" and "Personal"
>> Inside "School", we have a total of 12 files. The student doesn't have many files for school. We can easily find our file "university-text-scores.xls" among those 12 files.

It may be more difficult to find the file if there were further levels of folders. More clicks and more thinking about how the file should be organized. If we don't need a folder to create further organization, we should not use a nested folder.

Nested folders should help us work quicker, not slower.

Component libraries

Above in the folder naming examples, the last example shows anything_anything_element-name as the an option. We will show an example of this with a component library use case.

Folders introduce a huge organization upgrade to component libraries of all size. Relume Library will benefit greatly as a Client-first component provider. Nesting folder provides a powerful organization upgrade to work even faster in Webflow.

In a component library, we may want to organize classes like this:
slider1_component

slider2_component

slider3_component

grid1_component


grid7_component

logo-row1_component


logo-row2_component
In component libraries, we are given reusable components that can be used anywhere in our project. There's no proper way to name components in a component library to be instance specific. The intention of the component is to not be instance specific.

Each one of these components would be a base level folder. Every folder in the project is a one folder level setup. If we have a relatively low amount of components in our project, this may be a good strategy. If we have many components, each with many variations, this naming may not be efficient.

With the addition of one underscore we can further organize our components to better handle variations and deep component libraries.

The same classes have been re-written to include a nested folder with the variation number.
slider_1_component

slider_2_component

slider_3_component

grid_1_component


grid_7_component

logo-row_1_component


logo-row_2_component
Look at the beautiful output this naming convention gives. We can organize all of our component types as base level folders. As we click into each folder, we see how many option variations are available to us. Each variation is clearly defined and organized in its own folder.

For extra super large component libraries with variations of variations, it may be smart to use three folder levels. The organization is always your decision.

Renaming the general numbered folders after you have copy-pasted the component to your project is now seamless with Finsweet Extension.

Using Finsweet Extension, you will be able to bulk rename any folder name. This means you can copy layouts_grid_1_component
into your project and bulk rename every element in this folder as team-grid_component
. This renaming takes seconds inside the extension.

This is a major upgrade to the usability and organization of component libraries using Client-first.

Using the component keyword

The initial release of Client-first defined components as this:

Components in Client-first are 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.

Components have always been defined as using an underscore in the class name.

All of this is still true. In this folders update, we will be more specific when we are using components — and more specific when using underscores!

Initial release
underscore = component

Folders release (current)
underscore = folder and _component = component


Using a folder underscore in the class name does not necessarily mean the folder is a component. We can use folders for organization or groupings of elements.

Components now have a specific classification. If we want the folder to be a component, we use the word "component" for the element identifier. Using this keyword tells us that this entire folder is a component — a group of page elements that create a complete ui element. We show many examples of using the "component" keyword in the beginning of this strategy section.

For example, we may have a clients slider on our website. This clients slider is a component. On the parent wrapper of all elements of the clients slider, we would add our component keyword.
client-slider_component
client-slider_mask
client-slider_slider
client-slider_arrow
This tells us that the clients-slider_ folder is a component. If we copy this component wrapper to our clipboard, we will be copying the entire component.

Remember not everything needs to be a component. Things like a newsletter signup, team grid, pricing calculator, reusable 3 column grid, or a clients list are all great examples of components. Sometimes we will want to use folders for groupings other than components.

For example, a style guide folder. If your Webflow project uses a style guide, you will likely need to create classes for the style guide. The style guide classes may be on one page. They may be used across several pages. There is no single copy-paste "component" of the style guide classes.

To organize our style guide classes, we can put them in a folder specifically for organizational purposes. No component required.
styleguide_structure
styleguide_content
styleguide_item
styleguide_sidebar
Let's look at an example where the folder name is organized by page. Imagine a unique "Culture" page in the project. This page may have styles that are shared across the site, but there are different components and sections throughout. We may want to organize all of these classes by the page.
culture_header
culture_accent-flash
culture_pre-footer
culture_cta
culture_section-divider
These classes are not created for a single component. The elements are being organized by a page on our project. There is no single wrapper to copy and paste a complete ui element. There's a collection of custom classes that were created for the "Culture" page.

Folder decision making tree

There are a lot of decisions to be made when you are organizing your project. Some of the decisions need to be made before you start developing. Many decisions will be made as you're developing.

When we first start making these decisions, it may be time consuming. Make quick intelligent decisions comes with practice.

Understand that making decisions for folder names is something that you will improve on as you continue to use Client-first. Your speed and accuracy will improve as you continue to use the Folders feature in your projects.

We have developed a decision making tree to help you understand how to make quick decisions about class organization.

In the decision tree below we will look at an example of a naming decision for a 'slider pane' element of a slider in our project.

Click on the decision tree image to expand it in a modal.
Flow chart showing the decision making process for naming folders.
It may have taken a few minutes for you to read this graphic. You will not need a few minutes to make decisions about naming. As you continue to apply this logic to your class naming decisions, you will make these decisions faster. With practice, trial, and error, you can make these complex decisions quickly.


Is there a question you have that was not answered in the docs? Let us know on Twitter.

Next: Classes

Learn about the classes that come with the Client-first cloneable
fs-arrow-icon