Script layer/extensions for Email 2.0 Editor

[Anonymous]

I'd like the ability to run scripts to help users build better emails. My main use would be to check title length, font size, font color, cta length, etc...

If a user does something outside of the company guidelines I could have an alert pop up or when they preview the email a list of errors would show up.

In order to do this now I have two options:

• Add a script to the email itself, which is a terrible idea.
• Attempt to force users to use a browser plugin like Tampermonkey with the script running (easily disabled)

I'd love to have this option available in the email editor. Guessing it would just scope to the shadow DOM and not be too difficult to implement .

[SanfordWhiteman]

This would of course be a great feature! I have little faith that it'll ever be added, though.

One way to simulate this is by using a conditional Velocity token that only includes a validation <script> when the email is being viewed in the Marketo UI. This way it'll never be sent to any leads -- of course you never want a script tag in a outgoing email -- but it'll have full access to the DOM (I wouldn't say "shadow DOM" here as that's something else).

[Anonymous]

Thanks so much for the suggestion, I will for sure look into this. Seems like the best approach out of my current options.

As far as the DOM, I was referring to the #document inside of the email canvas iframe (from within the email editor). I always thought that was a shadow DOM but I'm not too experienced in that area so I might need to do some reading before using that terminology again .

[SanfordWhiteman]

Yeah, IFRAME is just a window with a regular document and its DOM.

Shadow DOM refers to HTML fragments that are used to build reusable Web Components (WCs aren't even close to widespread availability in browsers). For example, you might have a totally custom datepicker widget that -- like anything on a modern web page -- is constructed out of typical HTML elements like DIVs, As, IMGs, background images, and associated CSS and JS. If it's declared to be in a shadow DOM, the widget doesn't need to expose its internal tree of elements in Dev Tools (and vice versa -- it is somewhat immune to pollution from styles and scripts in the main document DOM). Think of it as the successor to when people would (try to) use a Flash-based widget for an in-page picklist, menu, etc.  It's encapsulated so it sits aside from the rest of the page, but it doesn't use any plugins, just regular HTML.

[Anonymous]

That makes sense and it's also a pretty cool that you can encapsulate your code like that (when more widely supported). I can see that being especially useful if your WC or the host/parent document is using generic selectors. Also, not having to be so specific when writing JS would be great. Thanks for taking the time to explain this, really great stuff.

[Anonymous]

Hey Sanford,

I'm playing around with this idea but new to Velocity and its abilities. I was unable to find a way to run the velocity script at compile time rather than run time (if even possible).

The script token would check if it's running in the preview window, I've been doing this in JS using the URL, then if true show the <script>. However, within the preview window all I'm getting is the token name, {{my.scriptToken}}, since the script has not run yet. Do you know of a work-around to get the desired results. I saw your post here (Text version of emails not token-friendly ) about having a script token dynamically aware of where it is, would love to hear more about this if you have the time.

Thanks,

Tony

[SanfordWhiteman]

You can't have the script check to see where it's running, because that means the script is always present in the email (even when sent).  You have to check the context (preview vs. actual send) before even displaying the <script> block. There's a trick to it.