How to make more flexible and complex components in Webflow

Components in Webflow have a lot of potential and are a really powerful tool, but due to their high level of complexity it can be difficult to know how best to utilize them. In this article I’m going to explain some key strategies for stepping up how you use components so that you can create components that are more powerful and flexible.

At the bottom of this article I’ve linked to a Webflow cloneable that utilizes some of the strategies in this article. I use those particular components as examples throughout the post so feel free to reference the cloneable as you read in order to examine their structure in more detail.

First off, a disclaimer

Admittedly, the user experiences of editing components still needs some improvement; knowing when you’re editing an instance vs the global component can be confusing. Hopefully with improvements like the recent change to allow double click editing the user experience is going to be more straightforward. Even so, there’s definitely a case to be made that just because you can turn something into a component does not necessarily mean you should or that it will be the easiest option in terms of editing and maintenance.

All that being said its up to you to decide which strategy will work best for a specific section or build. Hopefully this article will help you understand some of the more advanced capabilities of components.

Strategy 1: Using visibility overrides to create alternate layouts

The first main strategy when making complex components is using visibility overrides to create multiple layout styles. In the cloneable each of the gallery sections is built from one component but within the component there are multiple divs the each have a different layout and they can be shown or hidden based on visibility overrides.

One of the key things to note when using this strategy is that you need to use the same properties for the content within each layout. In the gallery I have six images and when I change the layout the images don’t change. This is because I bound the first image in all four of the layout options to the same Image 1 property. If I was to use separate properties for each grid it would get much more confusing and instead of 6 image properties it would have 24 image properties which makes the component much less manageable.

Visibility Property vs Conditional Visibility

You may be wondering if this is an issue for website performance because this strategy means that each component now has 24 images inside it instead of the 6 that are going to show up. Thankfully it actually works without any performance side effects (other than potentially slowing down editing within the designer) — this is because Webflow actually removes elements that have a visibility property set to hidden from the DOM on the published site, meaning they don’t load at all. This is different from using Conditional visibility in CMS lists or CMS pages because if an element is hidden that way it just sets the display to none but doesn’t actually remove the elements from the DOM. Because of this difference, you need to be more careful when using conditional visibility in CMS lists due to the potential performance issues, if you were to have 6 layouts in a CMS item and only one was shown the browser would still have to load the HTML of all the hidden elements it just won’t render them on the page.

How to set this up

What I would recommend in terms of setup is having a parent component that has few to no styles and within that having several divs with unique classes for each of the types of layout you want. In the gallery example I have four unique layouts gallery_offset, gallery_horizontal, gallery_vertical, and gallery_unique. For each of the layout divs I created a unique visibility property, I set one of them to be visible by default and the rest to be hidden by default. Within each of those divs I have the same 6 images each with a wrapper div (so that I could create a scale hover effect). If you need to give some of the images or image wrappers unique styling to work within that layout you can give them a combo class of .is-vertical (or something similar that matches name of the layout you are using.

There you have it, now you can just style each of the unique layouts however you want using flexbox, grid or whatever else.

Another note on structure

You may have noticed that the parent symbol is not actually the gallery_component but the section_gallery. This choice can be left up to you, in the above example I’m using the Client-First naming convention and structure and thought it would be simpler to make the component an entire section. By structuring it this way it is easier for clients or other editors to drop a gallery onto a page and not worry about the other structural divs within a section. The downside of this is that it locks in the vertical padding and the container size as a part of the component so you can’t have galleries with unique padding or a different max size. An alternative is to create the component at the gallery_component div and then you have more control over the spacing around it but also its less easy to drop into a page.

That covers one of the main strategies for creating more unique components, but I also have another strategy where you can create alternate components without having multiple layout divs and just using some custom code.

Strategy 2: Custom CSS in components.

Another helpful tool for creating more complex components is writing some custom CSS to override specific properties and then triggering those overrides using visibility properties.

How it works

In order to set this up the HTML structure is really important. You need to have a parent div (I would keep component in the title somewhere) and within that you first have several divs that you are going to use to trigger custom settings. In the cloneable I created a component called Header and use it with several different layout options along with a dark theme option.

*Important, the trigger divs need to be before the divs they are affecting in order to correctly target them with CSS. I’ll explain this in more detail below.

Next what we’re going to do is give each of those divs a unique visibility property based on what you want them to affect and then write some CSS to target the header_layout when that div exists.

As an example, in the Header component above I created a div called header_reverse layout and gave it a Visibility property with a default of hidden. Now what I can do is select the header_layout only when it has a previous sibling of header_reverse layout and change the flexbox direction to switch the image and the text.

 /* If there is a sibling with .header_reverse-layout before the .header_layout */
/* Flip Direction on Desktop and Tablet */
@media screen and (min-width: 768px) {
	.header_reverse-layout ~ .header_layout {
  	  flex-direction: row-reverse !important;
	}
}

And this is the final result.

In the cloneable I also added an option to have a vertical layout and an option to have a dark mode which add a bit more complexity but I won’t go into full detail explaining those since it is the same concept with just a bit more complex CSS.

A Major Drawback - Inconsistencies in designer

There’s one important thing I want to note about how this works within Webflow that you’ll notice as soon as you start playing around with the cloneable. The custom code does not work as expected within the designer even though it works as expected on the live site, but why?

The reason for this is that Webflow needs to actually load the html within the designer, so the html structure does not always match the settings of the component within the designer. This means that the CSS selectors used in the custom code might not trigger in designer or could trigger when you don’t want them to. There is no direct solution for this but you can have different results within the designer itself based on where you put the custom CSS.

Option 1, CSS in the head of page or site settings.

This option is in a sense the simplest, by putting the CSS styles for the symbols in head of the site they won’t render at all in the designer and you can just work off of the default styles of the component knowing that you can override things and they will change on the live site. It will be important to check your staging domain to make sure you have everything set up the way you want before pushing changes to your primary domain.

Option 2, CSS within a Global on Page Embed

Another option is for you to put all of the CSS settings in a Global Styles embed. When you do this all of the CSS overrides will be triggered regardless of whether the properties are switched to  visible or not. Once again, they will work correctly on the live site but will not work as intended within designer so you’ll want to check your webflow.io domain before pushing changes live.

Option 3, CSS put within each conditional div

The last option is to put the relevant styles for each unique override within the div that controls that override. See the image below as an example.

By doing this Webflow will actually render the symbol correctly within the designer as long as there is only one of that symbol on the page. However, if you have two Header components and one has the Reverse Layout property set to visible, then both of them will appear reversed even though only one of them should. So in this option it can still be a bit misleading but it is often more consistent with the live site than the other two options.

One final disclaimer, because this third option includes the styles within the component rather than at the top of the page it could have some minor negative affects with performance because styles will be changing as the HTML is parsed. That being said I really don’t know how much of an affect this will have as it depends on the situation.

Wrapping up

And that’s about it, I hope this was helpful in your understanding of Webflow components and all the possibilities they hold. In general I would recommend using the first strategy for unique layouts as that makes things easier to manage within the designer and overall less confusing, but the second strategy is really helpful when doing smaller color or stylistic changes (eg, having a transparent version of the navbar). You can check out the cloneable below to examine the examples I’ve set up in more detail.