CSS inlining
rasky opened this issue · 7 comments
It looks like CSS is not inlined. This is an important compatibility problem.
Hi @rasky,
In which situations you have compatibility issues ? CSS is not inlined in mailgen either and it does not seem to bother users.
Nevertheless, I know Postmark template (template that default theme is based on) is providing a CSS-inlined version. But it's a pain to maintain.
Either way, mailgen and Hermes provide two methods to generate emails : HTML and plaintext. Plaintext is for old browsers and emails clients.
I saw a golang lib that can parse html pages that links to CSS and convert it to inclined css.
I can't remember at all what it was called.
But i agree that external CSS is a problem.
Also con writing images to base64 might be also needed but not sure
@matcornic it's true that it's less useful now after Gmail finally decided to handle embedded CSS, but there are still country-popular email providers that don't handle that (like Libero in Italy or Yandex in Russia).
Alas, the plaintext version is not a workaround, because if you send a mime/multipart email, those email providers will display the HTML version, but it will appear broken because of the embedded CSS.
It would be great if you could either inline the CSS during generation, or use the inlined version as template.
@rasky Thanks for the explanations :)
Inlining CSS during generation would be nice, I will look into that.
Some context here: https://litmus.com/blog/a-guide-to-css-inlining-in-email
EDIT: also this: https://mosaico.io/email-client-tricks/email-inliners/
Jumping into this dialog...
I'm the author of CSS::Inliner, one of the prominent open source CSS Inliners. An earlier version of the library is referenced by @rasky in the above Mosaico article.
It is true that there are still some benefits to inlining the CSS of an email, but I would mostly classify those benefits as minor. The current state of affairs is the following:
Within the US:
- using Gmail it seems that enabling images for an email where the images had previously been disabled still results in a misrender, but this is a known bug and will be fixed
- using Gmail on Android for a non-gmail account fails to render properly
- Yahoo's app on Android fails to render properly
Outside the US:
- Mail.ru web app fails to render properly
- Yandex web app fails to render properly
- Orange's app on Android fails to render properly
- Terra web app fails to render properly
- I was unaware of Libero, but have confirmed it fails to render properly
- Telstra web app fails to render properly
- T-online web app fails to render properly
Probably there are more foreign providers that similarly fail to work properly, it's hard to enumerate them all.
The crucial piece of information for hermes' authors is that CSS inlining is incredibly difficult to keep up with. Each version of CSS you want to support takes an order of magnitude more work to get functioning than the previous version. So for example CSS2.1 took 10x the effort that it took me to implement CSS1. CSS3 support in email is now being supported on certain clients, and I imagine that those selectors will take 10x more work than CSS2.1.
Anyways, you get the idea. You see a minor issue like this and think "hey, no big deal", but this is a slippery slope. Before you know it you're going to get issues filed for improper selector support, precedence issues, debates of W3C semantics, all of which distract from your project's main purpose.
Problem solved using this go library
https://github.com/vanng822/go-premailer
previously I want make PR to include this library to hermes, but I think i'ts not necessary.