query parametar in image url - html

Is there a reason not to do this to force reload image in browser:
<img src="http://some.domain.com/the_image.jpg?v=3" />
The ?v=3 part, will it break somewhere?

This is perfectly valid and often used together with aggressive client side caching. You could for instance use this URL together and let clients cache the image for a year (as suggested by some RFC as maximum) and change the value as soon as the_image.jpg changes.
Note however, that it's recommended to change the path rather than the query string instead (say /3/the_image.jpg, or the_image-3.jpg). This is mainly due to some faulty implementations (e.g. proxies).

Related

What is the difference between these URL syntax?

I was sent a hyperlink to a Tableau Public link by a client. When I tried opening it, I got a 404 exception. I wrote back to the client but was told by the same that the link was working fine. I visited his profile page and was able to open the presentation there, but the URL that ended up working was slightly different than the one behind the original, non-functioning link.
Here's the anonymized URL behind the original link
https://public.tableau.com/profile/[client_name]%23!/vizhome/Project-AirportDelay/FlightPerformancesinUSA?publish=yes
And here's the URL via the profile page:
https://public.tableau.com/profile/[client_name]#!/vizhome/Project-AirportDelay/FlightPerformancesinUSA
The only differences I see are ?publish=yes and %23!. I tried appending the former, ?publish=yes, to the working URL, and it was still functional. So I suspect that it has to do with the other difference %23! vs. #!. Could the first work because he is opening it from his computer where he is likely logged onto Tableau Public? What's the difference between these syntax? Any ideas about why the original hyperlink might not be functional?
For obvious privacy reasons, I can't provide the whole URL.
It looks like the basic URL pattern for passing filters ?publish=yes
and
%23 is the URL encoded representation of #
The first # after the authority component starts the fragment component. If the # should be part of the path component or the query component, it has to be percent-encoded as %23.
As # is a reserved character, these URIs aren’t equivalent:
http://example.com/foo#bar
http://example.com/foo%23bar
There are countless ways how a URI reference could become erroneous. The culprit is often a software, like a word processor, where someone pastes the correct URI, and the software incorrectly percent-encodes it (maybe assuming that the user didn’t paste the real/correct URI).
Copy-pasting the URI from the browser address bar into a plain text document should always work correctly.

How do I auto-fill in this textbox at the US govt website via the URL?

I'm trying to embed a value into the textbox at the USCIS government website to check my application status number. Suppose it's LIN1234. After inspecting the element of the webpage I see that the HTML wrapper for the textbox is:
<input id="receipt_number" name="appReceiptNum" class="form-control textbox initial-focus" maxlength="13" type="text">
I tried opening up this URL with a suffix added on, but to no avail:
https://egov.uscis.gov/casestatus/landing.do?receipt_num=LIN1234
Is there a way to to this?
Before that, you must understand what means adding ?receipt_num=LIN1234 to the url.
When sending a request (By default and in this context) from your browser, it'll be a GET request (see here) where you send as a get argument your receipt number, setting its key to receipt_num.
What is done to this data on the server side, however, is up to itself.
Just understand that unless the server is made to auto-fill the field with that value in case it receives it, it won't do anything except sending some more data.
I think you want to load this page in your browser with auto-filled field.
In that case you should look into extensions for your browser that would do that automatically.
You probably won't be able to embed a value into the textbox... Just because you are sending values by GET (which is what the landing.do?receipt_num=LIN1234 syntax is doing) doesn't mean that they have something set up to process it, so the GET variable will probably not do anything.
You might be able to see how their URLs work ordinarily, what the page URL that you are aiming to land on looks like, and either decode something from that or set a bookmark there. That said, if they are submitting that data via POST (which they probably are, for security reasons), that probably won't work.
I would suggest looking at reputable form-filling plugins for your web browser, if that's an option. That might allow you to work around that.

How to test the case that HTML <object> (or a similar feature) is unsupported?

I'm writing a web page that has a HTML <object> in it, like
<object [...]>Your browser does not support this.</object>
On all my machines I only have up-to-date browsers installed and don't want to clutter my machines with old browsers (this is actually not easily possible in most cases without depending on third-party-software and/or doing hours of configuration tweaking).
I know of pages like https://www.browserstack.com/ that let you render websites, but this is rather time consuming when I frequently need to check loads of small changes. And honestly I actually don't want to give my data to external companies just for a simple rendering.
How can I easily check how my page would look on old browsers?
Just found it out. The content between the <object></object> tags is not only triggered in unsupporting browsers, but also when the data attribute holds an invalid target (like an unavailable file).
So, to test how it looks on unsupporting browsers, one can simply set the data-attribute to something unavailable. But keep in mind that the webdesigner then also has to define a more meaningful message than just "Your browser does not support SVG", but also has to consider that the object to display is simply missing (for example in a dynamic setting of the data attribute via PHP, like data=<?php echo getFile(); ?> when the function returns something undefined).

HTML cache version

You know how if you use
<script type="text/javascript" src="urlhere.js?version=1.0.0"></script>
the browser caches the javascript file and updates it when you give it a new version?
Is there a way to do that with the HTML code?
Because I want the browser to cache the HTML, but then update when the code is changed.
Is that possible?
The best way to handle caching would be at the server level, specifying two tags:
Expires
When the date specified has past, it tells the browser the content is no longer valid and it must be refreshed.
Cache-Control
Without involving the date, it lets the browser know how it should handling caching for the page.
Note: The browser should already take care of this as it (in the background) already looks at the last modified date of the file. However, the above methods are valid ways of overriding (extending) this kind of detection in places where the last modified date may not necessarily reflect change.

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

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