Thanks!
Now we are cooking 🧑🍳👨🍳👩🍳
I was getting hung up on the validation error, because I was editing the HTML of a test email when testing the <script> tag and not the HTML of a base Template. When selecting Approve & Close on a Template, there is no forced validation, and the script executes when using the template in a new message.
Now I wonder how much longer Marketo will be sticking around for us to make use of these enhancements I'm about to add 😬
You might think about using a class like "text-link" on the parent element (<table> in this example) and writing some CSS in a <style> tag in the <head> of your document to style the links. You can use the mktoModuleScope="" attribute to either make these variables bound to the modules or globally to all links on the template.
Here's an idea of what a CSS class might look like:
.text-link a, .text-link a:visited, .text-link a:link {color: ${em_linkColor} !important; text-decoration: ${em_linkDecoration}; font-weight:${em_linkWeight};}
... and here's a look at the implementation on the parent <table> element around the editable <div> (paragraph).
<table role="presentation" class="text-link" width="100%" border="0" cellpadding="0" cellspacing="0" style="min-width:100%;">
<tr>
<td>
<div role="paragraph" class="mktoText" id="paragraph.p" mktoName="Paragraph" style="font-family:${em_fontFamily_body}; font-size:${p_fontSize}px; line-height:${p_lineHeight}px; font-weight:${p_fontWeight}; text-align:${p_textAlign_left}; color:${p_color};">
Paragraph lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Quis ipsum suspendisse ultrices gravida. Risus commodo viverra maecenas accumsan lacus <a href="#" target="_blank">sample link</a>.
</div>
</td>
</tr>
</table>
If you'd like to make life easy on the marketers, you could create a few of these classes, lets say "text-link-red" and "text-link-blue" and "text-link-yellow" in your <style> tag. Then you could add a .mktoList (dropdown) variable that extends the class on the <table> element -- for example, you'd set your .mktoList variable like this:
<!-- default = red | values = red, blue, yellow | optional: mktoModuleScope = true/false -->
<meta class="mktoList" id="text-link-color" mktoName="Link Color" default="#FF0000" values="#FF0000, #0000FF, #FFFF00" mktoModuleScope="false">
With that new list variable created, you could update the class on the <table> element to look something more like this:
<table role="presentation" class="text-link-${text-link-color}" width="100%" border="0" cellpadding="0" cellspacing="0" style="min-width:100%;">
... and your CSS to look something more like this:
.text-link-red a, .text-link-red a:visited, .text-link-red a:link {color: #FF0000 !important; text-decoration: ${em_linkDecoration}; font-weight:${em_linkWeight};}
.text-link-blue a, .text-link-blue a:visited, .text-link-blue a:link {color: #0000FF !important; text-decoration: ${em_linkDecoration}; font-weight:${em_linkWeight};}
.text-link-yellow a, .text-link-yellow a:visited, .text-link-yellow a:link {color: #FFFF00 !important; text-decoration: ${em_linkDecoration}; font-weight:${em_linkWeight};}
If you wanted to take this to the next level, you could also use variables in place of the fixed color codes in your classes, and just set the default="" value for each of the variables to the red, blue, yellow colors. This would open the options back up to the end-user to be able to change the "text-link-blue" class to something like a pink color value, so maybe in your situation it'd be best to create a class for each of your branded link colors, give them a colorName (like red, blue, yellow) and then use those values to populate the list variable values so it's easy to read (red vs #FF0000).
NOTE: This would probably mean you'd need to refactor the code for your modules on your template which in turn would mean you'd need to add a new module to your layouts to replace the old setup but this might be something to consider in moving into the future w/ your email development standards in terms of optimizing for the end-user in your process.
I think one concern using css or html styles that aren't inline on the <a> is consistency across email clients that might ignore the separate css defined in the <style> tags, but it would be worth giving a try.