Re: Marketo Removing Code for Image Scaling for Outlook at 125%dpi

Anonymous · ‎06-19-2015

We’re having an issue with email rendering on Outlook 2013 (125% dpi) wherein the images stray from the set boundaries of the parent table. Upon further inspection, we’ve noticed that Marketo appears to be removing the header markup necessary for correct image scaling in Outlook at 125%dpi. I’ve attached screenshots of the code from before and after sending through Marketo.

Is there a way to stop Marketo from removing that code, or another workaround to adding it?

Pre Marketo code -

<!DOCTYPE html> 
<html xmlns="http://www.w3.org/1999/xhtml" 
xmlns:v="urn:schemas-microsoft-com:vml" 
xmlns:o="urn:schemas-microsoft-com:office:office"> 
<head> 
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> 
<meta name="viewport" content="width=device-width, initial-scale=1.0" />

Post-Marketo code -

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> 
<html> 
<head> 
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> 
<meta name="viewport" content="width=device-width, initial-scale=1.0" />

Any help would be much appreciated.

Justin_Cooperm2 · ‎10-13-2015

We will be releasing this feature with a patch outside of our normal release schedule and I want to explain how it will work. The items will be applied to our production code tonight (10/13) and will be available for activation starting tomorrow. It will not be turned on automatically for all customers. We will, however, enable the feature on an ad-hoc basis for those that are interested. If you would like this feature enabled, please email me atjcooperman@marketo.com and tell me the Munchkin ID of your subscription.

While this functionality has been thoroughly tested, we won't be enabling this for all customers for 1-2 months. It is a large change and it is important that you understand (and communicate to your team) the behavior before choosing to enable this.

With this feature enabled, you will see the following behavior:

Custom DOCTYPES will not be stripped from your Email Templates when creating new Emails in Marketo.
Custom HTML attributes will not be stripped from your Email Templates when creating new Emails in Marketo.

Please Note:

Your custom DOCTYPE will persist only if it is the very first line of your Email Template or what you are pasting into Email Actions > HTML Tools > Replace HTML. If the DOCTYPE is anywhere else, it will be stripped and replaced with Marketo's default DOCTYPE.
If you have existing Email Templates that already have custom DOCTYPES, they will now persist into your new Emails once the feature is enabled. Because this is a change from today's behavior, we highly recommend you make sure this will not cause issues for your existing emails. Same goes for existing Email Templates with custom HTML attributes.
If you omit a DOCTYPE in your Email Template or what you paste into Email Actions > HTML Tools > Replace HTML, the default Marketo DOCTYPE will still be added. You cannot create an Email without a DOCTYPE.
The Email Template "Preview" option will not show your custom DOCTYPE. This is expected so you can disregard this. Your emails will still have the DOCTYPE. This also applies to custom HTML attributes.

Again, please reach out directly if you'd like this enabled starting tomorrow (10/14) for your subscription. We will roll this out to all customers shortly after.

Thanks,

Justin

View solution in original post

Anonymous · ‎10-01-2015

Sorry I haven't been on in a few days.

Can you state your issue again, the image renders at 125%? or it doesn't respond?

**Also please note: width="600px" will not work 100% because of the measurement of px. Drop px, width="600" is the proper way to structure the table width attribute.

Dan_Stevens_ · ‎10-01-2015

Defining units as pixels will work just fine (just not here because of the code that's being stripped by Marketo). Here's more info on this issue - along with the solution (https://www.emailonacid.com/blog/article/email-development/dpi_scaling_in_outlook_2007-2013/ ). I also describe the issue in great detail above.

It all boils down to these three basic principles in order to ensure responsive templates render in Outlook when the user's Windows scaling is set to 125% or 150%:

1) Use inline styles and px units on tables. (supported in Marketo)

2) Use this tag to make VML scale. (not supported in Marketo)

xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office"

3) Use MSO-xxx for cellspacing and cellpadding (supported in Marketo)

This issue has been discussed as much as it can, here on the community. Now, we all just need to wait for the Marketo engineers to dedicate the time needed to finally fix it.

Anonymous · ‎10-07-2015

Tables in HTML documents

Calculating the width of columns - section title

Anonymous · ‎09-24-2015

Copy...

Dan_Stevens_ · ‎09-18-2015

