Classes

Maintaining a Webflow Site

In order to make the project easy to manage by anyone from our team or our clients,
it is important that every member from our team names Webflow Classes in the same way.

This will result in less bottle necks and make the process of transitioning projects between team members much easier.

Transferring the Designs from Figma to Webflow

When kicking off a new project, it’s best to go over Figma in detail and fill in the Flow Starter template fully before kicking off Webflow development. This way, we'll make sure the design is following the best Web guideliness even before it hits the Web.

Sometimes you might take a day or two more in order to clean up the messy heading sizing or grouping items in Figma better, but it is well worth the hustle in order to transfer the designs to Webflow in a Shinobi like speed.

Migrating an existing site

If we’re migrating from Wordpress, Wix, Squarespace or any other platform we recommend: 

• Cloning the Flow Starter in Webflow
• Exploring the Wordpress site (For an example) and identifying Global Styles
• Filling in Headings and all other global styles like margins etc in Webflow
• Only then starting to develop the Homepage of the project

By using this process, we'll start having a system that will be much easier to follow later on.

We're sometimes end up standardising the site a little more and technically not copying it 1:1 like it was on Wordpress, Wix, Squarespace etc. Usually clients are fine with that if it results in a cleaner CSS sheet and easier site for management.

‍

Page Specific Classes

‍

{Page Name} Hero Image or {Page Name} Decoration 1 These are used only on the specific page.

Why would we use this?

Example: If we have unique Hero Image position and size on each page, having the Hero Image class for the homepage, will cause issues if we want to use Hero Image class on the About page.

Another thing to note, is that we should never use Combo Classes on these specific page classes.

Component Based Classes

‍

{Component Name} Card or {Component Name} Item We’re using these classes when creating elements that are going to be used on Multiple pages.

We should also cascade this down to other elements while creating the element.

For an example:

- {Component Name} Card

— {Component Name} Image

— {Component Name} Play Button

— {Component Name} Column

These should also avoid having combo classes, but we might have a use-case where we need to change the BG color or add margins left right bottom, and in that case we can add for an example Testimonial Play Button BG Brand 200

‍

Global Classes

‍

{Class Name} Apart from the usual Global Classes like Button, Section, Container.. We’re also having some per project unique Global Classes.

Column

‍

We have a pre-set class for the Column. This really plays nicely with the Grid utility class and the global Container Class

This is basically the core of Ninja websites, templates and components.

It comes with:

• Position Relative
• Flex Left
  

It allows us to position elements in the grid without the need to create unique classes each time. It helps us span items across the grid and change span amounts per container basis.

This allows Webflow to really become a No-Code solution when developing layouts.

The great thing is we can add Utility Classes like:

• Flex Center
• Max Width M
• Text Center
  

And enable even more layouts with a single global class:

‍

Button Wrapper

Button Wrapper allows us to position two buttons for the CTA next to each other with a simple grid:

Page Wrap

This element has the <main></main> tag selected on the Webflow panel:

‍

How not to name classes?

Classes that we should always avoid using are:

• Card
• Image
• Play Button
  

We’ve found that if we don’t specify where the class is going to be used, like a component or page + component, it is often going to end up with 5 combo classes in order to fulfil each need for the project.

So we need to avoid naming elements with classes that can be conflicted on different pages and maybe be used in different use-cases, thus ending up creating a mess of class system.

Image and Icon Classes

Icons

‍

Ideally we would try to avoid classes for Icons. But sometimes we cannot get over that and we name them like:

• {Component Name} Icon
  

But ideally we would stick to

• Icon S
• Icon M
• Icon L
• Icon XL
  

We’re always using Image Element for Images in order to apply Lazy Loading. So we should try to avoid using Images as Backgrounds on divs at all costs.

They need to have pre defined widths and heights set. Usually they also have a default margin added to them below or to the side.

We should try not to create more than 3/4 global icon classes, as we can override defaults with Utility Classes Like:

• Icon S No Margin
• Icon S Margin Right XL
  

So that these base icons can work in any instance.

Images

‍

Adding classes to images

When adding images to Webflow we need to use the Image Element in order for them to either be loaded Eager with the page, if they are in the Hero, or Lazy Load if they are below the fold.

Following many bugs we’ve encountered with Safari, Mozila and Lighthouse, we always need to have:

• Image Width that’s not 100% but specific in px, vw, rem or vh.
• Image Height that’s not 100% but specific px, vw, rem or vh.

If the parent element of the image has a set width or height, we can use 100%. But only in those cases. This will also reduce Lighthouse speed test errors.

Images should be named like:

• {Component Name} Image
• {Page Name} {Component Name} Image

A good example can be: Testimonial Author Image

We should always export the images at @2x from the original size so they are crisp on Windows laptops and on Retina displays also.

‍

Compressing images

All Images need to be compressed via https://tinyjpg.com/ before uploading to Webflow. Our designers usually prepare these files for the project, but from time to time or while doing revisions this might get overlooked.

So each one of our Ninja Webflow Devs, needs to make sure images are under 100kb when uploading to the project.

‍

Adding Alt Texts to Images

All images should have descriptive alt text added to them. Example of good alt texts:

• Webflow expert developer
• Webflow expert designer
• {Page Feature} {Image Description}
  

Bad alt text examples:

• Man 324
• Man Holding Beer
• Iphone Mockup
  

We should always try to be as specific as possible with images, and think if I was searching for this page would I search for a term that the image would show up on google.

Ideally the client can provide suggestion keywords from their SEO Consultant as we're adding default Alt texts for Accessibility and Lighthouse, but not recommending any SEO advantages for that practice unless we're given alt texts from an SEO consultant.

CMS Classes

Adding a CMS Component to the project always needs to have a specific set of classes added to it for easier management.

For an example:

{Component Name} Wrapper

- {Component Name} List

— {Component name} Item

{Component Name} Empty

In order to avoid confusion when adding the CMS items to other pages it is important that we have this specificity for each CMS Component.

Only Exception when we're not naming the CMS like this is when we are using the Swiper JS library.

In that instance we’ll be applying Classes to CMS like:

{Component Name} Swiper

- Swiper Wrapper {Component Name} List

— Swiper Slide {Component Name} Item
‍

We’ll be releasing a Swiper JS guide in detail over the following months.