Ouch! It can’t be that bad, can it? Well, at least I grabbed your attention...

The good news is that our product team has been working vigorously to address issues and concerns that have been raised by our community! With the exception of a few emails from some anonymous “haters”, most of the feedback has been incredibly constructive . We always read through everyone’s feedback and have made solid progress on a set of enhancements to solve many of your issues. Our goal is for the new text editor to be fast, efficient, and much easier to use than the legacy editor. We intend to make all of the necessary changes so that, eventually, you’ll have no reason to revert to the old editor.

This is a process and your input is critical. Like many customers have pointed out, emails can be tricky. Often times, invalid and/or deprecated HTML may be used to manipulate how an email will render on various (especially older) email clients. Because Marketo uses an open-source text editor, much of its default functionality must be overridden to support these non-standard use cases. While the new editor does include support for most HTML4 and HTML5 syntax, often times this doesn’t cut it. In addition, although the new user interface is much simpler than the legacy editor, there are spots where important functionality is missing. While simple is definitely better, neglecting frequently used functionality is certainly not our intent.

In the sake of being transparent, I’d like to use this single thread to summarize some of the tasks we’re actively working on. If you’re experiencing issues that aren’t listed here, we need your help! Please contact me directly at jcooperman@marketo.com with a brief description of the issue and I will personally make sure it gets reviewed. I will continue to update this post with ETAs and mark things as completed as we make progress.

Add "Style" textbox so that users can specify a custom CSS style inline for the <img>

Add "Class" textbox so that users can specify a custom CSS class.

Add "Title" textbox so that users can specify the title of the <img> element.

Add "Alignment" textbox so that users can specify the alignment of the image.

Add "Vertical Space" and "Horizontal Space" textbox.

Reminder to update TEXT version - Add UI reminder to indicate when a change has occurred in the HTML side of an email without any changes to the TEXT version. ETA: JAN '15.

If you open an “mktEditable” section in the email editor, it should show that the font is "default" if a new font hasn’t been chosen for the content. If the user selects a font, it’s not currently possible to return to the template-defined font. This should also occur for font size. ETA: DEC '15.

When in TEXT version of email editor, double-clicking an editable region launches the text editor to the TEXT tab by default. Currently opens to the HTML tab.

Override editor so that anything is allowed within HTML comments – Fix for mso conditional comments being stripped. Ignore anything that is between <!-- and --> ETA: OCT '15.

Override editor so that any VML markup is supported. ETA: OCT '15.

Don’t put &nbsp in <td> when empty. ETA: OCT '15.

General

Undo/Redo does not function when a token is inserted.

Text styling issue - type text on line #1 and line #3 and then attempt to center align the text on line #3. Text from line #3 jumps to line #2.

Handles don't appear to re-size images after an image is inserted into the Email Editor (they do appear when images are inserted into the LP Editor). ETA: SEP '15.

Not Related to Text Editor but Fix Anyway

Do not change custom DOCTYPES when creating a new Email from a template or when using Email Actions > HTML Tools > Replace HTML. ETA: PATCHED AS OF OCT 13, 2015.

Do not strip custom attributes on the <HTML> element when creating a new Email from a template or when using Email Actions > HTML Tools > Replace HTML. ETA: PATCHED AS OF OCT 13, 2015.

When using “Copy from HTML” button, add the link-tracking markup in the TEXT version if the link is tracked on the HTML side.

Support newlines in text tokens!

Thanks for your patience as we work to resolve these issues. Stay tuned for continuous updates and improvements!

-Justin C.

P.S. Ultimately, our long-term plan is to “sunset” the legacy editor. But don’t panic! We won’t do this until you’ve given your blessing. We are committed to improving the editor until we’ve resolved any issues that have prevented you from using the new editor.

Indeed, we had to revert customers to the legacy editor for various reasons you listed above, including link and image styling.

On question : what's the ETA?

A few things I could add :

