Skip to main content
Grégoire_Miche2
Grégoire_Miche2
Level 10
June 8, 2016
New

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

  • June 8, 2016
  • 10 replies
  • 15078 views

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

    10 replies

    Grégoire_Miche2
    Grégoire_Miche2Author
    Level 10
    June 8, 2016

    @Pierce Ujjainwalla​​, @Fab Capodicasa​,

    What do the template development specialists think of this limitation? Do you use Tables elements or divs as the primary structure block in your emails?

    -Greg

    Fab_Capodicasa3
    Fab_Capodicasa3
    Level 2
    June 17, 2016

    We use DIVs as our top-level section wrapper. As our Email Template Builder/Editor works independently of Marketo, we don't really have an opinion either way

    Grégoire_Miche2
    Grégoire_Miche2Author
    Level 10
    June 12, 2016

    To be more precise, the current version only supports <table>, <tbody>, <thead>, <tfoot> or <td> for containers.

    and for modules inside containers:

    • <tr> if the container is <table>, <tbody>, <thead>, or <tfoot>
    • <table> if the container is <td>

    What we would need to have is

    • <div> modules in <div> or <td> containers
    • <table> modules in <div> containers

    -Greg

    Lucho_Soto
    Lucho_Soto
    Level 5
    June 17, 2016

    I might be misunderstanding, but it seems weird that "mkteditable" divs can't be modules.

    Our hybrid fluid templates look something like this:

    <table><tr><td>

    <mkteditable div></div>

    <mkteditable div></div>

    <mkteditable div></div>

    <mkteditable div></div>

    </td></tr></table>

    For modules to work on our template, it looks like we would have to go through our entire template and make sure each mkteditable div is inside of a separate table.

    Grégoire_Miche2
    Grégoire_Miche2Author
    Level 10
    June 17, 2016

    Hi Lucho,

    This is not the only way to set it up. Ours use a table on first level only on Outlook, otherwise it uses divs on other email clients:

    <!--[if mso]><table><tr><td><![endif]-->

    <div>

         <div class "mktEditable"></div>

    </div>

    <!--[if mso]></td></tr><tr><td><![endif]-->

    <div>

         <div class "mktEditable"></div>

    </div>

    <!--[if mso]></td></tr></table><![endif]-->

    This has shown to be easier to make it fully responsive on all Android email clients

    -Greg

    Grégoire_Miche2
    Grégoire_Miche2Author
    Level 10
    June 12, 2016

    @@Karli Kratzenberg ,

    If you are downvoting the idea, it would be interesting to know why.

    -Greg

    P
    pierceu25628284
    Level 7
    June 13, 2016

    Good question - checking with our email developers and will reply back with answers.

    A
    Anonymous
    June 21, 2016

    So, is it not possible to simply nest your structural code inside an acceptable container type to get it to work? It's hard to get my head around this without actually being able to play with it, but I would happily add another wrapper table around something in order to turn it into a module.

    Or is it that, as soon as you create a module, the entire thing becomes editable or something?

    I had presumed you could have, say, a TD container, with 100% wide tables stacked inside, each set to be mktoModule elements, making them repeatable and rearrangeable. Then, inside those elements, you designate specific editable areas using mktoText and mktoImg elements, etc.

    Can it not work like that?

    Grégoire_Miche2
    Grégoire_Miche2Author
    Level 10
    June 21, 2016

    Hi Nicole,

    what you suggest is the way Marketo builds its own templates. And they do not render perfectly on all devices, as you can see on the litmus link I posted above.

    We can achieve a better result with <DIV> tags, which are BtW just plain HTML standard ones...

    -Greg

    A
    Anonymous
    June 22, 2016

    Hi Grégoire,

    Thanks so much for your response! I can certainly see what you mean about the Marketo templates in that they do not render well across email clients, however I think that is less to do with how they have configured the editable sections, and more to do with poor email coding generally.

    Thanks,
    Nicole

    Grégoire_Miche2
    Grégoire_Miche2Author
    Level 10
    June 21, 2016

    We have been able to wrap the <div> in a table / tr / td structure and it is apparently working.

    It is adding an additional level of code to the template, which in turn adds to the complexity (risk of formatting interactions with the other elements), the risk of errors and the maintenance. So there is workaround there, but not perfect.

    -Greg

    A
    Anonymous
    June 22, 2016

    Oh, that is great news. Thanks for letting me know. I admit I'm very happy to rejig my layout or even add some complexity if it means getting things to work!

    A
    Anonymous
    August 17, 2016

    Hello Greg,

    Do you know if Marketo is working on implementing this?

    Thank you,

    Laura

    Grégoire_Miche2
    Grégoire_Miche2Author
    Level 10
    August 18, 2016

    Hi Laura,

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

    -Greg

    Justin_Cooperm2
    Justin_Cooperm2
    Level 10
    August 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
    Grégoire_Miche2Author
    Level 10
    August 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

    gkrajeski
    gkrajeski
    Level 10
    August 19, 2016

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

      A
      Anonymous
      May 29, 2017

      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
      Grégoire_Miche2Author
      Level 10
      May 30, 2017

      Hi John,

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

      -Greg

      K
      kh-lschutte
      February 6, 2020
      No text available
      Terms & ConditionsAccessibility statement

      Loading footer...