What's the valid way to include an image with no src? - html

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"/>

Related

Why is the srcset attribute only working correctly when used before the src attribute in img tags

I'm having a mystery here. The issue itself is worked around by now, but I still can't see the actual cause: On our image sharing site Pixabay.com we recently implemented the srcset attribute for img tags on search results. You can see that in action here: https://pixabay.com/photos/
A typical img tag in there looked like this:
<img src="/image__180.jpg" srcset="/image__180.jpg 1x, /image__340.jpg 2x" alt="...">
It worked very well - for about 99% of all users. However, a few reported to see the issue depicted in this screenshot:
Some 30-50 images loaded correctly on the page, while the others resulted in broken images. We realized, our NGINX log contained a few errors like this:
open() "/.../image__180.jpg" srcset="/image__180.jpg 1x, /image__340.jpg 2x" failed (2: No such file or directory)
Apparently, for an unknown reason, the client requested the whole expression (value of src+"srcset"+value of srcset) as image path, which of course resulted in an error 404.
We played around a bit and realized, first providing the srcset and then the src attribute on the img tags solves the issue. No more error logs, no more complaints.
<img srcset="/image__180.jpg 1x, /image__340.jpg 2x" src="/image__180.jpg" alt="...">
I couldn't find any reports of this behavior anywhere on the web. But I'd like to learn more. Here's the discussion on Pixabay with several users reporting the issue: https://pixabay.com/en/forum/help-me-please-11/pixabay-technical-difficulties-1474/?pagi=2
Do you have an explanation?
There is absolutely no way for a browser to screw this up normally. HTML parsers are rock-solid, they don't randomly eat extra bytes for an attribute.
This is definitely a proxy or some other MITM screwing with the markup somehow. I suggest dropping in some JS that quickly examines all the src attributes on the page and checks if any contain "srcset", and if so, logging as much information as you can about the UA or whatever, so you can try to find a commonality between them.
Suspect it's probably some weird proxy examining/rewriting source, using a regex like /image.*.jpg/ and rewriting it back URL-escaped. That'll catch everything from the start of your src image up to the final .jpg in your srcset, and escape all the spaces and quotes between them so you get a single big src attribute value.
Alternately, since this is apparently delivered over HTTPS, which reduces the chance of proxy rewriting, it may be a badly-behaved extension.

How to change the behaviour of the smiley feature in CKEditor

We use CKEditor to construct emails. Now, when activating the smiley button, the smileys are actually added as
<img alt="smiley" src="<app>/script/webeditor/ckeditor/plugins/smiley/images/regular_smile.png" />
Of course, in an email we can not refer to an internal application URL. So, what are the options here?
Gmail solves this by adding the smileys as inline images of the email
Hotmail solves this by referring to images on a public location
I found documentation about 'BBCode-mode' of the ckeditor, which would add the smiley as [:-)] and let the application which shows the bbcode decide which picture to use.
there are HTML codes to show smileys, but browser support seems to be poor.
My question: which option to use? Are there already plugins available that handle one of those options? Ideally, something like BBCode should be available as valid HTML, supported by all browsers, maybe there is?
I can tell you how to do it with a fixed location for the images (like Hotmail). You have to set a config property like this:
config.smiley_path = "http://www.example.com/images/";
This should render
src="http://www.example.com/images/regular_smile.png"

HTML image not showing in Gmail

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.

<img src="#"> Means in HTML?

I do have the following code in my HTML:
<img src="#" alt="image alternative text" />
What does src="#" mean? Because in HTML, I cannot have empty src attribute for an image tag. And if we do not have that attribute, visual studio 2012 will throw a suggestion.
Thanks
When you don't want any image to be loaded using src attribute (probably load the image dynamically later), you need to set src empty. But when you do that, browsers still send calls to server.
Browser behavior for empty src (Source: http://developer.yahoo.com/performance/rules.html)
Internet Explorer makes a request to the directory in which the page
is located. Safari and Chrome make a request to the actual page
itself. Firefox 3 and earlier versions behave the same as Safari and
Chrome, but version 3.5 addressed this issue[bug 444931] and no longer
sends a request. Opera does not do anything when an empty image src is
encountered.
To avoid the unnecessary call to server, instead of using empty src, src="#" could be used which forms a hash url and hash urls are not sent to server.
Let's say base url is : http://mysite.com/myapp/
src="" -> Absolute url: http://mysite.com/myapp/
src="#" -> Absolute url: http://mysite.com/myapp/#
Most people use it as a placeholder for links just so that there are no errors when the code compiles. If a programmer gave you some code with the "#" as a placeholder, they probably want you to interchange it with a web URL.
As with the href attribute of an anchor element, <img src="#"> is roughly equivalent to <img src="thecurrenturl#" ..> (but see the fiddle example for why it's not identical).
As it is written src will never refer to a valid image resource but, presumably, something/someone can change the URL later or otherwise manipulate the element. Since the src attribute is required1, substituting in such a valid "dummy" value appeases tools like the Visual Studio editor.
This fiddle shows the behavior which can be observed by using the DOM src property.
1 "The src attribute must be present, and must contain a valid non-empty URL .."
More than likely just a placeholder subject to change dynamically based off of an event listener (or like #FabricioMatte suggested, a lazy loading technique.) It could also be just a placeholder to bypass any potential errors.
In src="#", the attribute value is a reference to the start of the document at the current base URL, according to the URL standard, STD 66 aka RFC 3986. You would need rather special arrangements to make that actually work as a reference to an image.
Why anyone would use such an attribute is a different question, and a yet another question is what is the problem that the construct is supposed to address.

errors on firefox

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.