Browser Compatibility in Html5

Written by admin


Building web applications that provide a good user experience regard- less of what browser the user is using to visit the site therefore becomes a critical aspect of web development. This situation is aggravated by the fact that not only do web developers have to worry about different brands of browsers (IE, Firefox, Chrome and Safari) they also have to deal with different versions of the same browser. While this might sound like a sad state of affairs, fortunately there are a few techniques that we can employ to deal with this issue.

polyfills and shims

A common refrain that one encounters with web developers is the idea that HTML5 is mostly just hype because of the ground reality that browser usage

is extremely fragmented. The only practical thing, it appears, is to target the lowest common denominator. This is not so. Two concepts that are worth discussing in this context are “poly lls” and “shims”!

A “poly ll” is basically just a fancy name for a library of some kind that provides the functionality of a particular HTML5 speci cation for a browser that does not natively provide that support. For example, older versions of Internet Explorer – up until version 8 – do not support the use of the HTML5 “canvas” tag. If being able to use that functionality in a page is critical to the app then it might make sense to use a poly ll library that provides the same functionality through some other means – perhaps via Silverlight or Flash plugins. The user experience will certainly not be the same as what it would be had the feature been natively supported but the users aren’t completely out of luck either.

“Shims” are similar to poly lls in that they are libraries as well, except for the fact that they do not conform to any HTML5 speci cation. A good poly ll library would provide complete delity with the HTML5 spec in question (say, the Canvas API in the example cited before) where as a “shim” usually provides a workaround or provides a library that is at a higher level of abstraction. The “Amplify.js” library for instance solves the problem of client side storage using the best available option on a given browser. On browsers supporting the HTML5 DOM Storage or Indexed DB specs the library would leverage that and use alternatives on other browsers. A “shim” usually provides its own API for the functionality it provides and does not conform to any HTML5 spec even though it might leverage them when available.

Feature detection vs. browser detection

It is a commonly used technique in web development these days to enable/ disable functionality depending on the speci c brand and/or version of browser a given user is running. This is usually achieved by inspecting the “user agent” string that browsers provide to identify themselves. In JavaScript for instance, it is common to nd code such as the following:

• if(navigator.userAgent.indexOf(“MSIE”)==-1){ • window.addEventListener(“load”, onLoad);
• }else{
• window.attachEvent(“onload”, onLoad);

This is not a good idea because here you are making assumptions about what features are supported in a browser. In this particular case it turns out that from IE9 onwards the “addEventListener” method is in fact sup- ported in the DOM. If you choose to do browser detection as we have done in the snippet above then it basically means that the onus of tracking what features are supported in what browser and in what version is upon you! A far better alternative is to use feature detection. The same functionality given above can be achieved using feature detection like so:

• if(window.addEventListener){
• window.addEventListener(“load”, onLoad); • }elseif(window.attachEvent){
• window.attachEvent(“onload”, onLoad); •}

In this case it really does not matter what browser or version the user is using, if “addEventListener” is available then it will be used. One library that really helps implement feature detection in an ef cient manner is Modernizr which simpli es the process of testing for availability of various features. Testing whether canvas is supported for instance looks like this: • if(Modernizr.canvas){

• // yep, canvas supported! •}

internet explorer 9 compatibility modes

Internet Explorer 9 displays webpages that contain the HTML5 document type in IE9 Standards mode, which provides the highest support available for established and emerging industry standards, including the HTML5 (Working Draft), W3C Cascading Style Sheets Level 3 Speci cation (Working Draft), Scalable Vector Graphics (SVG) 1.0 Speci cation, and others.

In some cases, existing websites may not display correctly when dis- played in IE9 mode. This can happen for any number of reasons, including (but not limited to) the following:

  •  The design of a site may rely on the behavior of a specific version of abrowser and that behavior has changed in later versions of the browser,such as conditional comments, version vectors, and user-agent detection.
  •  The design of a site may rely on non-standard behavior.
  •  The design of a site may rely on functionality that is no longer supportedin the latest versions of various standards or browsers.The design of a site may rely on functionality that was incorrectly implemented in an earlier version of a given browser.

To help ensure that your sites are available while you redesign them, Internet Explorer 9 supports document compatibility, which refers to a set of features that allow you to direct Internet Explorer 9 to display your pages as if they were viewed by older versions of the browser.

Document compatibility controls the features that are supported by web pages and the way web pages are displayed in the browser. An extension of the compatibility mode introduced in Microsoft Internet Explorer 6, document compatibility enables you to choose the specific rendering mode that Internet Explorer uses to display your web pages.

Specifying Document Compatibility modes

You can use document modes to control the way Internet Explorer interprets and displays your web page. To specify a specific document mode for your web page, use the meta element to include an “X-UA-Compatible” header in yourweb pagee, as shown in the following example.

In this example, the X-UA-Compatible header directs Internet Explorer to mimic the behaviour of Internet Explorer 7 when determining how to display the webpage. This means that Internet Explorer will use the <!doc- type> directive (or lack thereof) to choose the appropriate document type. Because this page does not contain a <!doctype> directive, the example would be displayed in IE5 (Quirks) mode.

The content attribute speci es the mode for the page; to mimic the behavior of Internet Explorer 7, specify IE=EmulateIE7. Specify IE=5, IE=7, IE=8, or IE=9 to select one of those compatibility modes. You can also specify IE=edge to tell Internet Explorer to use the highest mode available.


About the author


Leave a Comment