In the Preface, we covered the general structure of an HTML5 document, but before jumping into development, we must first talk about addressing the time consuming issue of compatibility across browsers and platforms. In this chapter, we will cover how web browsers work and the strategies to support HTML5 across multiple web browsers and devices. By the end of this chapter, you will be able to follow an initial plan of action to consistently support your enterprise application's functionality, interface, and user experience.
We will cover the following topics:
The real meaning of compatibility
Browsers
OS platforms
Display resolution
Importance of compatibility
Patching the differences – compatibility libraries
In an ideal world, HTML, CSS, and JavaScript should be interpreted in the same way across all browsers and platforms. While the World Wide Web Consortium (W3C) has developed standards for such technologies, browser makers have implemented them in their own ways. This means that although you can use W3C standards for developing enterprise applications, it is possible for inconsistencies to arise between different browsers and platforms.
Compatibility does not mean that the experience of the user should be the same in every client, but it needs to maintain certain consistencies. For example, if we have a list of users in an application, it is good practice to have different inputs depending on the platform. We can use the scroll bar to navigate the list on any desktop client. For touch devices, gestures might be preferable.
On the other hand, we need to be careful with platform restrictions because sometimes it is not technically possible to support the same functionality in every device or client. A particular instance that illustrates this is the audio and video volume management in iOS devices (until Version 5.1.1). It is not possible to control the volume using JavaScript in Safari for iOS. In such cases, it is preferable to hide the volume control for iOS devices.
To better understand the issues of compatibility, it is important to understand the evolution of the World Wide Web in relation to the capabilities of the client that renders the final product, the operating system or platform, and the screen resolution.
Since the release of the World Wide Web, there has always been competition for dominance in usage share in the browser marketplace. By 2001, Internet Explorer controlled over 90 percent of the browser market after Netscape ceased to be a major contender, but with the release of Version 1.0 of Mozilla Firefox in November 2004 and Google Chrome in September 2008, it began to see a new crop of competition.
As of June 2012 however, Google Chrome has become the most used browser at just 32.76 percent market share. It now shares an ever crowded space with Mozilla Firefox, Internet Explorer, Safari, and Opera including mobile counterparts. In addition, each one of these has its own list of versions, and we need to decide in some cases from which version we require support for our applications after knowing that newer versions are always around the corner.
Let's peek behind the scenes a bit to understand the complexity behind the diversity of browsers and versions. Each browser has two major software components: a rendering engine and a JavaScript engine.
Also known as the layout engine or web browser engine, the rendering engine is responsible for parsing the markup content (HTML) and the style information (CSS, XSL, and so on), and generating a visual presentation of the formatted content including media files referenced (images, audio, video, fonts, and so on). It is important to know the many rendering engines out there because it can help you to recognize certain behaviors and deduce which browsers are going to behave in certain ways based on their rendering engine.
While Chrome and Safari use WebKit (developed by Apple, KDE, Nokia, Google, and others), Firefox uses Gecko (developed by Netscape/Mozilla Foundation), Internet Explorer uses Trident (owned by Microsoft), and Opera uses Presto.
With CSS, one can identify some exclusive rendering engine features (known as CSS extensions) by the prefix. WebKit-only features start with -webkit- and Gecko-only features with -moz-. Opera includes the -o- prefix while Internet Explorer 8 and up recognize -ms-.
Trident has a different approach. It recognizes common CSS properties with * or – as a prefix to override previous definitions (for example, *color:#ccc; and _color:#ccc; are not recognized by other rendering engines except Trident).
The JavaScript engine is the software component that interprets and executes JavaScript code in the browser. While the rendering engine is responsible for the visual presentation of HTML content using CSS styles, the JavaScript engine will interpret and execute JavaScript code.
Chrome employs the V8 engine, Firefox now uses Jägermonkey, Internet Explorer 9 features Chakra, Safari uses Nitro, while Opera substituted SunSpider with Carakan in 2010.
Note
The rankings for what many consider the current browser war are largely driven by the speed of the JavaScript engine. While other engines rely on interpretation and compilation, V8 has no intermediate parser and it generates an assembler using its own runtime environment. In other words, it has a virtual machine. This has allowed Chrome to become one of the fastest browsers.
As a general rule (there are some exceptions), it is better to load HTML and CSS first and then JavaScript. This can be done by including the <script> tags that import JavaScript just before closing the <body> tag. The reason for this is that it is faster to render HTML and CSS than to interpret and execute JavaScript. Web pages will appear to load faster as a result.
Where it is not possible to include the <script> tags in the body, there are two attributes on the <script> tag that can be used to signal to the browser when the script should be downloaded. These are async, which was introduced in HTML5, and defer. The defer attribute literally does what it purports; it defers script execution until the page has been rendered. This way, the DOM is ready for your script. The async attribute signals to the browser to download the script asynchronously and without blocking the rendering engine and executes it when it is ready. Both execute before the DOMContentLoaded event. The key difference is that defer executes each script sequentially and async executes each script when it is ready. Typically, in order to support older browsers that do not support the async attribute, these attributes are used together so that browsers that do not perform asynchronously can fall back to defer.
While there are many differences between browsers, it is important to be aware that inside the same browser category exists multiple versions whose HTML5 and CSS3 support vary widely. This is especially true for Internet Explorer. Proper support for HTML5 and CSS3 does not appear until Internet Explorer 9.
Note
Microsoft has started a campaign to deprecate and reduce the market share of Internet Explorer 6 worldwide. See http://www.ie6countdown.com for more details. The Aten Design Group took this to another level by commemorating the IE6 funeral at http:///www.ie6funeral.com.
Most of the HTML5 and CSS3 capabilities are supported in the following browsers and versions:
Internet Explorer 9 and higher
Firefox 7 and higher
Chrome 14 and higher
Safari 5 and higher
Safari Mobile 3.2 and higher
Opera 11 and higher
Opera Mobile 5 and higher
Even so, there are still some features not supported and there are inconsistencies between the implementations. One interesting case study that reveals the lack of standards across the browsers is the use of video in HTML5. To use the native video capabilities of HTML5, the video file must be compressed using specific codecs. There are three major codecs that exist: Ogg Theora (royalty-free), H.264 (free for end consumer but involves royalties for products that encode and decode), and WebM (royalty-free). As Firefox is oriented to use open source technologies, it initially supported only Ogg and WebM. Chrome currently supports all three codecs, but, for similar reasons as Firefox support for H.264, will be removed in subsequent versions (although it may continue support on mobile). Safari, Safari Mobile, and Internet Explorer 9 and higher support only H.264 by default, but you can install plugins to support Ogg and WebM (except on Safari Mobile).
Any web application will be affected by the operating system (OS) on which it runs. The most noticeable difference is the appearance of user interface elements of the browser including the scroll bars, submit buttons, checkboxes, and so on. This is an important consideration because the size and shape of these elements can vary across multiple operating systems – even with the same web browser. In fact, some operating systems restrict some functionality, as was the case with <input type="file"> which initially had not been supported on iOS prior to iOS6.
OS platform statistics show that Windows is by far the most used OS on the web. Mobile platforms, however, may take on more prominence in the years ahead considering the growing popularity of tablet devices and technical improvements of smartphones.
With so many devices on the market, screen resolution is quickly becoming an important factor for consideration when planning web applications. Android has a diversity of devices of many sizes and densities. According to the usage of screen resolutions, the advance of new hardware technologies has made it possible to increase the number of pixels on modern screens:
Even though most desktop systems now have a resolution higher than 1024 x 768, the rise of mobile technologies has created a paradox where lower resolution displays are retaking lost ground. The experience delivered by an enterprise application does not need to be—and in fact should not be—the same for all the devices. Viewing a page on a desktop screen at 1920 x 1200 can be vastly different from a mobile phone screen at 960 x 540 not only because of the resolution, but also because of the size of the device and readability (the ease in which text can be read and understood). It is sometimes important to detect the resolution to adapt the user experiences. To be sure, new techniques such as responsive web design are taking hold to address these issues.
Note
As if there were not enough variables in the playfield, Apple introduced Retina Display in June 2010 with the iPhone 4, having a native resolution of 960 x 640. This technology is based on a higher pixel density that is beyond the human eye's capacity to see pixelation in images on the screen at a typical viewing distance. Although it was not so noticeable for web images in the iPhone 4, the new iPad and the new line of MacBook Pros released in 2012 with Retina Display create new requirements for web applications.
First, there are some web development techniques which determine if the client is a mobile device by using CSS to detect the device resolution. With the new iPad, 2048 x 1536 px resolution is not possible or at least not intuitive. The resolution of the new iPad is higher than the majority of desktops and laptops in the market. Secondly, to avoid the pixelated effect in any application viewed on the new iPad or the new MacBook Pro, it is necessary to include higher resolution images for these Apple devices and images in normal resolution for backward compatibility with all other devices.
At this point, it is natural to ask why it is important to care about compatibility if one needs to only develop enterprise applications used internally within an organization, where a specific browser can be mandated. This attitude can be perilous for two reasons. First, businesses are moving quickly towards mobile delivery and controlling the platform is becoming thus less tenable. Secondly, constraining an organization in this way hampers its ability to update its application support capabilities as it couples the enterprise application too tightly to the choices in desktop support. If a company wanted to upgrade to a newer operating system or default web browser, constraining it by requiring that certain versions of browsers be supported can have undesired consequences down the line.
In general, we want to support as many browsers as possible, so we are going to need a way to allow backward compatibility by implementing the capabilities not available on the browser, informing the user that the feature is not available, or modifying the user experience depending on the browser's capabilities. To this end, there are many JavaScript libraries that can help.
Tip
For this chapter, styles and scripts will be included inline within the HTML file to simplify comprehension even though it is a good practice to have styles and scripts in separate files.
As already noted, Internet Explorer begins to support HTML5 tags in Version 9. HTML5 Shiv
allows for support in previous versions. Also known as HTML5 Shim, it is an open source JavaScript library that enables styling for HTML5 elements in versions of Internet Explorer before IE 9. It accomplishes this by using document.createElement("element") to tell the browser that the tags exist.
Suppose that we are testing in Internet Explorer 8, and we have the following code:
<!DOCTYPE HTML>
<html>
<head>
<style>
header{
color:#ff0000;
font-size:40px;
}
</style>
</head>
<body>
<header>Hello HTML5!</header>
</body>
</html>Tip
Downloading the example code
You can download the example code files for all Packt books you have purchased from your account at http://www.PacktPub.com. If you purchased this book elsewhere, you can visit http://www.PacktPub.com/support and register to have the files e-mailed directly to you.
In Internet Explorer 8, the text will not display the style. HTML5 Shiv can be used to make this work.
Tip
It is good practice to dive into libraries before you use them to understand exactly what they are doing. We encourage you to check out the HTML5 Shiv code at the following location: https://github.com/aFarkas/html5shiv/blob/master/src/html5shiv.js.
To install this library you need to perform the following steps:
Download the library from the following location: https://github.com/aFarkas/html5shiv/zipball/master.
Uncompress the file.
Copy
html5shiv.jsfrom thedistfolder to your JavaScript folder (jsin our case).Insert the following code inside the
headtag:<!--[if lt IE 9]> <script src="js/html5shiv.js"></script> <![endif]-->
As a result our code should look as follows:
<!DOCTYPE HTML> <html> <head> <!--[if lt IE 9]> <script src="js/html5shiv.js"></script> <![endif]--> <style> header{ color:#ff0000; font-size:40px; } </style> </head> <body> <header>Hello HTML5!</header> </body> </html>
Tip
Note that the <!--[if lt IE 9]> conditional comment includes the JavaScript library only if the browser version is Internet Explorer prior to Version 9.
If you run this code in Internet Explorer 8, it will show a Hello HTML5! in red with a bigger font. This is one of the exceptions where we need to load a JavaScript library inside <head>, because we need to give the capability to recognize HTML5 elements to the browser before it begins styling.
Since not even the newest versions of web browsers support all HTML5 and CSS3 capabilities, it is useful to do some kind of detection to show a notification or change the behavior of a page when a feature is not supported. An old strategy was to look at the property navigator.userAgent to detect the browser's user agent and code based on the pertinent cases. As user agents change, it becomes difficult to keep pace and alter an application. An alternative approach to user agent detection is feature detection
, wherein an application detects whether a particular feature is supported and reacts accordingly. The following is an example of feature detection:
function supports_video() {
return !!document.createElement('video').canPlayType;
}Modernizr is an open source JavaScript library that allows support for different levels of experiences based on the capabilities of each browser using a simple feature detection model. Additionally, Modernizr uses HTML5 Shiv, adding the ability to style HTML5 elements on Internet Explorer prior to Version 9.
Going back to our previous example:
<!DOCTYPE HTML>
<html>
<head>
<style>
header{
color:#ff0000;
font-size:40px;
}
</style>
</head>
<body>
<header>Hello HTML5!</header>
</body>
</html>Suppose that we want to implement the geolocation functionality using HTML5 to get the geographical position of the user, and we want to detect if it is available. For tha we start using Modernizr:
Select the functionality that you want to validate and html5shiv. In this case, we are going to select the Geolocation API functionality under Misc., html5shiv v3.4 and Add CSS Classes present under Extra.
Copy the source code generated.
Create a new JavaScript file (call it
modernizr.js), paste the source code, and save it in your JavaScript folder.Import the Modernizr library
<script src="js/modernizr.js" type="text/javascript"></script> inside <head>. At this point the code should look as follows:<!DOCTYPE HTML> <html> <head> <script src="js/modernizr.js" type="text/javascript"></script> <style> header{ color:#ff0000; font-size:40px; } </style> </head> <body> <header>Hello HTML5!</header> </body> </html>From here we have two possible solutions; use JavaScript or use CSS to detect the fallback.
In order to show a message or display a different style, we can se CSS with the following steps:
Add a class called
no-jsto the<html>tag. This will work as a default option if JavaScript is not supported. If JavaScript is supported, Modernizr will replaceno-jswith a class calledjs, and will add classes for all features using the prefixno-if it is not supported. For example, if your browser supports geolocation, thehtmltag will look something like the following line of code:<html class="js geolocation">
Otherwise, it will look like the following code:
<html class="js no-geolocation">
In the
<body>tag, add twodivtags containing messages for when geolocation is supported and for when it is not:<div class="geolocation-available"> Congrats! Your browser supports Geolocation! </div> <div class="no-geolocation"> Your browser doesn't support Geolocation :( </div>
Add CSS styles to show and hide the messages. By default, hide both messages and use the class created by the detection class in the
<html>tag to hide or show the classes accordingly:div.geolocation-available, div.no-geolocation{ display: none; } .no-geolocation div.no-geolocation, .geolocation div.geolocation-available { display: block; }Finally, the complete code should look like the following code:
<!DOCTYPE HTML> <html class="no-js"> <head> <script src="js/modernizr.js" type="text/javascript"></script> <style> header{ color:#ff0000; font-size:40px; } div.geolocation-available, div.no-geolocation{ display: none; } .no-geolocation div.no-geolocation, .geolocation div.geolocation-available { display: block; } </style> </head> <body> <header>Hello HTML5!</header> <div class="geolocation-available"> Congrats! Your browser supports Geolocation! </div> <div class="no-geolocation"> Your browser doesn't support Geolocation :( </div> </body> </html>
In case we want to implement a JavaScript fallback, we would need to create a conditional statement using Modernizr. In our case, since Modernizr is a JavaScript object with methods, we can use Modernizr.geolocation to test whether geolocation is supported. The conditional statement should be as follows:
if (Modernizr.geolocation){
alert("Congrats! Your browser supports Geolocation!");
}else{
alert("Your browser doesn't support Geolocation :(");
}The complete code should look as follows:
<!DOCTYPE HTML>
<html>
<head>
<script src="js/modernizr.js" type="text/javascript"></script>
<style>
header{
color:#ff0000;
font-size:40px;
}
</style>
</head>
<body>
<header>Hello HTML5!</header>
<script type="text/javascript">
if (Modernizr.geolocation){
alert("Congrats! Your browser supports Geolocation!");
}
else{
alert("Your browser doesn't support Geolocation :(");
}
</script>
</body>
</html>Modernizr—in spite of its name—does not actually add missing functionalities to browsers save for the HTML5 tags styling support. Where you need to create fallbacks for functionalities in old browsers, Modernizr is a good choice. However, if simple styling with HTML5 and CSS3 is needed, HTML5 Shiv should suffice.
Internet Explorer in versions prior to Version 9 does not support HTML5 Canvas, which allows 2D command-based drawing, but Explorer Canvas enables this feature.
To use Explorer Canvas you can perform the following stes:
Go to http://code.google.com/p/explorercanvas/downloads/list.
Download the last version of Explorer Canvas.
Copy
excanvas.compiled.jsin your JavaScript folder.Import the library in
<head>, verifying the version of Internet Explorer:<!--[if lt IE 9]> <script type="text/javascript" src="js/excanvas.compiled.js"></script> <![endif]-->Now you can use the HTML5 Canvas API in older versions of Internet Explorer.
As it is a JavaScript library, meaning that it needs to be interpreted and executed at page load, its performance will be considerably lower than modern browsers. It also does not support several features and is quite buggy.
A very simple and straightforward way of setting up a project including incorporation of Modernizr and basic configuration is to use a starter kit such as HTML5 Boilerplate. HTML5 Boilerplate is a collection of HTML, CSS, and JavaScript files including Modernizr, jQuery, and CSS Reset2 (a set of CSS rules that override default and inconsistent renderings in different browsers in a way that creates a common baseline). Even when compatibility is the furthest topic of interest, this template can be used as an out-of-the-box way of initializing the CSS and putting the necessary JavaScript libraries in place to make compatibility a non-issue.
You can download HTML5 Boilerplate from http://html5boilerplate.com/ by selecting one of the following options:
Boilerplate: The file collection not minimized and commented
Boilerplate Stripped: The file collection minimized and not commented
Customize Boilerplate: You can configure which files will go in your base project
While the last case may be enough, sometimes it is necessary to include more customizations. Fortunately, there is a tool called Initializr, which removes unneeded files from our HMTL5 Boilerplate project. Additionally, you can use the templates provided by Initializr to modify the visual presentation according to the window size / screen resolution.
To download Initializr, go to http://www.initializr.com/ and select:
Classic H5BP: This is the basic project
Responsive: This is the responsive project based on screen resolution
Bootstrap: This is the responsive project using Twitter's Bootstrap template (http://twitter.github.com/bootstrap/) using Less (http://verekia.com/less-css/), a dynamic stylesheet language that generates CSS on compilation using a JavaScript compiler
After this you can choose or modify the files included.
As we build the MovieNow app in the following chapters, we are going to start from scratch, so we can see the process step by step. But remember that you could use templates to build your enterprise applications. The only caveat is that you always need to know what is inside the project; sometimes an unknown JavaScript or CSS file may cause serious performance issues.
While all this can sound like a nightmare, you only need to follow a simple strategy to embark on the magical quest for compatibility:
Follow the W3C standards for HTML, CSS, and JavaScript (http://www.w3schools.com).
Choose JavaScript libraries or CSS to give backward compatibility for old browsers. In general, a compatibility solution that does not include JavaScript is better than the one that does, but sometimes it is not possible with only CSS.
Define a course of action for allowing accessibility for any user agent. There are a couple of strategies of note: graceful degradation or progressive enhancement. Graceful degradation implies that you begin developing for modern browsers, and then you add handlers for less capable devices. Progressive enhancement, on the other hand, implies starting with basic capabilities and building to the lowest common denominator for browser features, and then adding enhancements for more capable browsers.
It is a good practice to support different user experiences (UX) for mobile devices for a series of reasons: the keyboard can be cumbersome in mobile devices such as mobile phones and even more so on on touchscreen devices; viewing the same layout on smaller resolutions can force users to constantly zoom in and out or make it difficult to click some buttons or links, and sometimes it is not technically possible to have certain functionalities. For example, autoplay for video or volume control using JavaScript in iOS Devices (iPhone, iPad, and so on) is not possible.
Make a test plan for multiple browsers. There are services that allow you to test your enterprise application across multiple browsers and platforms. Of course, the services that employ snapshots may be sub-optimal since they do not test JavaScript execution. It is always good to have all of the browsers that your system will support installed on a test machine, and there are tools that allow you to change the browser version on the fly.
Use the official documentation for web browsers as well as the community forums to keep abreast of what browser makers are doing.
In this chapter, we learned about the differences between the web browsers and the inconsistent ways in which they behave. We talked about the importance of compatibility and strategies you can use to level the playing field. In general, web developers must try to cover most of the cases to ensure compatibility, but at the same time it is important to understand the project and the target audience, and adapt our solutions to them first and then to the global scene.
As a final thought, we need to put ourselves in the user's shoes. The last thing a user wants to see is a message asking to download another browser to use an application. Remember that our goal as developers is not only to bring a collection of requirements to life, but also to create engaging user experiences that define the application as a medium that facilitates an end, rather than an obstacle that separates the user from a final goal.
Before you start building a house, you need to understand what tools you need and how to use them. In the next chapter, we will look at setting up your machine and the available tools that we can use to build our HTML5 enterprise application, including a comprehensive evaluation of the business decisions involved in selecting these tools.