I agree that the issue is how Outlook renders responsive-coded emails (at least the approach that many use) when Windows is scaled to anything other that 100%, but the fact that Marketo doesn't allow the custom xmlns code in the HTML tag of the template, is preventing the defacto fix for this widespread issue (which has been well-documented across the web, e.g., here and here).

Also, Outlook/Windows isn't expanding our images - instead it's expanding the pixel width of the table layout (we don't use background images; furthermore, we also tested this by exporting all images at 96dpi - no luck), making the main/banner "look" like it's smaller - when in fact it's the layout to the main container of the email that isn't being respected here.

The good news is Marketo is finally on this issue and hopefully we'll see this fixed in next month's release.

Dan_Stevens_ · ‎09-23-2015

Now slated for December

Anonymous · ‎09-16-2015

Any fix for this yet?

Dan_Stevens_ · ‎09-16-2015

As I mentioned above, this is slated to be included in the October release.

Anonymous · ‎09-16-2015

"We were originally told that this would be fixed in June, then August, and now the earliest is October. "

Yes, thanks but it doesn't hurt to apply a little extra pressure. Our client is using outlook, I need this fix for them to approve the emails we send.

Also stating June, August & October doesn't fill me with confidence they'll get it done.

Dan_Stevens_ · ‎09-16-2015

I hear ya - understood. However, I do feel a bit more confident this time since members of the Marketo product team have reached out to me directly to ensure they are crystal clear on the issue at hand. Fingers crossed.

Dan_Stevens_ · ‎09-23-2015

All - I just heard back from the Marketo product team and unfortunately this has been delayed once again and now estimated for the December release. This is so frustrating that our responsive emails will continue to render incorrectly for many of our Outlook users.

Here's the response from Marketo:

The fix for the DOCTYPE and <HTML> attribute issues you're tracking has been delayed. We had a fix for it, but after regression testing it was determined that it broke other parts of our email infrastructure. We know how to address it, but it is a much larger code change. I will keep you updated, but this will come after the Q4 release. I am estimating Dec' 15.

Anonymous · ‎07-28-2015

is this still the case where Marketo strips out this code. Can anyone confirm?

xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office">

Kinda need this for background images to display in Outlook. without it this system is 3 years behind the times?

Anonymous · ‎08-07-2015

Marketo couldn't find an answer for us, so the issue still stands. If you figure it out, please share!

Dan_Stevens_ · ‎08-13-2015

Jackie - I just came across your post today. FYI, we're experiencing the same issues:

IDEA:

DISCUSSION: Marketo is rewriting/omitting a significant amount of code in our responsive emails withint he HEAD ...

We were originally told that this would be fixed in June, then August, and now the earliest is October. Unfortunately, we cannot wait that long and therefore need to identify alternative solutions - like knak. A bit frustrated though that we would have to pay for a solution that should be capable within Marketo (where we have a huge portion of our budget).

Dan_Stevens_ · ‎08-29-2015

I just did some thorough testing of customizable, responsive template services and have found that even these don't render properly when a user's Windows environment is set to 125% or 150% (we're finding most users have their scaling set to 125% on newer laptops due to the extremely high resolutions on a 12-14" display). Here are the tests with a simple 2-column template from Knak (Pierce Ujjainwalla) - the one at 100% is how it should look across all three settings) - notice how the width expands beyond the desired 640px width, making the top banner look smaller and the right column area to extend beyond the width that was initially set for the right column. Again, this is a fairly basic layout. More complex layouts look even worse.

I don't think any service/design will be able to develop consistently-rendered, responsive emails/templates until Marketo stops stripping out the highlighted code below that's needed (within the <HTML> tag in the top portion of the HTML file - just after the DOCTYPE and above the <HEAD>) for these to render appropriately across all Windows scaling environments. Fortunately, Marketo is working on this and it should be fixed with the October release (that's the latest I heard).

xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office">

Dan_Stevens_ · ‎08-31-2015

BTW, when testing our responsive templates in Campaign Monitor - where the two xmlns lines of code were left intact - the rendering of our emails was consistent across all three Windows scaling options (100%, 125%, and 150%).

Jason_Hamilton1 · ‎09-11-2015

Thanks for all the legwork on this issue Dan, lloking forward to a resolution from Marketo.

Josh_Perry1 · ‎06-19-2015

Have you reached out to Marketo about this?

Anonymous · ‎06-22-2015

We have, but they don't have an answer for us yet. I thought perhaps the community might have some experience with similar issues.