- Zach
Hey Adiba -
I don't think many people check this that often anymore, but did you try this solution?
https://litmus.com/community/discussions/982-outlook-overrides-font-to-times-new-roman#comment-9847
Good luck!
@rynne <address> has global support from html4 > current, but its always just safer to stick to the really basic tags
We went through this exact same exercise at my job.
There are so many benefits on both sides, but it really depends on your team's skill set. From my perspective, I'm a big fan of the idea of having a drag and drop/wysiwyg editor available to make edits and assemble templates, but if you don't have the HTML properly setup to work in that environment it can be disastrous. We used to be of the fragmented file mindset; writing modules by hand and then calling them at send time, but we actually built a drag and drop system to replace it...and we're learning about it in the process. Mistakes can be edited quickly, prototypes can be made quickly, things are more organized...it improved everything. But at the base-level there is still an HTML template that needs editing and a system that everyone needs to understand.
We had the case of someone coming in with no email experience and little-to-no experience writing HTML/CSS and they adopted it quickly...but the drag and drop makes that learning process and on-boarding time much quicker. It's just a much more organized system. It just comes down to your team needs. We've been making so many changes since we launched our first version just because we want to make it smarter. Taxi, as mentioned below, is a great application to mess around with. And then on the other side, MJML and Foundation for Email (my choice) are fun code-based solutions to the HTML/CSS coding approach. It just comes down to needs and who's comfortable with what on your team.
Our solution here was a hybrid approach between the two approaches because that's what we found comfortable and scalable. We still update code on a regular basis, but templates are delivered to modules for use in a drag and drop editor. We have custom settings for handling images, css, etc, so those are things you can choose...but these are also available in other platforms. If you aren't making complex changes to your templates on a regular basis, the drag and drop/wysiwyg model will probably be more appealing...but if you have some savvy designers/developers/engineers then maybe you go with a a more single-file or modularized system without a UI.
Discuss with your team and see what they're leaning towards.
Drop a comment if you have any more questions!
Yes...this is similar to my updated approach...except I don't even mess with MSO anymore because, well yeah I don't wanna mess with the MSO anymore (who does, honestly?).
This has to be done a bit clunky. I've found that trying a 'minified' style does not work at all in Outlook or OWA...and trying to combine all various tags/selectors/classes doesn't really work, so I go with this hideously ugly solution. I could probably cut some stuff down, but this is the version I'm at for now. A few extra lines are a small price to pay to never have to see Times New Roman ever again.
This solution also removes the need to ever call "font-family" inline or in your css, unless you want to do something specific with a separate font. Overrides will work because nothing is tagged with !important, so you have a lot of flexibility after the fact.
Sitting right below the body tag, of course...
<style type="text/css">
@media screen {
@font-face { font-family: 'Helvetica Neue'; font-style:normal; src: local(Helvetica Neue Regular), local(HelveticaNeueRegular), local(HelveticaNeueMed); }
@font-face { font-family: 'Helvetica Neue'; font-style:bold; src: local(Helvetica Neue Bold), local(HelveticaNeueBold), local(HelveticaNeueBd); }
}
* { font-family:'Helvetica Neue', Arial, sans-serif; }
html { font-family:'Helvetica Neue', Arial, sans-serif; }
body { font-family:'Helvetica Neue', Arial, sans-serif; }
table { font-family:'Helvetica Neue', Arial, sans-serif; }
td { font-family:'Helvetica Neue', Arial, sans-serif; }
th { font-family:'Helvetica Neue', Arial, sans-serif; }
p { font-family:'Helvetica Neue', Arial, sans-serif; }
span { font-family:'Helvetica Neue', Arial, sans-serif; }
div { font-family:'Helvetica Neue', Arial, sans-serif; }
a { font-family:'Helvetica Neue', Arial, sans-serif; }
img { font-family:'Helvetica Neue', Arial, sans-serif; }
.msoNormal { font-family:'Helvetica Neue', Arial, sans-serif; }
.MsoNormal { font-family:'Helvetica Neue', Arial, sans-serif; }
.externalclass { font-family:'Helvetica Neue', Arial, sans-serif; }
</style>
yeah thats the one thing im still trying to figure out...the split view. at least for my purposes i found it much easier, for debugging, to have multiple views but they dont have that option or at least i havent discovered it yet.
Hey Chaya -
A code sample and screenshot would be greatly helpful. This just kind of sounds like an HTML issue. Normally, in any case that I've seen this with my code, it's just a case of there being unfinished tags or improper CSS. In the case of CSS, if the item is position:absolute, then that'd probably be the issue. If its absolute then the table it's nested inside should be set to position:relative, so the button knows its boundaries.
Try that out but definitely post up some samples.
Yeah this is my method as well...still kind of choppy even with all the proper styling and containers...can be tricky especially across outlook versions.
But nested tables and fluid tables are the way to go.
I think everyone's already said their peace on this one, but here's another example that is my go-to.
<!--[if gte mso 10]>
<style>
/* Style Definitions for MSO 2010 */
table.MsoNormalTable, p, span, div, table, tr, td, th, a { mso-style-priority:99; font-family:"Arial","sans-serif"; }
</style>
<![endif]-->