One way HTML5 solves this problem is by aligning itself more closely with related markup languages. Content authors can embed markup written in MathML (for rendering equations) and SVG (for rendering scalable vector graphics) directly into their HTML5 markup. This increased flexibility makes cross-platform HTML more competitive with file formats such as Flash and Silverlight, which were designed with both text and graphics in mind.
But Web developers are clamoring loudest for HTML5's new audio and video tags, which aim to finally make it easy to embed multimedia content into Web pages. These tags are defined in the HTML5 standard as being codec-neutral, meaning it's up to individual browser vendors to support the codecs needed to play any given content item. Still, the video tag in particular is expected to be a godsend, particularly for online video providers who want their content to be available on Apple's iPhone and forthcoming iPad, neither of which supports Flash.
Taking interactive Web graphics one step further is the
In addition to these onscreen technologies, HTML5 also introduces the concept of browser-based application caches, which allow Web applications to store information on the client device. Like the Google Gears plug-in, these caches can both speed up application performance and allow users to continue to use Web applications even when they do not have access to the Internet -- in fact, Google is already planning to phase out support for Gears in favor of the HTML5 technology.
Browser plug-ins: Not dead yet
But for all of HTML5's new features, users shouldn't expect plug-ins to disappear overnight. The Web has a long history of many competing technologies and media formats, and the inertia of that legacy will be difficult to overcome. It may yet be many years before a pure-HTML5 browser will be able to match the capabilities of today's patchwork clients.
For example, while Vimeo and YouTube are already experimenting with the HTML5
video tag, deploying HTML5 multimedia will not be as easy as it sounds. The W3C's decision not to specify media codecs in the HTML5 standard means developers cannot guarantee that any one media format will be playable on every possible client device. Apple, Google, and Microsoft are pushing for H.264 video, for example, but open source browsers such as Firefox and Konqueror are unable (or ideologically unwilling) to license the appropriate patents to support that format. Unless this boondoggle can be resolved, Web content authors who need to reach the widest possible audience may be forced to continue to rely on Flash.
Not every legacy application will be rewritten for HTML5, either. For example, even if Google downplays its own Gears technology in favor of a standards-based approach to local application storage, the Gears API and the HTML5 application cache API are not identical. Google itself admits that "there is not yet a simple, comprehensive way to take your Gears-enabled application and move it (and your entire userbase) over to a standards-based approach." Until there is one, even users of fully HTML-compliant browsers may be forced to install Gears to support some legacy applications.
In the end, browser market share may be the most significant hurdle for developers interested in making the most of HTML5. Internet Explorer 6, for all its rendering quirks and inept handling of Web standards, is seemingly the browser that cannot die. Older versions of Firefox, IE, Opera, Safari, and others all have large user bases, and none support HTML5. Until these legacy browsers are replaced with modern updates, Web developers may be stuck maintaining two versions of their sites: a rich version for HTML5-enabled users, and a version for legacy browsers that falls back on outdated rendering tricks.