Apostrophes seem to be breaking the html rendering. The MJML code below has 2 mj-text blocks in succession. With the apostrophe in "doesn't", it breaks the HTML rendering in the subsequent mj-text block--looking at the generated HTML, the second
This can be replicated on http://miml.io/try-it-live/ using the code below. This is a new issue that cropped up recently--the same code worked on try-it-live a few days ago.
<mjml>
<mj-body>
<mj-container>
<mj-section padding="0">
<mj-column>
<mj-text font-size="18px" color="#b94f27" font-family="helvetica" padding-bottom="0px" font-weight="bold">Why doesn't this work?</mj-text>
<mj-text font-size="16px" color="#5d5d5d" font-family="georgia, serif" line-height="24px" padding-top="5">This should be on a new line with a new font...</mj-text>
</mj-column>
</mj-section>
</mj-container>
</mj-body>
</mjml>
Render With Apostrophe

Render Without Apostrophe

Hi @ericboles, thanks for opening the issue and big up for making it so clear with code and screenshots 👍
This is an issue related to the encoding of special characters in v3.3.0 (beta.3), we'll fix it in a future update, thanks for spotting it! If needed, please note that you can use the v3.2.2 locally (see install MJML locally) where this issue isn't happening.
Cheers
Hey @ericboles, sorry I didn't update you earlier, it was fixed in MJML and it's fixed on the try it live editor too!
Thanks again for reporting :)
Thanks @ngarnier. That's working now--good to see. That said, somewhere along the way we seem to have lost the ability to retain HTML entities in the conversion from MJML to HTML. The entities are now output as their respective characters...like → instead of →
We've often found not using the entity can cause problems in older clients... And further problems when you want to take advantage of to ensure a call to action like "Read More" doesn't line break in the middle.
Any chance of retaining the entities?
I think you're describing issue #343. We also have this problem and as a workaround we encode our content twice before inserting it into our MJML (turning a literal & into &amp; ... but watch out for ' because certain versions of outlook don't like it- use ' instead).
Hopefully when the parser work is finished we can remove this hack!
@levilansing sorry for posting on an old issue but this is still a problem in v3.3.5. I should not have to use the double encode hack for URLs right? (URLs with question marks, and apostrophes)
It wasn't immediately obvious to me because, for example, was just showing up as a space in the compiled HTML.
AFAIK it is still an issue in v3.3.5. It was my understanding the underlying issue would be fixed in 4.0 because of a new parser. However, I haven't tried it out yet and haven't seen any activity on the related issues.
@tolusonaike indeed it's an issue, but as pointed by @levilansing on February 25th, you're describing a different issue (#343).
Most helpful comment
Hi @ericboles, thanks for opening the issue and big up for making it so clear with code and screenshots 👍
This is an issue related to the encoding of special characters in v3.3.0 (beta.3), we'll fix it in a future update, thanks for spotting it! If needed, please note that you can use the v3.2.2 locally (see install MJML locally) where this issue isn't happening.
Cheers