Open WebPhenom opened 8 years ago
I can currently not reproduce this. Can we get a reproducible test case?
Using their online inliner produces some strange things.
https://foundation.zurb.com/emails/inliner-v2.html
On Thu, Dec 19, 2019 at 12:55 AM Daniel Ruf notifications@github.com wrote:
I can currently not reproduce this. Can we get a reproducible test case?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/foundation/foundation-emails/issues/586?email_source=notifications&email_token=AAG6NXU6PBRM4MWRCNG6N5DQZMZIVA5CNFSM4CP4EB42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHI4XVQ#issuecomment-567397334, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG6NXVGILCB2466CVHKPLDQZMZIVANCNFSM4CP4EB4Q .
Ah now I understand. Your comment was not correctly formatted. You mean the htmlentities. We do not enforce them there. But you can do tgat in your foundation-emails project setup.
Proof that htmlentities are not enforced there:
See the default setting for "Decode Entity Characters" of the used library:
Then my browser thinks its a bad character and shows a black diamond with a question mark.
Not sure which browser does this today.
When I enter valid endashes in my code like
–
the inliner spits our NON HTML endashes like this:-
Then my browser thinks its a bad character and shows a black diamond with a question mark.
I dig deeper and my code uses UTF 8 and when I swapped that out with ISO-8859-1 the browser recognized the endash again.
But this is backwards, why is the online inliner not coding with UTF -8? and why not just NOT touch HTML coded endashes and leave them as –
So two issues here. Please advise.