Gmail compatibility using Emoji about versafix-template

[francescbassas]

Returning to this and trying to think what might be the best solution...

The conflicting line: https://github.com/voidlabs/versafix-template/blob/master/template-def/template-versafix-1.htmml#L342C1-L342C41

Maybe turning display: block only for a mosaicoimg class?

img.mosaicoimg { display:block;}

And then adding this class to all existing images in the template?

[bago]

Of course this is a bug from Gmail, so I'd treat it as a bug in Gmail, and put a specific workaround instead of altering the way we deal with things.

My first attempt at fixing this would be something similar:
img[data-emoji] { display: inline }

or maybe, even better, something more gmail specific:
u + div img[data-emoji] { display: inline }

(This should be reported to Google that should add to their replaced emoji some inline style or some !important css overriding the email css)

[francescbassas]

Thanks @bago

img[data-emoji] { display: inline } makes sense for me. I will try it in our versafix based templates.

[bago]

Let me know if it works.
Also, give a try to the "u+div " prefixed version, as it is a gmail specific targeting technique.

[francescbassas]

@bago I deployed img[data-emoji] { display: inline } solution in a production environment and emojis now are displaying inline. Thanks!

[francescbassas]

@bago, I'm realizing that this patch doesn't fix the problem in the end. The styles are applied before the email is sent and before Google converts the emojis into images. It must have been set incorrectly when I tested, sorry.

I think the solution needs to go in the direction pointed in this other comment #41 (comment) restricting the scope of the display:block for images.

[bago]

I looked at this and I think the best options is to simply change
img { border: 0px; display: block; }
to
img:not([data-emoji]) { border: 0px; display: block; }

Note that the content of ":not(...)" is just cosmetic as the ":not" is just a way to prevent the rule to be read from Gmail (Gmail does not support :not). "img:not(a)" would work the same, but I'd use not([data-emoji]) so to make it more explicit why we need that workaround. The rule will anyway do its work on gmail because we do inlining so we add that border and display rules to every img tag before saving.

I also think maybe it is safer to move the img rule at the end of its style block (sometimes css parsers stop parsing the whole thing when they found rules they don't understand).

[francescbassas]

Thangks @bago. It works