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

Grégoire_Miche2 · ‎06-08-2016

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 · ‎06-27-2016

Hi Greg,

Good question

We have experienced various developments approaches and div with tables for outlook is the one that apparently gives the best cross-platform results. But maybe some other developers think otherwise and there is surely more than 1 way to achieve a good result.

The key question is, IMHO : why is Marketo limiting the possibilities?

-Greg

Anonymous · ‎08-17-2016

Hello Greg,

Do you know if Marketo is working on implementing this?

Thank you,

Laura

Grégoire_Miche2 · ‎08-18-2016

Hi Laura,

I do not know. This is a question for Justin Cooperman

-Greg

Justin_Cooperm2 · ‎08-19-2016

I think of this as a convenience feature and, yes, we'll look into adding support for <div>.

But, Greg had previously mentioned that our templates don't work well on different clients. As you'll now see in our last round of updates to all the starter templates, I think that isn't necessarily true. When we first launched Email 2.0, some of the templates simply had some rendering bugs. But, we've addressed many of those issues, while still using tables throughout the templates.

Does anyone have a more concrete example of why tables will not work for them? I've seen very nice templates from other customers that only utilize tables and they look great on all devices...

Justin

Grégoire_Miche2 · ‎08-19-2016

Hi Justin,

Basically, the main advantage of support for div will be the possibility to make the email really responsive on the gmail app on mobile, which they are not for the moment (the scale down, but the columns remain, and the text will be hard to read past 50 years old )

-Greg

Geoff_Krajeski1 · ‎08-19-2016

You made me chuckle w/ the "past 50" comment!

Grégoire_Miche2 · ‎08-19-2016

Yes, even people aged more than 50 sometimes read emails on mobile...

-Greg

PS: I started presbyopia at 38

Geoff_Krajeski1 · ‎08-19-2016

I'm the lucky one in my family. Both parents w/ glasses by 10, brother by end of high school, my son at 10, and I <knock on wood> still have 20/20!

Anonymous · ‎09-15-2016

Hi Justin,

Today I've been running into a big issue which makes a case for allowing a divs to be containers and modules.

There's a bug in Outlook called the 'Page Break Bug' where, when content gets over a specified height (22.7 inches, since Outlook is a bit insane and renders using Word), it will freak out and insert a page break somewhere. Since users can now create very long emails with lots of modules, it's easy to run into.

It looks like this, a weird gap somewhere in your layout on long emails, as shown below. (The pink was for testing purposes).

You can end up with multiple breaks throughout one email, sometimes going across the whole width.

You avoid it by ensuring that the content is split up into individual sections that aren't very tall, and that all block-level container elements are direct children of the body tag. Like this:

<body>

</body>

As soon as you nest even one more level in another block-level container, like this:

<body>

<table>

</table>

</body>

Outlook starts to consider the content too long, and looks for somewhere to add the page break.

It calculates the height from the first block-level container. So as long as you keep zeroing back down to the level of the <body>, you have no problems.

The good thing is, Outlook doesn't consider <div> tags to be block-level elements, so you CAN nest your module tables in a div, and you won't get any page breaks:

At present, we are required to nest each module in a type of container that is guaranteed to trigger this bug, and there is no way around it. You must have one big table wrapped around all your content so that you can either have a mktoContainer table with lots of rows or cells as modules, or you make the first cell the mktoContainer and then stack lots of tables inside. Either way, you end up with one really long wrapper table that triggers this bug.

(I have tried to trick Outlook by using conditional code on each mktoModule to close the row, cell and table and get back down to body level, but it doesn't seem to work. It really seems like we need to be able to have stacked tables or divs inside a div element to ensure this bug doesn't trigger.)

So I think it's necessary that at the very least we can have a <div> acting as the mktoContainer.

Thanks!

Nicole

Pierce_Ujjainw3 · ‎10-07-2016

Due to what Nicole has pointed out here, this is no longer a convenience feature. This is a feature that will ensure Marketo's customers emails render properly on Outlook 2007 & 2010 (two clients that still occupy a significant market share, especially in the B2B world). Please let us know if you need more information on why this needs to be resolved or the impacts of not making the change.