Email Templates 2.0: enable containers and modules on <div> tags, not only on table elements

[Grégoire_Miche2]

The new email template V2 enable to create modules, i.e. email blocks that can be added by the user as needed to change the layout of an email.

This is such a welcome functionality that we are looking forward to be able to roll it out.

The only limitation is that these new elements only work on table html tags (<table>, <tbody>, <thead>, or <tfoot> for the modules, <table>, <tbody>, <thead>, <tfoot> or <td> for containers).

Depending on the developments approach, in the emails, this may work... or not. Many fluid development approaches recommend to limit the usage of nested tables, excepted for Outlook, and to mainly use <div> tags.

So this idea is about enabling also modules and containers to be set on <div> tags.

-Greg

[Grégoire_Miche2]

I quite agree with Pierce's comment here

-Greg

[Justin_Cooperm2]

Nicole,

Thank you for the details. I will look into this and see if there are other solutions for this unusual bug you are seeing. Have you tried other ways to structure your specific template so that you don't see this issue?

Justin

[Justin_Cooperm2]

@Greg - The Gmail app and Gmail web app now support media queries. So, you should have your issue auto-resolved. G Suite Developers Blog: Your emails, optimized for every screen with responsive design

[Grégoire_Miche2]

Hi Justin,

Yes, yet this is still causing some issues with Outlook (See below).  Furthermore, this does not work with Android email client other than last version of gmail app (a majority of android are still 4.4). It will take a while until every android user in the world has switched to the most recent version of gmail app

Furthermore, the fact that we still have to use tables instead of div's makes the responsive effect still limited.

-Greg

[Justin_Cooperm2]

Greg,

I don't believe that it's necessary to use <div> to make an email render properly on all clients. Out of curiosity, I've looked at every newsletter I've received in the last week and 95% use tables exclusively...that's not to say there aren't unusual cases where old versions of Outlook have rendering bugs, but it's important that I completely understand the root cause and what the potential solutions are. A lot of the resources I've read discussing this "page break" bug have offered many suggestions for how to resolve the issue without using <div> at all. So, I am trying to understand what options are available to avoid this issue.

I will continue to look into this.

Justin

[Anonymous]

Thanks Justin. I have tried other ways, yes. And I've tried restructuring the template so that it has the bare minimum required markup with minimal nesting, but it still occurs. I've tried manually adding page-breaks using proprietary MSO code, I've tried using MSO conditional comments to zero back down to body level, I've tried adding height declarations to cells and all the different suggestions that there are.

The only known 100% guaranteed solution for this bug is to ensure that you stack tables on top of each other to prevent them getting too long and triggering the bug.

[Anonymous]

What's the latest here?

We want to take a mobile-first approach to our email development (which includes our template development) and I have become a big fan of MJML (MJML - The Responsive Email Framework). Unfortunately, the html code that is output from MJML follows the best practice that Grégoire Michel​ is referencing in this original post from almost a year ago. I had assumed that the I could easily markup this output with some Marketo Email Template classes and attributes and be off and running with a nice new template, but the lack of ability to use DIVs as Modules is preventing this.

Justin Cooperman​, is this in the pipeline anywhere?

Thanks!

John

[Grégoire_Miche2]

Hi John,

funny, the reason why I needed this is because our own email framework has been created using MJML too

-Greg

[Anonymous]

Justin Cooperman​ - I think I didn't tag the correct profile, initially... Any updates on this front?