Monday, December 9, 2013

The web-browser is a primal connection between any online service and a prospective user or client. With changing standards and old browser versions as common as they come, the need to evaluate ‘browser vs. new feature’ compatibility is now more important than ever.

Here-in I will give an introduction to the excellent Modernizr API. I am breaking this in easy to read parts, so stay tuned!

Introduction - HTML 5 & CSS 3 features

We know the importance of standards in the World Wide Web, one of which is the HTML markup standard. The HTML standard prevails as the ubiquitous structuring and presentation language for the World Wide Web.

HTML5 or the fifth iteration of HTML enables the provision of ‘beyond mark-up’ features, which until recently were available only by use of third party plugins. A good example of this is animation and video for web pages.

Web animation has long been a forte of Adobe’s Flash, which provides a rich end user experience. But the fact is that it is capable of burdening the bandwidth and occasionally causes memory issues for most modern browsers (this is especially prevalent in tabbed browser sessions having several flash widgets).

On the other hand, HTML5 now offers better inbuilt multimedia tag support, integration with geo-localization, drag-and-drop API support and so on. It allows in-built support and usage for video and audio. This enables handling web based multimedia as well as graphical content, without depending on traditional plugins and external APIs (albeit with some help from JavaScript and/or CSS3).

As far as the video is concerned, the HTML5’s canvas element makes it very easy to integrate and manipulate video related elements.

CSS3 on the other hand, is about evolution in design. It offers better in-built support for text decoration and rendering and tries not to rely on JavaScript as before for implementing the same.

An important factor which spearheaded or necessitated the integration of external features in the current HTML and CSS standards are the multiple and evolving information access techniques, namely mobile devices.

With diversified ecosystems and non-uniformity in standards, it is nothing short of a ‘developer’s hell’ to develop a ‘code-once run-anywhere’ solution.

For example, it is common knowledge that Adobe’s flash has support issues and known incompatibility on some Apple as well as Android devices.

Hence, we needed standards like HTML5 with CSS3 for designing cross-platform solutions.

Why do we need feature compatibility checks?

One aim is common across all of the modern day Web-browsers – to render the Web pages optimally and according to the latest specifications. But sadly, this attitude wasn’t there in the past.

Browser providers have had the habit of implementing exquisite, unique and popularly demanded features in their own unique manner, which eventually led to a broken standard ecosystem.

Although this seemed to suffice as far as the end-user is concerned, the developers got the short end of the stick! Actual development became difficult since these custom feature implementations had to be taken care of at the coding level.

In the current scenario, the latest versions of nearly all browsers agree to the scope and viability offered by the feature-rich HTML5 standard. But HTML5 itself is still evolving.

The major HTML5 APIs (2D drawing, offline web applications, video and audio, DOM Levels, CSS3 and so on) are still not out of their core development cycle and are continuously changing.

If we talk of individual browsers, Firefox, Chrome and Opera are early standard adopters, which is a two edged sword in itself, since issues pertaining to security etc. could still be waiting to be discovered.

Talking of Microsoft’s Internet Explorer, it is nearly always at the end of the adopter line and is slow to support the common HTML5 features prevalent today.

On one hand while we as developers wonder how our application will run on “pre-HTML5” browsers, on the other we are never quite sure of what hardware and software combination our product or service would eventually be accessed on (a fact given shape due to many nonstandard mobile platforms)!

But the thing is that there is no fully HTML5 compatible browser.

HTML5 in itself is not a product or end feature; rather, it is a collection of individual feature evolutions.

Hence, our aim is to detect support for newer features (like canvas, video, or geolocation), and thus here-in comes the need of feature compatibility checks.

What checks exactly are required for ensuring compatibility or available features?

Each and every web-page in a browser is rendered according to its DOM (Document Object Model). In short, the DOM presents all the available HTML elements on that page to the browser.

So basically, if we need to check for compatible features, we need to check the DOM elements themselves.

The actual checks should include the following basic parameters or criteria –

1. Checking for a core property at a global level (e.g. a browser’s geolocation capability)

2. Checking for a property at an element level (e.g. a video element)

3. Check if an accessible method or function is available for the element & check the method calls for both getters and setters (e.g. if a video element is available, check for a specific video format support, or set the format for the current video element)

4. Check if the properties set by the above setters are retained.

In the up-coming parts, we will visit the compatibility check options, their implementation and how modernizer steps in as the leader of the pack. So stick around!