Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mc:edit on <img> tag breaks 2x/retina images #37

Open
colinchan89 opened this issue Aug 20, 2016 · 22 comments
Open

mc:edit on <img> tag breaks 2x/retina images #37

colinchan89 opened this issue Aug 20, 2016 · 22 comments

Comments

@colinchan89
Copy link

colinchan89 commented Aug 20, 2016

I created a responsive template for an email newsletter and we wanted to use 2x/retina images. It looked great on all platforms except for Outlook, where it would retain its full dimensions. It took a while to realize that having mc:edit on the img tag was the problem, and moving mc:edit to the containing td or div fixed the issue. While for our needs, the issue is fixed, I bring it up because having the mc:edit on the img tag gives different options in the Mailchimp in-browser editor that our team preferred. If it could be possible to allow for mc:edit to be used on the img tag without retaining the original dimensions, that would be ideal.

@jonleverrier
Copy link

+1

@willryanuk
Copy link

+1
I'm wondering if there is a way to surround the image with some sort of DIV with max-width or width specified to then force the image not to grow beyond its intended bounds. But again, I don't think Outlook is going to respect that. When you have mc:edit on images, it strips the width and height attribute. I'm emailing with Mailchimp support now to see what workaround options there are. Its kinda boring stuff, because right now, the client still needs to go through every image and specify explicit dimensions in the MailChimp editor to get the retina emailer to display correctly in Outlook.

@nyckelplaya
Copy link

Did anyone find a solution to this? It's hard for me to believe that this is still an issue with responsive emails being so popular. Their own documentation specifies to use mc:edit directly on images:

  • mc:edit="" should be used on a div, table cell, or any other element that can be considered a ‘container.’
  • mc:edit should be placed on an <img> element. This will allow the app to call up an image upload and editing dialogue.

Thanks for the hint about using it on the container td. Definitely not ideal, but at least it works.

@willryanuk
Copy link

I seem to remember that an update made by MailChimp a few months ago may have resolved (or perhaps alleviated) this issue but I'm not 100% sure without delving back into it...

@nyckelplaya
Copy link

Thanks - that would be good news if I weren't battling this issue today! Maybe I'm just unlucky. There are no display issues sending from Mailgun or within EmailOnAcid, so it still seems to be Mailchimp's issue. I will try some additional tricks to see if I can constrain the images via containers. Not much hope there, but who knows. Thanks for the quick reply!

@nyckelplaya
Copy link

Ah yes, silly me. When adding the images, there's a spot to explicitly set the dimensions. If you do that, then Outlook honors those dimensions.

@ableandre
Copy link

ableandre commented Oct 10, 2017

It seems I'm still running into this issue in 2017 — per @willryanuk's comment: did anyone ever figure out a way to explicitly state max-width width or height to a wrapper so that retina images always stay that size, even if edited (mc:edit)?

I can't seem to get Outlook to respect it:

				<!--[if (gte mso 9)|(IE)]>
				<table>
					<tr>
						<td height="70" width="70" style="width: 70px !important; height: 70px !important;">
				<![endif]-->
				<img mc:edit="new-hires-img" width="70" height="70" src="https://gallery.mailchimp.com/05bb36e7093ce1334a29efeda/images/02c603e9-35d8-46ee-bdfb-c9cdd9ea9784.png" alt="New Hire Photo">
				<!--[if (gte mso 9)|(IE)]>
						</td>
					</tr>
				</table>
				<![endif]-->

Also, I saw that @nyckelplaya mentioned the spot to set h x w values, but I'd love for my clients to be able to skip that step. Person clicks on image that's editable, replaces the image with a retina one (twice the size of the container), not have to edit the height/width amounts.

Any ideas?

@willryanuk
Copy link

This has not resolved last time I checked with support (July 2017). I've reached out for support, but the MailChimp team basically say NO. As soon as you want to edit using the Drag and Drop editor, things break. The solution from them is that you should use Code Your Own every time and then not edit that upload in MailChimp. Obviously, that isn't suitable for people without coding skills which is why the drag and drop editor is useful.

In the end, we built our own editor which our clients can use to create the retina layouts, with images, links and alt text, and then they upload that.

If you want to see the full email exchange with tech support, you can read it here. But as I mention, MailChimp seem unwilling to engage with the developer community to alleviate things like this, which have been going on for years...

