HAVING just taken up a new assignment in California in the early 1990s, following a five-year hiatus covering the financial roller-coaster of Japan, your correspondent was embarrassed to be asked each time he interviewed sources in Silicon Valley what was his employer’s web address—ie, its Universal Resource Locator or URL.
For the first few months, he mumbled something about the core competency of newspapers and magazines being their well-honed ability to spread the word around the world overnight via print, not bits and bytes. When he could take the cajoling no longer, he got permission (though no money) from the higher-ups in London to create The Economist’s first web presence in his spare time.
Not counting those evenings and weekends, the total cost of building The Economist’s first website came to $120—mostly spent on getting graphics scanned at Kinko’s. Hosting the site, on EarthLink, cost $20 a month. To your correspondent’s amazement, AOL subsequently ranked his botch-up as one of the top ten news sites in the world, ahead of Time Warner’s “Pathfinder” website, which reputedly cost $140m to build.
What your correspondent learned from hand-coding the fledgling website was that it had better start loading within three or four seconds and have finished in less than 20 seconds—otherwise visitors would not hang around. With the majority of users relying in those days on dial-up modems, each web page could therefore offer no more than 50 kilobytes or so of content.
That meant paring the HTML code used for laying out web pages to the bone. To speed things up further, all the style-sheet data and Java scripts had to be collated into separate files for caching judiciously around the internet. And web graphics comprising bulky GIF files had to be kept to an absolute minimum—and replaced with slicker PNG and JPEG formats as soon as they became available.
With today’s broadband connections to the internet, websites can offer a far richer experience—including music, graphics, video and animation—and still comply with the “eight-second rule” that requires content to be loaded swiftly before impatient visitors wander away. But to do so, the browsers people use nowadays have to be packed with plug-ins, protocols and codecs (compression-decompression algorithms) to decode all the wizardry on today’s web pages.
Video presents the biggest challenge. Because the World Wide Web Consortium (W3C)—the governing body that oversees, amongst other things, the HTML standard—opted long ago not to back any particular video format, each browser developer (eg, Microsoft, Mozilla, Apple, Google, Opera and others) has been free to choose whichever it thought best.
The choice has finally come down to two formats: one, called H.264, is used in Apple’s Safari and Microsoft’s latest Internet Explorer, while the other, known as Ogg Theora, has been adopted by the Firefox and Opera browsers. Google’s Chrome has embraced both. Experts agree that the H.264 algorithm (used in Blu-ray Disc players) produces a better picture, but is a proprietary technology, while Ogg Theora is open source.
With so many different browsers around these days, a web page that can be read perfectly using, say, Internet Explorer may stutter or stall when viewed in Firefox or Safari. As a result, people who buy a new computer or mobile device may have to install a different browser, media player or codec just to carry on enjoying their favourite websites.
The bravest attempt yet to unify all websites and browsers is Flash, a software framework produced by Adobe Systems. Most of the animation, video, adverts, games and interactive features found in web pages today comes courtesy of Flash. However, to display such content, a user must first download a suitable (free) copy of Adobe Flash Player for the operating system, language and version of the browser used. For the player to work properly, the device it is running on needs to be reasonably powerful and have plenty of spare RAM.
Such quibbles aside, Flash has helped web developers build sites that offer a rich and rewarding experience for the vast majority of users. The notable exceptions are people who use iPhones or iPads to access the web. The late Steve Jobs called Flash “a rat’s nest of buggy software that hogs processor cycles, drains battery life and causes needless crashes”—and refused to let it near his beloved iOS, the operating system that powers both the iPhone and the iPad. He even banned programmers from using Flash development tools to create iPhone apps (see “Flash in the pan”, April 16th 2010).
But Jobs was being more than a little disingenuous. Apple never had any quarrel over letting Flash work on its Macintosh computers. So, Jobs’s objection was not really about buggy software causing needless crashes—though, heaven knows, Flash certainly causes its share. Of far greater concern was the likely loss of revenue. Had iPhone or iPad users been allowed to install a Flash player on their devices, they would have promptly stopped buying games and other animated software from Apple’s App Store—and got their Flash equivalents for free from elsewhere on the web.
That said, Flash remains a plug-in that adds excess baggage to both the browser and the web page. It is also a proprietary product which, though free to use, may not always be so. And Jobs was right in saying it robs the device of computing power and drains its battery. To get the most out of their tiny batteries, mobile devices really need to decode their video in hardware rather than in software, which burns up twice the amount of juice. Unfortunately, the majority of websites that rely on Flash still use older video decoders that cannot work with today’s mobile chips. With mobile devices becoming the dominant way of accessing the web, Flash’s shortcomings have begun to loom ever larger.
So have HTML’s. The framework used to support web pages has been tweaked, patched and enhanced continuously since Tim Berners-Lee invented the web (and HTML to display it) in 1991 (see “Happy anniversary?”, August 12th 2011). No surprise that it has begun to creak and buckle under the weight of Flash and all the other kludges needed to make it work in a modern multimedia world, where streaming video on the fly (rather than simply downloading it as a file for viewing later) has become the norm. The current version of HTML (4.01) cannot handle any of this on its own. The time has come for a massive overhaul.
That is where HTML 5 comes in. This is not just a new version of the venerable mark-up language, but over a dozen web standards rolled into one. Above all, HTML 5 treats video as a priority task, allowing it to be streamed natively—ie, without the need for browser plug-ins such as players, codecs and other stray bits of software. As such, it is destined, eventually, to replace Flash and other make-shift solutions. Even Adobe recognises this, and has begun incorporating HTML 5 into its various graphics tools.
Apart from its native video and audio tags that make handling multimedia so much slicker, HTML 5 is expected to solve a huge problem that has bedeviled publishers seeking to create online versions of their publications with the same look and feel as their print editions. Publishers believe this is crucial for maintaining brand recognition and reader loyalty as they migrate their businesses precariously from print to web.
The problem is that today’s web standards require specialised readers like Kindle and Zinio to display facsimiles of actual printed pages on a computer screen. To do so on a smart-phone is even trickier. The New York Times and a handful of others have had to develop hand-coded applications to reproduce their publications on iPhones, iPads and Android devices. Few publishers can afford to hire large teams of programmers to do that.
But with its native tags for marking up various parts of a document—including header, footer, body, section, figure and caption—HTML 5 can provide publishers with a template that will allow their content to be displayed exactly as it should be, on every compliant browser, on every conceivable device, on every possible occasion. For many in old media, that day cannot come soon enough.
Much the same can be said for web games. A new tag in HTML 5 known as canvas allows applications to draw directly on a web page like Flash. Even better, the tag can call up built-in 3D routines that reside in a device’s graphics chip. That should let web designers generate games that are every bit as immersive as their console brethren. If HTML 5 can do that for web games, imagine what it can do for web-based business applications such as schedulers, databases, spreadsheets and even word-processors. HTML 5 even allows such applications to be taken offline and stored in the user’s computer or mobile device. For the first time, web applications will therefore gain access (given the appropriate permission) to files stored on a user’s device. In the process, the computer and the web will become one.
Pie in the sky? It all depends on whether the engineers who volunteer their time to the HTML 5 project can pull it off. As of today, all the popular browsers—on smart-phones as well as computers—support at least some of HTML 5’s features. In May, the W3C leadership announced its “last call” for the 400 or so individuals involved in hammering out HTML 5’s specifications to make any last-minute changes. The aim is to release the final version by 2014. If, by then, web-enabled devices support just half of what HTML 5 has to offer, the online world will be a far richer place.
Powered by Facebook Comments