stripo-modules-and-css
19 February

Stripo modules and CSS: Why they inherit template styles and how to keep your own

Anton Diduh
Anton Diduh Content writer & Video content creator at Stripo
Table of contents
  1. How modules and CSS operate
  2. Why do we design our modules this way?
  3. The benefits of not saving CSS 
  4. How to save your CSS styles
  5. Wrapping up
1.
How modules and CSS operate

This article explains the behind-the-scenes logic of Stripo modules. Why is CSS not added when saving modules? What benefits does this approach bring to marketers?

When using Stripo, you may notice that when you add your saved module to the template, the colors are different, and the font is not the same as the one you saved. Why is that? How does it work? This article will answer your questions as well as show you how to save your module styles if you want them to remain unchanged when drag-‘n-dropping your modules. 

How modules and CSS operate

Let’s start from the beginning and see how modules work in Stripo. We have a beautiful email element with new prices, and it’s time to save it as a module. This is easy to do — we just click the “Save as Module” button.

Saving element as a module

We can already see that the header font in the module preview is not the same as that in our email.

Saved module

We added this module to a different email, and now its appearance is completely different from  its original appearance. All the fonts in the module are now the same as the main font of the email, and the background of the module has also been changed to match the color of the template. Why does it work that way?

Drag-‘n-dropped module becomes different

Why do we design our modules this way?

These changes to modules, when drag-‘n-dropping them to different templates, occur due to CSS styles.

CSS styles come in two types:

  • general styles are created and changed through General settings. These settings shape the style of the modules in the colors chosen by the user when they drop the module into their template;
  • inline styles are CSS written inside the HTML code. They are saved with the module and will be like this when drag-‘n-dropped into any template. General styles will not affect them. This is necessary to create unique things that will appear as the designer intended them, making your modules rigid in terms of how they look.
Roman Burdyga

Roman Burdyga,

Team Lead, Design Unit; Product Designer.

Now, you understand CSS styles, but you may still have questions about why the module functionality is not saving all of your styles by default. Why didn’t we save the entire CSS at once? The answer is quite simple:

The whole approach to how modules and CSS work was deliberate from the beginning. The original idea of ​​modules was that each module saved in the module library would apply the template styles to which our user adds it. This makes sense from a design perspective because if I create an email layout, set its styles, and finalize its overall look, I expect the modules to also be in my styles when I add them. Therefore, CSS styles are not stored together with HTML modules.

Roman Burdyga

Roman Burdyga,

Team Lead, Design Unit; Product Designer.

In essence, by not storing the CSS in the module, we free you from the extra work of manually tweaking each module every time you add it to another template. This saves time, making email creation faster and more convenient — a significant benefit for any marketer. Talking about benefits...

The benefits of not saving CSS 

To clarify this matter completely, let’s talk about all the benefits that our modules operation logic brings to email marketers.

Benefit 1. Decoupling CSS from HTML for effortless design control

First, the logic of modules is built around the marketer’s convenience. When HTML and CSS are saved separately, the marketer can easily update the module design without editing the main HTML. As a result, the configuration of modules and templates is simpler and more manageable, especially when it is necessary to quickly change branding and tweak styles without having to go through the entire technical part of the email.

Benefit 2. Auto-adaptive modules for seamless template integration

The second pillar on which the logic of modules is based, and which we briefly mentioned above, is convenience. Since any module can be used in countless templates, it should be quickly adaptable to a new style. However, what if the modules needed to be edited manually for each template separately? In such a scenario, the whole point of modules — saving time and making the creation of templates easy — would be lost. Our modules automatically adapt to the styles of each template, which significantly saves time and makes the lives of marketers a little easier.

The fact that general CSS styles are not stored with the module makes it possible to use modules universally, without any headaches. Each module will fit a specific email style and does not need to be configured or reconfigured every time you use it. However, if you still need to tweak the appearance of some elements, you have the option to do so.

Roman Burdyga

Roman Burdyga,

Team Lead, Design Unit; Product Designer.

In addition, this approach gives the marketer the choice to have the template adapt to each email or make it unchangeable by using inline styles — you can do what suits you best. 

Benefit 3. Code weight optimization

The third pillar, no less important than the first two pillars, stands on the technical side of our subject — namely, the weight of the code. The heavier the email code, the greater the chance for email clients to clip the email in the recipients’ inboxes. However, when modules inherit CSS from the email template instead of including it directly in each module, the overall size of the email is reduced. The module contains only its HTML structure and inline styles (if you add them), and the rest of the CSS is applied from the template. This makes the email code lighter and ensures that the email loads properly.

How to save your CSS styles

Let’s fix the situation and save your module styles with inline styles. The basics are the same — an email element with new tattoo prices. However, before saving it to the module, we added inline styles, as follows:

  • by clicking on the title, we installed the font we needed, and it was written into the email code;

Fixing font with inline CSS styles

  • in the same way, we changed the background color, and the changes appeared in the code.

Fixing background color with inline CSS styles

We saved it as a module, so now it’s time to see the results. We have dropped our new module into the same email near the previous one, and voilà! The font style and background color remain the same as we previously set them for the module.

Drag-‘n-dropped module with unchanged design

We achieved what we wanted — unchanged module styles that we want to drop into other templates. 

Wrapping up

We created modules to achieve our main goal — to make the email creation process easier and faster. One of the tools used to achieve this goal is CSS logic under the hood. Without it, the whole point of modules disappears, creating additional steps when creating emails, such as tweaking the design of modules for each template. That’s why we give users the choice to use the pre-built logic out-of-the-box or to enhance the modules with easy-to-apply inline styles, leaving the modules unchanged when working in any template.

Create exceptional emails with Stripo
Was this article helpful?
Tell us your thoughts
Thanks for your feedback!
0 comments