Breaks Responsive Layout with Foundation for Emails

[adueck]

I looove the idea of having an inliner available in GO. Thank you so much for writing this.

Unfortunately for me though, it doesn't work for inlining emails written with [Foundation for Emails].

Before inline:

After inline:

It works fine when using another inliner, inline-css (with node), but somehow the inlining with with go-premailier is breaking it.

For a full example of the email and broken output:

HTML with embedded CSS before inlining

HTML after inlining with inline-css npm package - This works 👍

HTML after inling with go-premailer - This is broken 😢

I hope this is helpful... I would looove to be able to inline these in Go without having to do slow calls out to a separate node script.

Thanks!

[vanng822]

Thanks for reporting this issue!

This package has only basic functionalities and is not really matured since not many try it out.

After a quick look I see that "!important" is one of the difference(s). I will take a close look later when I have time Otherwise you can try and fix so it comes into the inline (probably somewhere in element.go)

[adueck]

Thanks so much for having a look, and for your quick response.

Sorry I didn't dive deep into the differences, but I though the least I could do was offer the files. 🤔

For now I'm using a really slow call out to a node script running inline-css, but it would be really awesome if this could get sorted and I'd use this. 👍 (Plus lots of others using Foundation hopefully)

Another little issue I noticed is that it turns the  s into spaces. These should be left as is too.

[adueck]

Oops didn't mean to hit the close button...

[adueck]

I should also mention that in order to get it to work with inline-css I needed to set the following options:

options.preserveMediaQueries = true;
options.applyTableAttributes = true;

Whether to apply the border, cellpadding and cellspacing attributes to table elements.

Is this the main problem? 🤔

[vanng822]

I found the problem. A sort causing that padding:0 is placed after paddin-* and override all. I haven't looked into   but probably has to do with github.com/PuerkitoBio/goquery hopefully that we can pass some flags to keep html entities. We should split up this into 2 issue. One with broken css-applied which I can fix as soon as possible

[vanng822]

Ok, the problem is bigger than I thought so it will take sometimes. I did a wrong assumption and have to redo both css and this packages to make css work better.

[vanng822]

I think your problem should be fixed.

Regarding the hard whitespace. I think goquery encodes it to hard whitespace according to unicode

Please try it out and confirm. You need to upgrade css as well

[adueck]

Great! Thanks so much. It seems to be working now except one other strange little bug that I can see...

When the email begins with a line containing 3 (or sometimes 4) characters, it breaks the line like this:

Here the H in <div>Hi,<br/><br/>This is an email</div> is floating on the right and to far over the container margin.

MISTAKEN/CORRUPTED HTML FILES REMOVED - WILL REPOST IN A COUPLE OF DAYS

How it looks with original HTML file and after node inline-css:

[vanng822]

What is your OS and browser. I don't have that issue on Mac (Firefox, Chrome, Opera). It looks like that the node version not the same as the original on my computer. Go version and original looks the same.

[vanng822]

I think the node version generate also invalid attribute such as width="100%%" Another question is why do we have value in "100%%" ie 2 "%"

[adueck]

Sorry, something strange happened with the html files I saved... Those are not right at all.

I also realized that the spacer table used at the beginning gets squished a little smaller in the go-premailer version. It might have something to do with that.

Don't have time now but a couple of days I will be able to give you proper html files and detailed examples.

Thanks so much for your work on this. I'm surprised it's not more widely used/popular. Would be great if this can become the go-to css inliner for GO. 👍 (I couldn't find any other lib out there!)

(Also the double percentage thing could be from a different problem on my end... anyways, more in a couple of days!)

[adueck]

Ok, here are some proper examples

Original File

After Inlining with inline-css

After Inlining with go-premailer

The inlining from go-premailer makes it look broken like this for Chrome on Windows (But not Firefox)

[vanng822]

Look like the problem is when converting to html-attribute of text-align and vertical-align. It seems not an easy thing and probably time-consuming. I will remove that support (since there are recommendation not using it). Without align and valign, it looks quite good.

Edit: This means that if you run with option.CssToAttributes = false it should work better

[vanng822]

Please give it a try and see if you are happy with the result.

I think the attribute conversion is complex so I will remove it complete in the future version. It should still work well for modern browsers

[adueck]

Thank you. With option.CssToAttributes = false that does look better now in my browser.

As you mentioned:

It should still work well for modern browsers

However, the problem with writing HTML/CSS for email clients is that you can't rely on modern browser standards. Email clients are notorious for not supporting modern HTML5 features and to having bad compatibility, so you have to write old style HTML

https://www.campaignmonitor.com/css/

Every single email client reading your email is going to have it's own rules about how it deals with HTML emails, so you are going to have to design for the lowest common denominator. Think it's a pain having to test websites in 4-5 different browsers? It's much worse with email.

https://css-tricks.com/using-css-in-html-emails-the-real-story/

It may look good in the latest version of Chrome, but that's no guarantee that it will be production ready to send to all of different email clients that haven't been tested unfortunately.

I'm really thankful for your work on this, and I would love for there to be something very reliable for Go. If you are able to work more on it, I'm sure it could be a huge use of a lot of people. 😃

[vanng822]

I hope that more people can help out. It started as a project to learn go and to prove that go can do faster than the python version (even I optimised the python version 5-10 times faster).

I have been using this for the latest 3 years but my css is to simple so that's why I never seen those bugs. Thanks for reporting.

[vanng822]

If you are happy for now please close the ticket. Let's see if there are some document how to map css to attributes. If you find one just notify me

[adueck]

Ok, I will close and see how things work out. Thank you for your help, and yes you're right Go can do it much much faster!

[vanng822]

No problem