Mainly some notes for myself:
* utilizes HTTP Pipelining (Sends multiple requests on the same connection) to avoid round trip delays on servers that support them
* GPU accelerated rendering (for CSS transitions and such)
* “async” attribute for scripts now supported
* Loading of CSS scripts are now blocking
* HTML5 Web workers support
* CSS position: fixed
* CSS overflow: scroll (-webkit-overflow-scrolling: touch;)
* Still no browser based file upload (input type=”file”)
* new input types: date, datetime, month, time, range
* new EcmaScript 5 stuff
iOS5 seams to have broken functionality in our HTML5 mobile webapp. Requesting audio media assets are currently failing 1 out of 2 times with one of two errors:
The operation couldn’t be completed. (NSURLErrorDomain error – 1013.)
The operation could not be completed
After much research I’ve come to the conclusion that our authenticated media host is having issues with the updated HTTP Request behavior in iOS5′s version of mobile Safari. iOS5 now uses its own flavor of HTTP Pipelining to speed up data transfer and my theory is somewhere along the line our host’s web server is disagreeing with it.
Since mobile networks usually have very high latency HTTP Pipelining allows the HTTP client to avoid round trips to the server by send multiple requests on the same connection without waiting for the server to respond. You can read up on iOS5′s version of HTTP Pipelining and the concept in general here:
http://www.blaze.io/mobile/ios5-top10-performance-changes/
http://www.blaze.io/mobile/http-pipelining-big-in-mobile/
We’ll be reaching out to our media content provider today to validate but I figured I would throw up a place for others experiencing the same issue to discuss as I am not seeing other posts about it yet.
Building javascript heavy webapps using html5 and css3 is tough when you have old but still stubbornly popular Internet Explorer browsers to support. The solution: Chrome Frame
In Google’s words:
Google Chrome Frame is an open source plug-in that seamlessly brings Google Chrome’s open web technologies and speedy JavaScript engine to Internet Explorer.
In my words: Hello IE 6 render my shit automagically using Chrome.
Once installed, this meta tag in your html will tell IE to use Chrome’s engine to render the document:
<meta http-equiv="X-UA-Compatible" content="chrome=1"> Don’t have Chrome Frame installed yet? These few lines of condition IE logic will check and prompt:
<!--[if IE]>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/chrome-frame/1/CFInstall.min.js"></script>
<style>
.chromeFrameInstallDefaultStyle {
width: 800px;
border: 5px solid blue;
z-index: 99999;
}
</style>
<script>
// The conditional ensures that this code will only execute in IE,
// Therefore we can use the IE-specific attachEvent without worry
window.attachEvent("onload", function() {
CFInstall.check({
mode: "inline", // the default
oninstall: function(){
alert("Chrome Frame is now installed. You may need to restart your browser.");
}
});
});
</script>
<![endif]-->
Chrome Frame is installed at the user level if the user does not have admin access (Win!). The documentation states a restart isn’t even necessary once installed but I’ve found in my tests that the browser does need to be fully restarted so I’ve included a post-install alert specifying so in my code.
Forcing a user to install a plug-in to see content is usually a no-no but when it comes to all-or-nothing HTML5 CSS3 webapps that need to span all browsers an devices with a single codebase sometimes those IE6 users can use a little prodding. To clarify, Chrome the web browser does not have to be installed beforehand and installing the plug-in does not install the Chrome browser. Chrome Frame’s name is a bit of a misnomer as the structure of your document is not modified and no DOM frame is used–everything is just rendered beautifully even in IE6 using Chrome’s versions of the WebKit layout engine and V8 JavaScript engine via the IE plugin.