@ableandre
Copy link

ableandre commented Oct 11, 2017

Well that's a huge bummer @willryanuk. I'm not sure if this will help, but I know a couple developers at their MailChimp Atlanta HQ. I'll reach out and see if they can have any influence or solutions to these issues. 🙏

@iamtahirk
Copy link

The solution at Email on Acid works perfectly for retina images but the problem is mailchimp's mc:edit tag as pointed out by @nyckelplaya.

@nyckelplaya
Copy link

@ableandre, @iamtahirk - I'm not sure why this still hasn't been fixed. It's a core problem that affects paying users. And my hunch is that it impacts a lot more people who don't even realize it. I've had to train my clients to set the dimensions manually, and then send a test message to Outlook every single time. just to be safe. Pretty annoying for all of us. Bummer, indeed.

@iamtahirk
Copy link

Exactly @nyckelplaya. This is what most of the time happens to me. Clients needs retina images to look fancy on smaller screen and if we do that it breaks outlook. Don't know why they haven't addressed the issue, it's been quite a long time.

@callmegoon
Copy link

+1

I can't believe this is still an open issue!

@cossssmin
Copy link

cossssmin commented Mar 4, 2018

This is unbelievable, what's so hard to get it fixed, MailChimp?

If I use mc:edit on an <img>, the width and max-width inline CSS, as well as the width="" attribute are obliterated by the editor.

If I use mc:edit on something that wraps the <img>, it of course loads the rich text editor where I need to double click the image, close the link overlay, and finally click "Back to files" in order to change it.

In both scenarios, once I select an image and click to insert it, I need to be sure I manually set the correct width and no height (unchecking "keep proportions"), otherwise if it's an image smaller than the container, it will be blown up on mobile by the responsive image CSS.

Besides developers who do custom templates for clients to edit visually in MailChimp, there are literally thousands of paying customers that are buying custom templates from marketplaces. To then use your editor and get this behavior.

How is this still an issue?!

@daniel-thisnow
Copy link

I am new to the misfortune of mail chimp s poor custom template functionality. I didn't know how lucky I was using adestra. I actually moved a few mc:edit 's from Divs to IMG tags - and now i know why, i shall move them back.

It is really going to make it harder and likely to cause mistakes editing the images though the wysiwyg dialog.

Come on - pull your fingers out.

@matchboxhero
Copy link

As far as I can tell this is still an issue, using the mc:edit on an image causes the image to ignore all given dimensions in Outlook.

@titodevera
Copy link

Same problem here! :(

@Iurisdoc
Copy link

Iurisdoc commented Jul 12, 2019

+1

8 hours to find out the problem and now a see this forum.

MC-EDIT in is the problem!

To solve it, i put around the img tag and span tag with mc-edit.

Hope it will be usefull for you

@ldepender
Copy link

ldepender commented Dec 5, 2019

an other option is when you don't want to use the span tag (like me because i want a image inserter not a wysiwyg editor for he image

On the image add a max width for your column width from the table:

<img src="your source" mc:edit="image" style="max-width: 300px" />

Hope this will help others aswel.

@stevemansfieldux
Copy link

stevemansfieldux commented Jan 30, 2020

+1

I've had this issue with clients for about 3 years now, I have to send clients documentation and make them aware of the issue.

max-width works everywhere except outlook.

Making the td mc:edit works but again, you lose the image editor as people have said.

The span is again a similar fix mentioned above, but you lose the image editor.

Most of my clients now just opt for 1x images to save themselves the manual leg work and it's shocking support having reached out on numerous occasions over the last 3 years.

I came back now to check after 6 months to see if any progress and it seems you're all still experiencing the same issues.

I've started persuading clients to move away from the platform as when I take on new work, I send them a 'All the things we can't do in Mailchimp' document.

@adrianjean
Copy link

adrianjean commented Feb 25, 2021

My solution:

It seems as though despite putting the image width in the template, MC doesn't recognize it on import. You have to leave the "src" empty, and select an image to fill it inside the MC editor. I think once the MC editor places the image in the editable space, it re-initializes the size of the image in the template code and it seems to work.

Note, I still have not been able to get 2x res images to work tho. Uploading a larger image and setting the dimensions in the MC editor just resamples the image smaller... so.. it's a half solution.

@alexbovey
Copy link

How is this still not fixed in 2024?!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests