When Written: April 2011
Why can’t we just have a single rendering engine I keep asking? The WebKit rendering engine that is used by the Safari browser and a number of other programs including Dreamweaver for its Live View mode is a move in the right direction, but I doubt we will see any attempts at conformity whilst the big boys behave like kids in a playground with their ‘my dad is better that your dad’ attitude. Microsoft showing off the hardware rendering acceleration of IE10 versus Chrome is all well and good but if you want to develop a web application for everyone to use you cannot rely on their browser to have such performance. Great if it has, and your application should of course degrade gracefully when viewed on lesser devices but that will still mean that your application cannot rely on such capability and so it becomes of limited use to the web developer.
There is, however, some help for the poor web designer who is being hassled by their client to use all the latest CSS3 and HTML5 ‘tricks’ but still maintain compatibility with older browsers that do not support these. The help comes in the form of a library called ‘Modernizr’ (http://www.modernizr.com/ ). This library uses feature detection within a browser to detect if it supports a particular feature rather than the usual and very flawed approach of detecting the browser and its version. This feature detection it is claimed is done in ‘a few milliseconds’ so it should not slow your web site down. So now you can go ahead and use such things as graduated fills, rounded corners or shadow effects in CSS3 without worrying what will happen if the browser does not support these. The syntax that you use is very simple. For example, let us assume that you want to put a shadow around a box area on a web page. You define a div area called say ‘somediv’ and then in your Style Sheet you would put:
/* If Browser does not support boxshadows in CSS3 then simulated box shadow using borders: */
.no-boxshadow div.somediv {
border-bottom: 1px solid #666;
border-right: 1px solid #777;
}
/* If browser supports boxshadows in CSS3 */
.boxshadow div.somediv {
border: none;
box-shadow: #666 1px 1px 1px;
-moz-box-shadow: #666 1px 1px 1px;
-webkit-box-shadow: #666 1px 1px 1px;
}
The key part of this code is the Modernizr syntax of ‘.boxshadow’ and ‘.no-boxshadow’. Modernizr could help solve a lot of compatibility problems until such time as HTML5 and CSS3 have settled down as a standard and the current browsers are all supporting it. But even after that time, the feature testing system that Modernizr uses should ensure that any incompatibilities that linger will be trapped and dealt with by your site. Using such libraries as this one and JQuery takes a lot of the ‘grunt work’ out of building great web sites that work in all browsers.
Web development always has and I suspect always will, be a case of compromise and taking the middle path when it comes to using the capabilities of the viewing browser, so show us something we can use today Microsoft and stop trying to score points off competitors because of the ultimately unusable performance enhancements. I would rather have something that rendered the same as the other browsers and that loaded quickly than something that will display multiple video streams faster than a competitor’s browser when the bit of ancient aluminium wire that is apparently part of BT’s 21st century network around here and in many areas, has problems streaming even a single non HD video. Even the large posters that Microsoft are putting up about Internet Explorer just emphasise its speed. Sure it may run JavaScript faster than other browsers which is a benefit but in my experience it still takes a lot longer to load up the first page than Chrome so I shan’t be switching my default browser just yet.
There is much talk about the ‘video’ and ‘audio’ tags in HTML5 and how these will see the demise of the current video delivery systems like Flash and Silverlight. Whilst I feel that in the future this may be true it is some way off still as there are two main drawbacks with the current HTML5 specification. The first is that there is no rights management currently built into HTML5., Now while we would all like all our movies to be free, back in the real world the owners of such content need to make money out of it and they are going to be very reluctant to embrace a technology that has no form of protection. The other limitation to video in HTML5 is its lack of streaming capability, and while it is true that companies like Apple have got round this with their HTTP Live streaming protocol this is currently a proprietary protocol and not standards based so is not currently supported by the other players. Of course these issues should eventually get sorted by the Standards Committees but these move very slowly, not helped I would guess by the big software companies who also sit on them and have their own strategy issues. So before you go off and create your ‘killer’ HTML5 web site for that client, just ask them what their position is on the copyright protection of the video content on their site.
Article by: Mark Newton
Published in: Mark Newton