ESP – Product Engineering – Platform and Software Products

If the web platform has attained this maturity with HTML4, what triggered the need for a new HTML5 specification? Let's try answering this question by exploring HTML5.

Specification development in participatory fashion

At the specification level, there is a difference between how HTML4 was developed versus how HTML5 is being developed, as the developers (WHATWG & W3C) claim to have "learnt a lot" from previous experience with HTML4 adoption. Post HTML4 release, it was noticed that apart from supporting the standard HTML4 functionality, web-browser vendors had introduced few features of their own. Examples are marquee (by Microsoft), multicol (by Netscape), sound (by Mosaic), animate (by IBM WebExplorer) and blink (by Netscape). Vendors provided such features on top of the HTML4 specification because they perceived business value in those features, which were of course intentionally not incorporated in the HTML4 specification. So, once non conforming features were made available in a browser, solution developers built their solutions around them. Problems arise when browser vendors decide to stop supporting those features, as these are anyway not part of the HTML4 specifications. Learning from experience, this time apart from coming up with the standard set of specifications, the HTML5 specification developers are also paying keen attention to the web-browser vendor's needs. Vendors are being consulted in the specification creation process at every possible stage. With this kind of collaboration, the expectation is to develop an even more widely acceptable, vendor neutral but still market oriented specification set.

Adding powerful graphic APIs and reducing 3^rd party dependency

User interface design is very important as it majorly influences the user's acceptance of a product. Over the years, web-application developers have been writing tricky and complex scripts and using 3^rd party controls to develop attractive GUI. Today, rich internet applications are almost always based on Flash, Silverlight or similar technologies. Developers tend to rely on these technologies for rich graphics, media and cross-platform compatibility. The flip side of using such technologies is that WebApp users are expected to install the plug-ins associated with these technologies on their machines. Unfortunately, not all operating systems have these plug-in available for them. That's why W3C probably decided to address this issue in the new specifications. Accordingly HTML5 compatible browsers are expected to inherently support the popularly desired graphic, audio and video capabilities.

To provide desktop-like custom graphics rendering capabilities, HTML5 introduced <SVG>, a persistent state graphic API. The following code snippet demonstrates how simple it is to draw a custom graphic inside an HTML5 browser by embedding a SVG tag in HTML. To render such graphics using HTML4, a web-developer would have typically used images.

           .                         

Figure 1  SVG embedded in HTML                                                                   Figure 2  SVG rendered in browser

Similarly, a new <video> tag has also been introduced in HTML5. This tag has the potential to partially replace the object tag but unfortunately, HTML5 does not associate default codec with this tag. The initial recommendation was to have Ogg as the default codec but later, due to possible (and perhaps un-foreseen) patenting issue, this format was dropped. Currently, the open source community is demanding that VP8 be the default format because Google, after acquiring On2 (the original developers of this codec), has announced that this codec will be made available to the open source community.

The idea behind introducing new APIs is to improve the browser capability to inherently support the 3 important interactive capabilities (sound, image and video), so that compatibility of the new generation (i.e. HTML5) WebApp is ensured on all operating systems.

Apart from the graphic APIs, HTML5 has also introduced new controls. The "Date" control is one of them. With Date input-type, every (HTML5) compliant browser would have capability to display the date control. Although, the actual look and feel could differ across vendors, the basic functionality of being able to choose the month, year, date and day would be provided by the browser itself. No 3^rd party control would be required for the same.

Similar to Date, Range (i.e. slider) is another newly introduced control. HTML5 captures the functional details of these newly introduced controls in great details, for example, to avoid page layout issues across different browsers HTML5 states even the minutest details like the default size of these controls.

The following code snippet shows how the newly introduced controls look like

          .             

Figure 3  Opera - Date and Slide control           Figure 4  Safari - Date (currently not supported) & Slide control

Figure 5  Slider and Calendar HTML5 code

Easy client-side data validation

WebApp developers have been writing rehashed script code for client-side input validation which often involves empty username, address and URL detection. The new specification has simplified this validation task. To perform empty input validation, developers can now associate the "required" attribute so that the web-browser would perform the validation and highlight input field to the user with a visual indication against the empty mandatory field.

One of the very often sought after user input is the e-mail id. HTML5 has proposed an edit control which performs email address validations. This again saves the effort in developing and using commonly written scripts to validate e-mail address

With HTML5, developers can associate the newly introduced "autofocus" attribute with HTML form controls to indicate which form element should have the focus when the page loads.

Figure 6  Opera's response to empty date which is marked as a "required" field, Ref: fig 5

A step towards the Semantic Web

Even today experts differ over whether the current state of World Wide Web is 2.0 OR 1.0 but the progression towards the Semantic web is undisputed. By introducing <aside>, <article>, <header> and <footer> tags, HTML5 has enabled semantic web crawlers/agents to decipher information that otherwise would need human intervention.

Figure 7  Typical HTML4 page layout                                                    Figure 8  HTML5 page layout

Figures shown above highlight the difference between a typical HTML4 webpage and the HTML5 webpage. A typical HTML4 page heavily uses the div tag to achieve the required page layout. The problem with this approach is that because information (text or image) is always placed inside one or the other div tag, web crawlers/semantic agents fail to differentiate between the main article (that the web-page has to present) and the supplementary details like references, navigation info, header and footer data etc. To fully understand the web-page created using the div tag, the crawler/agent needs human intervention, whereas, a well-formed HTML5 page can be easily and correctly understood on its own.

Unification of DOM structure

The in-memory presentation of the HTML is commonly known as "DOM HTML" OR simply "DOM". Although web-browsers are not obliged to support DOM, since script engines require DOM, browsers are forced to host DOM. One of the short comings of the earlier HTML4 version is that it partly described DOM. Hence, different vendors have (slightly) different DOM tree structures causing script incompatibility issues and increased development/testing effort.  The HTML5 specification decided to fully describe DOM to avoid any vendor specific incompatibility. One can argue that this is too much of detail to be captured at the specification level but it is required to ensure identical DOM structure across all browsers.

 Backward compatibility

After the finalization of the HTML4 specification in 1998 it has hardly been updated. In fact there were attempts to develop XML based alternative for HTML - known as XHTML. The subsequently developed XForms technology was also projected as the next generation 'Form' technology. But gradually it was realized that reach of these XML based web technologies was limited only to RSS and Atom. Hence, browser vendors (Apple, Mozilla and Opera) decided to start developing HTML5 with the intent to be backwardly compatible with HTML4. This was essential as browser vendors had invested considerably in the development and maintenance of browser code targeting HTML4. Based on the past learnings it was also realized that the new specifications should be detailed enough to cover interoperability amongst the various vendors.

Concluding remarks

Above points highlight HTML4 limitations and how HTML5 offers improvised solutions over the same. HTML5 can ease the development effort and help ensuring cross platform compatibility. This is also the reason why web-developers are very excited about it and are eagerly awaiting release of compatible browsers. The browser vendors have already started supporting HTML5 features although the official release of the HTML5 specification is scheduled in next couple of years. The caniuse.com survey states, Firefox 4.0, Safari 5.0 and Chrome 6.0 support 85%+ HTML5 features whereas Opera 10.6 is 75% and IE 8.0 is 26% HTML5 compliant. The new specification is all set to give the required boost to the open standards. Let's hope HTML5 soon becomes the vocabulary for web development.