fix for Image Center Aligment issue

[vbence86]

Disclaimer

Use of transform attribute is not broadly supported by HTML Email preprocessors resulting in unexpected display of HTML constructed by AlloyEditor.

For more informations please check #766.

Intent

To provide an implementation supported by HTML Email processors to align images to the centre of the area which incorporates it.

Solution

• After a good deal of research about what the best way is to center-align images in HTML Emails, I removed transform attribute and utilized margin-left:auto along with margin-right:auto attributes.

HTML Email rendering engines

Tested against the following HTML Email rendering engines

• Outlook 2003
• Outlook 2008
• Thunderbird 2
• Thunderbird 3
• Gmail
• iPhone 6 iOS 8
• Apple Mail
• Gmail on Android 5.1.1

[jbalsas]

Hey @vbence86, this looks quite impressive, nice work!

Just a couple of thoughts:

• Last fix seems to have broken some tests
• Our usual approach is to provide support by enhancing the configurability and extensibility of our products while providing sensible defaults.

Rather than trying to reach full email support (which we never intended), we should make the image alignment commands configurable so users with that need can fix that on their own.

I think the first change makes sense as a sensible default, so I would propose we merge just that and then, if needed, work on ways to make the plugin configurable.

What do you think?

[vbence86]

I agree on the points you've brought up. Besides, HTML Email renderers should actually keep their tech aligned with modern standards. My venture seemed only reasonable due the small effort it needed to transform the default behavior into a sort of de-facto cross-platform standard. But with the tests failing with no apparent reason, I'm happy to step back.

[duracell80]

This is would be nice but is wishful thinking ... "HTML Email renderers should actually keep their tech aligned with modern standards.".

I noticed DXP going towards AE instead of CK on email templates, this could potentially open up a can of worms for HTML email situations beyond rich text.

Unless the editor can be given context (which I really would advocate for) there's no one size fits all that's going to work. By context I mean, AE should be able to know that the content being created is for an "email" or a "document" or "technical manual" or an "article" or a "discussion". In the case of email the editor would then produce HTML4 content not HTML5 and would apply different approaches to inline styles (as well as head styles). Head styles for Outlook that begin with a dot only like .tableone are generally ignored, the code would need to refactor as table.tableone.

In any case as a HTML email creator myself I always hand code, there's no useful case for WYSIWYG in creating emails, it'll only lead to heartbreak and tears.