- Too much CSS gets the style block removed
- Any CSS gmail doesn't like (including valid css) gets the style block removed.
- Sending to a non
@gmail.comaddress. Using the Gmail App but Not a Gmail Account (often referred to as GANGA) doesn't support CSS in the head.
Hi Aman,
No worries happy to help.
Yeah it would be good if there were a way to remove a section if the break falls in the middle of it, but can't currently think of a way to target that in CSS.
There aren't conditional comments for Gmail or Yahoo but you can target them with CSS, it's probably not going to help much in this situation, but if you're interested there is a list of email client targeting tricks here https://howtotarget.email/
102kb is pretty large so I'm guessing you either have a large amount of content or a very complex design. If you can't reduce the content then maybe a simpler design could help.
I think the main issues come when the break falls part way through an opening element tag
<p class="foo" style="margin:1em 0">
if that's broken anywhere between the < and > it'll cause issues, if it's broken in the following text then the browser will automatically close the tag. So reducing the amount of inline styles and shortening class names can help.
A single column layout can be good, as this will use less code, also breaks in multi column layouts can look a lot worse.
But there will always be a chance that it will break in a tricky place if you go over the limit.
The app appears to work in the same way as teh webmail. So they replace your colours and inline the styles.
Previously we could override this by adding a class with !important to override their override. But since a recent update they are now applying !important inline so we can no longer override the changes they make.
I was digging around a little yesterday and I found when changing a color style in darkmode, Outlook will add data-ogsc to the element. And when changing a background-color style in darkmode, Outlook will add data-ogsb to the element.
So we can target this with something like [data-ogsc] .foo{}
We still have the issue of not being able to change colours but we can make other adjustments to try and fix some of the styling.
Here's some code to try out, for me this works in both webmail and iOS app.
<style>
[data-ogsc] .darkmode{
display:block !important;
}
[data-ogsc] .lightmode{
display:none;
}
</style>
<div style="color:#000">
<div class="darkmode" style="display:none;">this is dark</div>
<div class="lightmode">this is light</div>
</div>
You can either set the color on the <a> tag, or you could try the old link vlink attribute on body to reset the default colours that way.
<body link="#ff0000" vlink="#ff0000" >
Gmail doesn't allow you to import fonts.
The reason you may be seeing Open Sans rendering is either because Gmail are importing it for their own use or you may have it installed on your testing device.
When looking at the Gmail webmail client I can see they import google sans and roboto
I've not looked much on Outlook via mobile safari. That is quite an edge case. But I know Outlook webmail resizes emails built with tables, even when using fluid or hybrid layouts.
The way around that is to use a ghost table layout. That will scale down as expected. I know this works for desktop browsers so hopefully will be the same in the mobile browser.
@media should work fine in Gmail apps, however there are some limitation.
Here are some docs
https://developers.google.com/gmail/design/css
https://developers.google.com/gmail/design/reference/supported_css
Common issues are;
Outlook overrides your colours by either editing the inline style or if it's added with CSS they add an inline style.
So this <p style="color: green">text</p>
Becomes this <p style="color: rgb(103, 202, 82);" data-ogsc="green">text</p>
I've not yet found a way to prevent this from happening but you can override it by adding styles to your head.
Because they are only touching inline styling and not your <style> block you can add something like p{color:green !important} which will override the added inline styles.
It could end up being quite a lot of code doing it that way if you're using a lot of colours so may be best to only use it where the changes are really bad.