Related
I'm sending an e-mail newsletter in HTML.
Inside the HTML I have something like
<img height='70' width='70' style='display:block' src='myDomain.com/imageName.png'>
When I open the newsletter with Thunderbird or Outlook, the image is being displayed. However, when I open it with Gmail, no image is shown.
I'm not sure if it's about the proxy that Gmail uses for security reasons or if it's something else. Either way, I'd like to know if anyone ever came across this and if so, how it was solved.
Late to the party but here goes... I have experienced this problem as well and it was solved with the following:
Including the scheme in the src url (using "//" does not work - use full scheme EG: "https://")
Including width and height attributes
Including style="display:block" attribute
Including both alt and title attributes
EG:
<img src="https://static.mydomain.com/images/logo.png" alt="Logo" title="Logo" style="display:block" width="200" height="87" />
For me, the problem was using svg images. I switched them to png and it worked.
Google only allows images which are coming from trusted source .
So I solved this issue by hosting my images in google drive and using its url as source for my images.
Example:
with:
http://drive.google.com/uc?export=view&id=FILEID'>
to form URL please refer here.
Please also check your encoding: Google encodes spaces as + instead of %20. This may result in an invalid image link.
You might have them turned off in your gmail settings, heres the link to change them https://support.google.com/mail/answer/145919?hl=en
Also gmail may be blocking the images thinking they are suspicious.
from the link above.
How Gmail makes images safe
Some senders try to use externally linked images in harmful ways, but
Gmail takes action to ensure that images are loaded safely. Gmail
serves all images through Google’s image proxy servers and transcodes
them before delivery to protect you in the following ways:
Senders can’t use image loading to get information like your IP
address or location. Senders can’t set or read cookies in your
browser. Gmail checks your images for known viruses or malware. In
some cases, senders may be able to know whether an individual has
opened a message with unique image links. As always, Gmail scans every
message for suspicious content and if Gmail considers a sender or
message potentially suspicious, images won’t be displayed and you’ll
be asked whether you want to see the images.
Try to add title and alt properties to your image.... Gmail and some others blocks images without some attributes.. and it is also a logic to include your email to be read as spam.
I noticed that Google was stripping the src attribute from my img tags. I tried every answer on this page - with no luck.
What finally worked for me was replacing img tags with divs that have background images. For example, instead of:
<img style="height: 24px; width: 24px; display: block;" src="IMAGE SOURCE"/>
I replaced it with:
<div style="height: 24px; width: 24px; display: block; background: url(IMAGE SOURCE); background-size: contain;"></div>
Hope this helps others who spent way too long pulling their hair out over this.
In addition to what was said by Howard
You have to keep in mind that Google encodes spaces as +
To avoid this, the ulr must be encoded in RFC 3986, which means spaces encoded at %20, for example:
https://example.com/My Folder/image 1.jpg
to
https://example.com/My%20Folder/image%201.jpg
I had the same issue and for me it was because I was using an SVG image, once I changed to a JPG or PNG, it worked. Maybe this can assist someone who will come across the same issue. It seems Gmail doesn't support SVG images.
HTTP or HTTPS should be full address
background-image: url(http://fulladdress.com/ca/1/product_assets/T/C/X/M/K/NMTCXMK_mu.jpg)
var mailOptions = {
from: 'fulladdress#gmail.com',
to: emails,
subject: 'i super another ma node mailer cool test',
text: 'That was easy!',
html: '<div style="background-image: url(http://fulladdress.com/ca/1/product_assets/T/C/X/M/K/NMTCXMK_mu.jpg);width:500px;height:500px">ascfas</div>'
};
I know Gmail already fix all the problem above, the alt and stuff now.
And this is unrelated to the question but probably someone experiences the same as me.
So my web designer use "image" tag instead of "img", but the symptom was the same. It works on outlook but not Gmail.
It takes me an hour to realize. Sigh, such a waste of time.
So make sure the tag is "img" not "image" as well.
My issue was similar.
This is what my experience has been on testing the IMG tag on gmail
(assuming most of the organization's would have a dev qa and prod server.)
I had to send emails to customers on their personal email id's and we could see that gmail would add something of its own like following to src attribute of img tag. Now when we were sending these images from our dev environment they would never render on gmail and we were always curious why?
https://ci7.googleusercontent.com/proxy/AEF54znasdUhUYhuHuHuhHkHfT7u2w5zsOnWJ7k1MwrKe8pP69hY9W9eo8_n6-tW0KdSIaG4qaBEbcXue74nbVBysdfqweAsNNmmmJyTB-JQzcgn1j=s0-d-e2-ft#https://www.prodserver.com/Folder1/Images/OurImage.PNG
so an image sent to my gmail id as following never worked for me
<img src="https://ci7.googleuser....Blah.Blah..https://devserver.com/Folder1/Images/OurImage.PNG">
and our dev server we can't render this image by hitting following URL on Chrome(or any browser).
https://www.devserver.com/folder1/folder2/myactualimage.jpg
now as long as the src has www on it worked all the time and we didnt had to add any other attributes.
<img src="https://www.**prodserver**.com/folder1/folder2/myactualimage.jpg">
I was using Cloudflare. As soon as I disabled the proxy for my host's website IP address images in Gmail appeared immediately.
I have now added a new firewall rule to allow requests where the URI contains 'googleimageproxy' and everything is working fine.
I am even later to this party, but after spending about 2 hours trying everything imaginable and not having any luck, I finally realized it will work if I upload the pics to GOOGLE PHOTOS instead of GOOGLE DRIVE. Then I can right-click on the pic, copy the address, paste it in, and it works beautifully.
In backend i created endpoint for showing images. Laravel code looks like:
public function getImage($name)
{
return response()->file(base_path() . '/resources/img/' . $name . '.png');
}
Then in my html email template i created div with background-image.
<div style='background: url("https://mysite1.com/api/v1/get_image/logo")'></div>
And it's works for me.
I tried another image from internet which url starts https://
it worked on gmail and outlook.
get your images from domain which has SSL.
For me, the problem was using images name as equity investments.png . I switched them to equity_investments.png and it worked.
Not working :-
<img src="https://xxxxxxx.com/webinar_images/equity investments.png" alt="" />
Working :-
<img src="https://xxxxxx.com/webinar_images/equity_investments.png" alt="" />
I tried all the suggestions this thread (setting width, height, title, full url, etc). The final fix for me was switching from SVG to PNG did the trick for me.
I then tried removing all the other extra decorators (title, display block), and it still worked as long as I left the image type as PNG. So, PNG seems to be the only required change.
In the noble effort to re-invent every wheel, our company has recently rolled our own custom web-based e-mail app, of which I was the primary designer.
One thing I've noticed is that smileys coming in from MS Outlook-based e-mails (sent from third parties) are not appearing correctly. Example: A happy face just displays a J
The HTML of the inbound message comes in like this:
<span style="...;font-family:Wingdings;...">J</span>
I know that Firefox and Chrome do not support the Wingdings font because it is non-standard. However, I am tasked with coming up with a fix.
Is there a good way to either 1) force the browser to load and use Wingdings or 2) otherwise convert the J to a smiley?
I'd rather not do anything crazy like try some wingdings-detection-regex - or even worse, parse the DOM - just to get some stupid emoticons working. Maybe there is already some library out there that already handles this?
For what it's worth, GMail seems to not 'fix' this problem either. iOS doesn't in the message view, but puzzlingly does fix it in the inbox view (replaces the J w/ emoji)
EDIT
To clarify, this question is regarding inbound messages from third parties. Outlook, by default, autocorrects ":)" to the Wingdings smiley. There's nothing I can do to prevent this coming in. What I need is a solution to correct for this.
EDIT 2
Again, the app itself is a web based e-mail client (Gmail, etc.). E-mails go in to here, NOT to users' individual Outlook/phones/other e-mail clients. It only goes into the web app.
To avoid having to parse the HTML or manipulating the DOM, a simple solution would be to use CSS3 web fonts by linking the Wingdings font-family to a copy of the Wingdings font file on your server:
<style>
#font-face {
font-family: Wingdings;
src: url(link_to_wingdings_font_file.ttf);
}
</style>
However, a license is required for this approach.
You could embed the SWEC (Symbola-based Wingdings Emoticons Compatibility) font: https://drive.google.com/open?id=0BwDrnPQfa-aMOEx0bEZCQUNrSGs
It provides basic compatibility with Wingdings emoticons. (In Wingdings, "J" represents a smile, "K" represents a lack of expression, and "L" represents a frown.) Background: certain versions of Microsoft e-mail clients still in use change user-typed expressions such as ":)", ":|", and ":(" into "J", "K", and "L", respectively, and then specify Wingdings as the font family; recipients on systems which do not include a Wingdings-compatible font are not able to see the intended emoticons, which can cause confusion.
You need to manually substitute it prior to sending the email as you have no control over what fonts the reader has installed. You also can't include anything outside bland old html and css (unless you want to mess with VML)
First I would try running your wingding through a html converter to see if there is a html code for it.
Besides that, you could try a webfont wingdings equivalent, however there are issues with Outlook playing nice when webfonts are imported in email (ignores your font stack, falling back to Times New Roman).
Besides that, all that is left is ZephyrusDigital's suggestions of using an image or :).
Against my better judgement I have decided to go for the quick hack and just use a regular expression. Here it is for anyone else that runs into the same problem:
$html = preg_replace('/\<SPAN*?(Wingdings)*?[^\>]*\>J(\<o\:p\>\<\/o\:p\>)*\<\/SPAN\>/i', ' :) ', $html);
use :)
kidding!
why not save the wingdings smiley in photoshop as a png, or make another custom one? you could use <img src="http://something.com/images/smiley.png" style="display:inline-block;"/> and it won't look weird in a text block as long as it isn't taller than your line-height.
i have 2 errors coming up on firefox. Theses errors are shown below.
1-there is no attribute "property". This refers to the line below:
<meta property="og:title" content="blahblahblah"/>
This is to do with linking it to social networks i.e facebook etc
2-there is no attribute onerror. This refers to the line below:
<img src="281.jpg" width="125" height="125" onerror="onImgErrorSmall(this)"/>
This basically displays a default image if the actual image dose not show up.
the question really is, i know these are not valid attributes but how can i get around them, if anyone has any ideas id be grateful.
For the meta tag there is no property attribute
For the img tag there is no attribute called onerror
No way to get around them as they are not part of the html markup
Live with them or remove - they will never validate against a web standard
You pasted stuff into a wysiwyg editor directly from Microsoft Office or OpenOffice document.
These properties are proprietary.
You should clean up or remove the markup before pasting. (Most of wysiwyg editors in use today have this function (a.k.a. paste from Word))
This link may be able to help you out.
onerror is only supported by the "browser" that Microsoft makes.
I have an image that I will dynamically populate with a src later with javascript but for ease I want the image tag to exist at pageload but just not display anything. I know <img src='' /> is invalid so what's the best way to do this?
Another option is to embed a blank image. Any image that suits your purpose will do, but the following example encodes a GIF that is only 26 bytes - from http://probablyprogramming.com/2009/03/15/the-tiniest-gif-ever
<img src="data:image/gif;base64,R0lGODlhAQABAAD/ACwAAAAAAQABAAACADs=" width="0" height="0" alt="" />
Edit based on comment below:
Of course, you must consider your browser support requirements. No support for IE7 or less is notable. http://caniuse.com/datauri
While there is no valid way to omit an image's source, there are sources which won't cause server hits. I recently had a similar issue with iframes and determined //:0 to be the best option. No, really!
Starting with // (omitting the protocol) causes the protocol of the current page to be used, preventing "insecure content" warnings in HTTPS pages. Skipping the host name isn't necessary, but makes it shorter. Finally, a port of :0 ensures that a server request can't be made (it isn't a valid port, according to the spec).
This is the only URL which I found caused no server hits or error messages in any browser. The usual choice — javascript:void(0) — will cause an "insecure content" warning in IE7 if used on a page served via HTTPS. Any other port caused an attempted server connection, even for invalid addresses. (Some browsers would simply make the invalid request and wait for them to time out.)
This was tested in Chrome, Safari 5, FF 3.6, and IE 6/7/8, but I would expect it to work in any browser, as it should be the network layer which kills any attempted request.
These days IMHO the best short, sane & valid way for an empty img src is like this:
<img src="data:," alt>
or
<img src="data:," alt="Alternative Text">
The second example displays "Alternative Text" (plus broken-image-icon in Chrome and IE).
"data:," is a valid URI. An empty media-type defaults to text/plain. So it represents an empty text file and is equivalent to "data:text/plain,"
OT: All browsers understand plain alt. You can omit ="" , it's implicit per HTML spec.
I recommend dynamically adding the elements, and if using jQuery or other JavaScript library, it is quite simple:
http://api.jquery.com/appendTo/
http://api.jquery.com/prependTo/
http://api.jquery.com/html/
also look at prepend and append. Otherwise if you have an image tag like that, and you want to make it validate, then you might consider using a dummy image, such as a 1px transparent gif or png.
Use a truly blank, valid and highly compatible SVG, based on this article:
src="data:image/svg+xml;charset=utf8,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%3E%3C/svg%3E"
It will default in size to 300x150px as any SVG does, but you can work with that in your img element default styles, as you would possibly need in any case in the practical implementation.
I haven't done this in a while, but I had to go through this same thing once.
<img src="about:blank" alt="" />
Is my favorite - the //:0 one implies that you'll try to make an HTTP/HTTPS connection to the origin server on port zero (the tcpmux port?) - which is probably harmless, but I'd rather not do anyways. Heck, the browser may see the port zero and not even send a request. But I'd still rather it not be specified that way when that's probably not what you mean.
Anyways, the rendering of about:blank is actually very fast in all browsers that I tested. I just threw it into the W3C validator and it didn't complain, so it might even be valid.
Edit: Don't do that; it doesn't work on all browsers (it will show a 'broken image' icon as pointed out in the comments for this answer). Use the <img src='data:... solution below. Or if you don't care about validity, but still want to avoid superfluous requests to your server, you can do <img alt="" /> with no src attribute. But that is INVALID HTML so pick that carefully.
Test Page showing a whole bunch of different methods: http://desk.nu/blank_image.php - served with all kinds of different doctypes and content-types. - as mentioned in the comments below, use Mark Ormston's new test page at: http://memso.com/Test/BlankImage.html
As written in comments, this method is wrong.
I didn't find this answer before, but acording to W3 Specs valid empty src tag would be an anchor link #.
Example: src="#", src="#empty"
Page validates successfully and no extra request are made.
I found that simply setting the src to an empty string and adding a rule to your CSS to hide the broken image icon works just fine.
[src=''] {
visibility: hidden;
}
if you keep src attribute empty browser will sent request to current page url
always add 1*1 transparent img in src attribute if dont want any url
src="data:image/gif;base64,R0lGODlhAQABAAAAACwAAAAAAQABAAA="
I've found that using:
<img src="file://null">
will not make a request and validates correctly.
The browsers will simply block the access to the local file system.
But there might be an error displayed in console log in Chrome for example:
Not allowed to load local resource: file://null/
Building off of Ben Blank's answer, the only way that I got this to validate in the w3 validator was like so:
<img src="/./.:0" alt="">`
I personally use an about:blank src and deal with the broken image icon by setting the opacity of the img element to 0.
<img src="invis.gif" />
Where invis.gif is a single pixel transparent gif. This won't break in future browser versions and has been working in legacy browsers since the '90s.
png should work too but in my tests, the gif was 43 bytes and the png was 167 bytes so the gif won.
p.s. don't forget an alt tag, validators like them too.
I know this is perhaps not the solution you are looking for, but it may help to show the user the size of the image before hand. Again, I don't fully understand the end goal but this site might help: https://via.placeholder.com
It's stupid easy to use and allows to show the empty image with the needed size.
Again, I understand you did not want to show anything, but this might be an elegant solution as well.
<img src="https://via.placeholder.com/300" style='width: 100%;' />
Simply, Like this:
<img id="give_me_src"/>
I'm trying to add localization support to a Google Chrome Web App and, while it is easy to define strings for manifest and CSS files, it is somewhat more difficult for HTML pages.
In the manifest and in CSS files I can simply define localization strings like so:
__MSG_name__
but this doesn't work with HTML pages.
I can make a JavaScript function to fire onload that does the job like so:
document.title = chrome.i18n.getMessage("name");
document.querySelector("span.name").innerHTML = chrome.i18n.getMessage("name");
but this seems awfully ineffecient. Furthermore, I would like to be able to specify the page metadata; application-name and description, pulling the values from the localization files. What would be the best way of doing all this?
Thanks for your help.
Please refer to this documentation:
http://code.google.com/chrome/extensions/i18n.html
If you want to add localized content within HTML, you would need to do it via JavaScript as you mentioned before. That is the only way you can do it.
chrome.i18n.getMessage("name")
It isn't inefficient to do that, you can place your JavaScript at the end of the document (right before the end body tag) and it will fill up the text with respect to the locale.
Dunno if i understand exactly what you are trying to do but you could dynamically retrieve the LANG attribute (using .getAttribute("lang") or .lang) of the targeted tag and serve accordingly the proper values.