The main limitation is that the length of the data protocol has a maximum fixed length, but even worst is that IE8 apparently introduced the data protocol only for images.
In another scenario,where we would like to use the same technique for other purposes, IE is still the only browser that does not respect standards.
This is an example:
function evalazy(src, callback){
var script = document.createElement("script"),
body = document.documentElement;
if(callback)
script.onload = callback;
script.type = "application/javascript";
script.src = "data:" + script.type + "," + encodeURIComponent(src);
body.removeChild(body.appendChild(script));
};
Above function is able to evaluate valid JavaScript code in an asynchronous way, calling a callback, if any, when evaluation has been completed ( kinda load runtime an external script ).
Since functions like atob and btoa are still not standard, the script is evaluated as url encoded string.
But even using a base64 string, the result does not change, IE does nothing, or it could generates an error, the classic could not complete the operation due to error 800a03e8 if the body is not present, and in some case, it could even crash during next script execution.
evalazy("testMe = 123", function(){
alert(testMe);
});
In this case the problem is JavaScript, but since the data protocol has been only partially implemented, we will not be able to include every other kind of resource that is not an image.
Hoping I am wrong, and hoping they'll make data protocol more "efficient", let's play with IE8 and its new features, really, and generally, appreciated. Thanks IE8 team :)