Is it good to implement website elements like css, javascripts, images or web links without the protocol?
For example: jquery.com offer the cdn-file without:
//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js
Pro for using is, that they automatically use the current protocol (http or https). Even the links are shorter (okay, just 4/5 signs). Are there any cons or should I use it on my own website?
Is there any definition about how browsers deal with this kind of links (official standard)?
href without protocol (Protocol-relative URL) is used to remove the naggy warning of accessing unsecure content in IE.
But it'll cause double download in IE7 and IE8 (alas, WHY U NO SMART!!!).
The standard RFC3986 is mentioned in Paul Irish's article. But standard can only serve as a reference in web development, the browser vendors' implementations is more important. Websites like Can I Use, WebPlatform documents this info.
Do refer to these links:
http://www.paulirish.com/2010/the-protocol-relative-url/
http://blog.httpwatch.com/2010/02/10/using-protocol-relative-urls-to-switch-between-http-and-https/
http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/
Related
We have a universal React application sitting behind a CDN.
We want to serve up HTML with srcset images from the server, but need to handle the fact that IE will not support this HTML feature, ideally using feature detection.
As the site is served from a CDN, IE will get the same initial HTML as other browsers. When the page loads in the browser, we want to swap out these srcset image tags for some different HTML, but this means React will complain about a mismatch between the client side HTML and the already rendered server side HTML.
What's the best way to handle this?
e.g.
ignore the warning, or specify it's ok somewhere?
use a client side polyfill that happens after the page has loaded e.g. using componentDidMount? In this case, how do we handle subsequent renders of an unchanged component not rewrite this HTML on the client?
use a cache key on the CDN for the user agent - but this would mean sniffing browser rather than using feature detection
The best and most compliant way is to leave both attributes. My guess is that browser will use "src" as a fallback but use "srcset" if available.
No polyfills or strange manipulations needed here :)
I opened up Firefox this morning and was presented with the "New Tab" page. One of the tiles that appeared on this page was Mozilla's MDN site.
Unlike all the other tiles (which were merely screenshots of the web site), the MDN tile has a custom tile which advertised the MDN.
Looking at the HTML source for MDN I couldn't see any META or LINK tags that would suggest how they are achieving this?
I've Googled around but can't see any documentation about how I would go about customizing tiles for my own web sites so they display as pretty as MDN on this page..?
I was wondering if there was a standard mark-up for this so it would also work with Google Chrome's equivalent start page?
Looking on the Mozilla help page for Firefox users, you can see that tiles in their screenshots are not merely screenshots, but where can I see the web designer documentation for this..?
This is not under the control of the site.
See this bugzilla ticket:
Can a website specify their own enhanced tiles via some meta tag?
Right now no. There's been discussions around that, but there's
initially some worse privacy aspects where Firefox would need to
connect to a site to get that information potentially triggering
cookies similar to bug 1037673.
How enhanced tiles are implemented is the content comes from
cookieless https requests to mozilla servers, so there's lower privacy
risks of some types of tracking.
Another ticket has been opened requesting the feature.
You would need to make a deal with Mozilla to get special treatment for your site on their servers.
We are doing some experiments in the lab and we have rewrite a TCP implementation. Now our problem is if there's some methods that can make HTML5 use our TCP stack to transmit videos.
Thanks.
Update:
Sorry about the description. I didn't know much about web technology, maybe my question shuold replace HTML5 by Browser.
Everything that is described in HTML is executed by the browser. HTML is not a programming language, it's markup. Therefore HTML has no influence on the internals of a browser.
Either you manage to get your browser to use a different TCP stack (which is unlikely unless you're working with Firefox or Chrome (or some other open source browser) and compile it from source), or you have to write your own browser.
:::UPDATED:::
i am reading about HTML-5 and what are the new features it offers, and one of these features are the App Cache which is define in W3school website as "Offline browsing - users can use the application when they're offline",,.
But is this really a new feature in HTML-5 that was not avilable in earlier HTML versions?? since from long time (at least 6 years back) we have the option of browsing a web site even if we are offline since the HTML will be cached inside the browser ?? so what is meant by offline browsing in HTML-5??
BR
Yes, this is new functionality introduced with HTML5. This is not the same as your browser caching the site, such as the ole "save for offline use" option.
Some browsers offline caching mechanisms are simply just unreliable. HTML5 instead uses a manifest file to tell the browser what it should use for offline storage.
See:
http://www.html5rocks.com/en/tutorials/appcache/beginner/
And the w3c working draft:
http://www.w3.org/TR/html5/offline.html
My favourite HTML5 resource (more regarding correct usage of older elements, and how to use the new ones): http://html5doctor.com/
Lastly, as many experienced web developers will tell you, w3schools is trouble. They're infamous for having all kinds of misleading and false information. See http://w3fools.com/
Hope this helps.
Is anyone aware of whether it is problematic to use protocol relative URLs for an image source to prevent mixed content security warnings.
For example linking an image like:
<img src="//domain.com/img.jpg" />
instead of:
<img src="http://domain.com/img.jpg" />
or
<img src="https//domain.com/img.jpg" />
In my testing i've not seen anything to suggest this is wrong but i'm not sure if it has edge cases where it will create problems.
EDIT i've seen it throw errors when using PHP's getimagesize function.
Found an interesting gotcha for the use of protocol relative URLs:
You have to be careful to only use
this syntax in pages destined for
browsers. If you put it in an email,
there will be no base page URL to use
in resolving the relative URL. In
Outlook at least, this URL will be
interpreted as a Windows network file,
not what you intended.
from here
Essentially though there are no valid reasons why this shouldn't work as long as the request is made by a browser and not an external email client.
more info from here:
A relative URL without a scheme (http:
or https:) is valid, per RTF 3986:
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 relative URL method
myself on heavily trafficked sites and
have had zero complaints. Also, we
test our sites in Firefox, Safari,
IE6, IE7 and Opera. These browsers all
understand that URL format
IE 7 and IE 8 will download stylesheets twice if you're using a protocol-relative URL. That won't affect you if you only use it "for an image source", but just in case.
The following should be considered when using Protocol-Relative URLs:
1) All modern browsers support this feature.
2) We have to be sure that the requested resource is accessible over both HTTP and HTTPS. If HTTP redirects to HTTPS it is fine, but here the load time will take a little longer than if the request was made directly to the HTTPS.
3) Internet Explorer 6 does not support this feature.
4) Internet Explorer 7 and 8 support the feature, but they will download a stylesheet twice if protocol-relative URLs are used for the css files.