It’s a protocol-relative URL (typically HTTP or HTTPS). So if I’m on http://example.org and I link (or include an image, script, etc.) to //example.com/1.png, it goes to http://example.com/1.png. If I’m on https://example.org, it goes to https://example.com/1.png. This lets you easily avoid mixed content security errors.
//example.com/img.png is a perfectly valid URI syntax as per RFC 3986: Section 4.2. It is relative to the current scheme, and therefore as you mentioned, it can be very useful when switching between HTTP and HTTPS, because you won’t need to explicitly specify the scheme. All modern browsers will understand that format, including IE 6. … Read more
is this URL format safe to use for all browsers. I can’t say anything for sure, but you should be able to test it in different browsers. And is it a standard? Technically, it is called “network-path reference” according to RFC 3986. Here is the scheme for it: relative-ref = relative-part [ “?” query ] … Read more
The resource you’re looking for is the RFC 3986. See Section 4.2 and Section 5.4. Quoting from the latter: Reference Resolution Examples Within a representation with a well defined base URI of: http://a/b/c/d;p?q a relative reference is transformed to its target URI as follows: “g:h” = “g:h” “g” = “http://a/b/c/g” “./g” = “http://a/b/c/g” “g/” = … Read more
I tested it thoroughly before publishing. Of all the browsers available to test against on Browsershots, I could only find one that did not handle the protocol relative URL correctly: an obscure *nix browser called Dillo. There are two drawbacks I’ve received feedback about: Protocol-less URLs may not work as expected when you “open” a … Read more
A relative URL without a scheme (http: or https:) is valid, per RFC 3986: “Uniform Resource Identifier (URI): Generic Syntax”, Section 4.2. If a client chokes on it, then it’s the client’s fault because they’re not complying with the URI syntax specified in the RFC. Your example is valid and should work. I’ve used that … Read more