Make the image property dialog to open when we double click an image

Make the lnik property dialog to open when we double click a link

When inserting an image, do not add the height by default in the "height" box. Usually, height will not be set in the template styles, only the width is (so that the user can insert images of different heights withou distortion). If the editor forces a height, on some devices, the image apears distorted.

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.

10/2 Update: See my latest comment. We actually may have a fix for this in the coming weeks.

Can you please anticipate this December fix and let us know in advance if it will, or will not, make it by December? I have had new responsive designs gathering dust for months because Marketo ruins them in Outlook, despite their testing fine in Litmus.

I have been told a fix would be in.......July, August, October and now....December. Sadly, this begs the question whether it will, in fact be fixed....and when.

Following this thread is the right thing to do if you are interested in monitoring status (I've been marking each item inline and will continue to do so). I can at the very least assure you that we're working diligently on these issues. This is an issue that has been present in the platform for many years and it is not as simple as it may seem to resolve. Thanks for your patience.

-Justin

P.S. I know a lot of people on the web use all the XHTML doctype stuff in example responsive templates, but there are other ways to build responsive email templates that work great today. Many that we've found will work great out-of-the-box. If you take a closer look at some of the beautiful responsive emails you're receiving at your personal email address, you'll see that many use alternative approaches.

Couple of general questions around the html editor in general but definitely related to this subject and maybe some more users see these issues...

We're using <p> tags in our emails and we declare the styles (font, size, line height etc.) at the template level.

We have hundreds of users (literally) globally and I noticed sometimes that they love a copy and paste from word etc. which adds rubbish in L

We always tell them to right click paste as plain text but sometimes, even doing that, it throws out the standard stuff (the font for example comes in a lot smaller) and then if you examine the html, it's put additional un-needed code in, usually a blank <span> tag etc.

Is there any way to stop this additional code being added?

Secondly, I noticed the plain text email formatting (let's call it alignment) gets squashed up, if for example they paste the content in as a block.

The common denominator I noticed is that it changes <p> to <p style="font-weight: normal> and then the plain text email is on consecutive lines. Change it back to <p>, update the text and everything is fine.

Would be interesting if silly things like this could be fixed or any tips to avoid these scenario’s

This one isn't related to the TinyMCE rich-text editor. That is referring to the HTML view of our Email Template editor. We'll also be working on improving that as well, but this thread just covers the text editor.

Override editor so that anything is allowed within HTML comments – Fix for mso conditional comments being stripped. Ignore anything that is between <!-- and --> ETA: OCT '15.

Override editor so that any VML markup is supported. ETA: OCT '15.

... Because I've been relying on Campaign Monitor's "Bulletproof email buttons" which are a great non-image-based solution for buttons. They use MSO comments as well as <v:rect> tags.

I've figured out that they still work if they're unmodified from the Email Template, so I've been taking advantage of {{my.tokens}} to pull in the button's URL, though this is a very awkward fix at the moment.

Do not change custom DOCTYPES when creating a new Email from a template or when using Email Actions > HTML Tools > Replace HTML. Also support having no DOCTYPE. ETA: OCT '15.

Do not strip custom attributes on the <HTML> element when creating a new Email from a template or when using Email Actions > HTML Tools > Replace HTML. ETA: OCT '15.

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. EDIT 12/1/15: This is now live 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 at jcooperman@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.

I've only received two requests to enable the feature. Please don't be shy! Let me know if you want this enabled in your subscription and make sure you tell your team about the behavior change (noted above).

Yes, the main callout for this feature is that "none" is really not a good option to use. It has very negative side-effects for formatting, and some functionality might not work as expected in the text editor when you change the root block element to none.

I don't actually understand what the issue is. If you edit the text, are you saying it is changing your font size that is defined in the template. The text editor should never do that unless you explicitly change the font size in the text editor. It should load in the text editor and say "Default"

Sorry if I didn't explain it very well. At template level the font is declared at 13px for example. Before this week when we edited an email the font size in the actual editor itself appeared at the correct size. Since Monday it appears to be very small (it looks like a 10px font for example) but when you click out of the editor into the draft then its fine.

If I declare the size in the editor (screenshot 2) by using a span tag etc then it views correctly.

Basically our users are asking us if there is an issue because the font looks small. Everything works fine in emails and in edit mode (just not in the editor). The font is appearing small and it looks like it's not picking up the inherited size from the template in editor mode.

I've seen this issue too and for some time now - It seems to have to do with the font settings not being applied to the rich text block that you open, but they do render when it's added back into the HTML.

I quite like it to be honest, it gives me the confidence that it's more difficult for people using the Rich Text Editor to overwrite the template's fonts and styles because they know they just type in what they want and Marketo spits out the right answer when it renders

Yeah, I think it must be something else that changed, because our text editor has always done this. Even the legacy editor did this. If you use a custom font or size in your template that we don't have in our text editor as asn option, we have to show something. So, the text editor will show it as "Default" and the actual text will be displayed using some defaults just so the user can edit it. Does that make sense? If you pick some random web font we don't support, it might show it to you as "Default" and show the text as "Helvetica" even if the resulting font on a live landing page would take on the web font you specified.

We're running into an unfortunate issue where when we edit the TEXT version of the email, it strips out the formatting of our HTML text. It's been driving us crazy for the last 24 hours and we're now being forced to send out our campaign with the TEXT version unformatted - which is far from ideal.

We're not entirely sure where the code is being stripped out. When we upload our HTML directly to Marketo and ignore the TEXT version - our litmus tests are perfect. As soon as we edit a single section of the TEXT version the litmus tests come back with a variety of spacing, sizing, and color issues.

We've tried duplicating the text styling and spacing with span tags and on the table cells with no luck. Editing the TEXT version breaks it every time.

We ran into a spacing issue with formatting the TEXT version back in October that seemed to be resolved, but it seems to be back at it again. We've taken a screenshot of our somewhat over-styled code:

P.S. as a side thought - TinyMCE editor, although open source, was built for web development and not email coding. I'm not surprised your team of developers is struggling with getting this editor to work right. As you know, there are few similarities between email coding and website development. Just a thought.

I haven't seen this issue and I can't seem to reproduce it. If you open up an "mktEditable" section in your email, you are saying that modifying the TEXT side of things is causing unwanted whitespace? Or am I not fully understanding what's happening. Perhaps you can email me and we can discuss further.

Rather than either adding or not adding the <p> around the entire section, it stopped adding <p> tags between paragraphs when editing in the rich text editor (even though the editor was displaying them while editing).

To counter that I manually added <p> tags around the paragraph and, upon saving, they were all removed.

It seems as though this functionality should either by default add or NOT add the tags (as defined in the editor settings), but it's creating a lot of issues by removing tags that I put there myself.

Dan, I still don't follow 100%, can you reach out to me at jcooperman@marketo.com? The TEXT version won't inherit any CSS styling from the HTML side. It is just going to pull out the text contents of elements like divs, spans, etc. For example, if you have a css style "margin-left:40px;" specified on a div in the HTML side, it's not going to automatically add spaces in the TEXT version. It's also not possible to change the text size or font in the TEXT version of an email...is that what you're looking for? Please email me to discuss more.

Thanks again for getting on the line with me to sort this out. I figured I'd post a brief description of the issue.

Root Block Element

With the new feature roll-out mentioned a bit further up the string of being able to define what your email editor's "Root Block Element". What wasn't mentioned in this conversation is that Marketo defaulted everyone's account to be set to <p> — paragraph tags. It was essentially "None" before this switch, but was "<p>" in the old email editor - hence their decision to default everyone to <p> again.

What this actually means is that Marketo will insert <p> tags every time you edit a section of your email. So if, like me and my team, you restrict <p> usage and use a more finite control over your HTML/CSS to ensure your emails render properly in all email clients (including really old versions of Lotus and Outlook) then this will break your code. This is explained further here: Rich text editor adding paragraph tags

Confusion

This was causing us a lot of confusion since we were only using the WYSIWYG editor to change the TEXT version of the email, but it still insert <p> tags in each section we touch since the WYSIWYG editor using the same editing blocks for both HTML and TEXT.

The solution was to switch the global settings back to "None" — which I highly recommend for anyone using templates defined without the use of <p> tags.

I hope this helps someone else out there. A huge shout out to Justin for his incredibly quick response to my post and willingness to work through this with me.

This is really helpful, as I definitely had the same issue...Any downsides to reverting the root block element back to None you've run into? I am looking at editing all my current templates to encompass the new root block element (specifically bc we have HTML "buttons" with our CTA and the <p> as root block element is adding spaces so doubling the size of the "buttons").

Justin mentioned earlier in the thread: Yes, the main callout for this feature is that "none" is really not a good option to use. It has very negative side-effects for formatting, and some functionality might not work as expected in the text editor when you change the root block element to none.

Wanted to know if you ran into any of the negative side effects? I have not reverted the root block element back to none yet; I am trying to weigh my options of a larger scale template redesign or changing the root block.

Essentially, some of the formatting functionality in the text editor won’t work as expected. In some cases, the editor can't properly manipulate the text if there isn’t a root element to act on.

Examples:

Single Space & Double Space options doesn’t behave correctly.

Indent More and Indent Less can behave unusually.

Alignment options don’t always work (add 3 lines of text, try to center align only the second line).

There are others, but you get the idea. If you don't care much about alignment and indention then you should be fine setting the root block to "None".

_______________________

Here is additional info also from that thread:

Before Dec '15, our email editor used “none” as the root block element. As of Friday, we've reverted back to having the default email root block element be <p> for all subscriptions (please note that the legacy email editor also uses “<p>” as the root block element). Customers can change this setting in that Admin dialog if they prefer the other behavior, but it does mean that some text formatting options in the editor will not function if they are using “none” as the default root block. Marketo recommends that customers use our default settings for the best experience (most text editors will default to using <p>). The landing page editor will continue to have its default set to use a root block of <div>, which can also be changed from the Admin dialog. The root block of rich-text program tokens cannot be changed and is set to <p>. One minor callout for rich-text tokens is that if the token only contains a single line of text, the surrounding <p> tags will be stripped automatically by Marketo when used in an Email or Landing Page.

So, what is a root block element?

If you have <div class=“mktEditable”></div> in an Email Template, you will see the following behavior when you open the section and insert “Hello World” text using the editor:

You click on an editable rich-text element (just like you would have before), and then click the "Text" tab and edit the contents of that element's text value. There is no difference between this and the legacy editor except it's no longer side-by-side editing. You must click one tab or the other.

This changes the spacing of the HTML version. We have several tokens that wouldn't work in the text version so we delete them in the text tab. This causes major spacing issues when we save and look at the HTML version. Same goes for adding spaces in the text version, this can throw off the HTML. Turing <p> to None in admin for text editor solves this but we would rather not have to toggle that on and off when editing text versions.

The only reason that would happen is if there is no <p> inside of your rich-text element. When you save, it will add one because that is set as the "root block" element. If you don't want that behavior, then you should change the root block to "None" in the new editor. By the way, the legacy editor always forced <p> as the root block and we didn't even have an option to disable . So, setting it to "None" will ensure that you can edit text version and nothing will happen to your HTML side because there are no requirements about the root block having <p>. If you need more info, email me at jcooperman@marketo.com. It sounds like this is working as expected though.

Hey Justin Cooperman any updates on "Reminder to update TEXT version"? I currently have sticky notes on all my users monitors to remind them to copy to text version. Really looking forward to this automatic reminder