How we handled partial HTML5 support — Stripo.email

Interactive emails need to work for everyone — no matter which email client they use. That’s why we build three versions of the same email:

• AMP: Powered by AMP HTML, this version lets users interact directly inside the email — with things like carousels, forms, games, or real-time updates. Supported by Gmail, Yahoo, and a few others;
• kinetic: Built with HTML5 and CSS3, it offers a lighter form of interactivity — like showing/hiding sections or supporting quizzes and polls. Works in Apple Mail, Samsung Mail, Thunderbird, and most modern email clients;
• static fallback: A simple HTML version that shows text, images, and links only. It’s the safest version and works everywhere, including Outlook.

This setup ensures that every recipient either enjoys the interactive experience or, at the very least, sees a fallback with the core message. Nobody is left out. 

At least we thought so…

The challenge with partial support of kinetic content  

We always assumed that if an email client supports kinetic content, it would handle everything inside it — buttons, toggles, forms, and all. But during testing, we found that’s not always true.

Take iCloud Mail web as an example. It looks like it supports kinetic emails — the design loads, and interactive elements appear. But when you try to submit a form, nothing happens. In contrast, Apple Mail handles everything as expected.

Apple Mail _ Recipients see their answer was submitted	iCloud Mail (web) _ We click on the Submit button but nothing happens

If that’s the case for iCloud, other clients may also have partial support. That got us thinking: How can we avoid showing a broken interactive version — and instead show a clean static fallback when needed?

That’s where things get tricky. Both the kinetic and fallback versions are built with HTML and share the same MIME-type. So, unlike AMP (which has its own MIME-type and falls back on its own), we can’t rely on automatic switching.

Instead, we have to manually control which version is shown — using CSS to hide or reveal content based on the email client’s capabilities.

How to combine static and kinetic HTML in one email section

Our goal was to include both versions in a single email section and display only one, depending on what the recipient’s email client supports. While we typically think of the static version as the fallback, in this approach, it’s the default. It’s shown when a client doesn’t support CSS interactivity. The kinetic version is revealed only if the email client supports HTML5 and CSS3.

We control this using class-based display rules and conditional comments. Here’s the basic structure:

    A simple HTML for the text version






    HTML for the interactive version

Key parts of the code conditions explained

• “Text version,” referred to as the static version above, placed inside a . It’s shown by default and acts as the safe version when nothing else works;
• “HTML version” is placed inside a
  . This version stays hidden unless the email client can handle interactivity via HTML5 and CSS3;

• the checkbox acts as a controller. With the help of CSS, it determines which version should be shown;
• the conditional comments () are used to hide the kinetic version from Microsoft Outlook desktop clients, which can’t render it properly;
• the mso-hide:all hides the content from Outlook.com;
• display: none hides it in most modern clients — until CSS rules say otherwise.

It’s important that the , , and

elements are placed right after each other, at the same nesting level. That’s because the CSS selectors used to control visibility rely on this order (we’re using sibling selectors like ~).

Adding styles to toggle visibility

Now we define the CSS that shows or hides each version based on what the email client supports:

What each part does

• the WebKit rule (@media screen and (-webkit-min-device-pixel-ratio: 0)) targets Apple Mail, iOS Mail, and Samsung Mail. These clients can handle HTML5 and CSS3 well. So here, we show the kinetic version and hide the fallback. This also works in WebKit browsers like Chrome and Safari if the email is opened in a browser preview;
• Outlook.com support: The selectors like [owa] make sure Outlook.com hides the kinetic block and shows the static fallback. [class~="x_container"], and [id~="x_fallback"] are used as a backup in case [owa] alone doesn’t work;
• Mobile Outlook: body[data-outlook-cycle] targets Outlook apps on iOS and Android. These don’t support kinetic interactivity, so we again force them to show the fallback and hide the interactive block.

Currently, in Stripo, we place this CSS directly at the beginning of the email body code because of how the editor works. But soon, you’ll be able to add it to the Custom CSS tab in the code editor. If you’re using a different editor, feel free to place the CSS wherever it works best for you — based on your editor’s structure and your preferences.

We’ve built a template that includes all the required code and versions. Explore it to review the setup, customize the content, and send test emails to see how everything works in action.

How it behaves in real life

Advantages of this method

Recipients will always see your message — no matter which email client they use. If interactivity isn’t supported, they’ll still see the static version. There’s no risk of an element being stripped out completely due to lack of support. Everyone gets the message, and no one is left out.

Cons of this method

Once you add the conditional code, you:

• won’t be able to edit the versions through the UI — only via the code editor; and
• in preview mode, you’ll see the kinetic HTML version, not the fallback. The static fallback version will be hidden.

We’re currently working on a switcher for the editor that will let you toggle between versions, edit each one through the UI, and preview them properly. This feature is coming soon.

What can you do now? First, build and fine-tune both versions — kinetic and static — either through drag-and-drop or the code editor. Once you’re happy with how everything looks and works, then add the conditional code snippets.

Don’t forget AMP

The code we discussed controls the static and kinetic versions of your email. But there’s also a third version to include: AMP HTML. It acts as the default when supported and is shown only to recipients using AMP-compatible email clients like Gmail, Yahoo, and FairEmail.

If AMP isn’t supported, the recipient will see the HTML version — either kinetic or static, depending on what their email client allows.

Here’s how it works:

• if AMP is supported (e.g., Gmail, Yahoo), the AMP version is shown;
• if AMP isn’t supported but the client handles HTML5 and CSS3 (e.g., Apple Mail, Samsung Mail), the kinetic version is shown;
• if neither is supported (e.g., Outlook), the static version is shown.

This way, each recipient sees only one version — never multiple layers or broken elements.

In our Interactive Module Generator, we combined all email versions into a single module — so users can design interactive emails with no code, right from the UI.

Testing your emails

To test your emails and see who receives which version, we recommend two simple approaches:

• use tools like Email on Acid. While you won’t be able to interact with your emails or verify whether forms work across all interactive versions, these tools show you exactly which version (AMP, kinetic, or static) appears in each email client;
• send test emails to yourself using as many email clients as possible. Even if you only have Gmail and Apple Mail, that can be enough. To check the AMP version in Gmail, turn on Dynamic content in your settings. To see the fallback (static) version — similar to what Outlook users see — simply turn that setting off.

When sending test AMP emails, be sure to add Stripo as your trusted sender. Go to your Gmail settings, then

• turn on the option to receive dynamic content (if it’s not on yet);

  

• specify us info@stripo-test.email as a trusted sender.

  

Wrapping up

Many assumed — just like we did — that if a client supports kinetic HTML, it supports all of it. But that’s not always the case. This method helped us avoid broken layouts and ensure every recipient gets a reliable version of the email. It’s not perfect yet, but it’s a big step toward safer, smarter interactivity.

Design interactive emails that work across all email clients with ease

Was this article helpful?


Yes

No

Thanks for your feedback!