Syndicated feed for Web Standards

Weblogs: Web Standards

For future growth of the Web into a pervasive medium, adhering to webstandards is a fundamental step.

Web Standards links

Atom Feed for this links blog Link blog feed

Wednesday, August 03, 2011

The Web Development Discipline

A web developer's responsibility is to build a website that best delivers on the expectations of that website's target audience. Every decision about the website must always take that audience into account. You cannot convert a visitor into a customer without offering something of value to that visitor.

The browser support of your website must be directly correlated with your target audience. If it isn't, you are doing it wrong. If you still consider it to be a technical decision, you are doing it wrong. If you think that it is cost-prohibitive to support Internet Explorer 6, your development approach isn't conducive to the Web. You are doing it wrong.

The hostile environment

Douglas Crockford, the JavaScript Colossus, frequently notes that the browser is the most hostile programming environment imaginable (this was before he found out about mobile development!). This should come as no surprise to anyone developing on the Web.

And yet, each piece of the web development puzzle is actually quite simple and can be picked up and learnt in an afternoon. HTML, CSS, JavaScript, jQuery, progressive enhancement, Firebug/Charles, HTTP, Fiddler, Cookies, sessions, caching, redirects, accessibility, internationalisation, semantic markup, form submission, CSS sprites, CSS page layouts, Ajax, CSS & JS minification, analytics, supporting Firefox, Safari, Chrome, Opera, IE6 & 7 rendering issues. Nothing on this list is complicated, almost all of it is seriously documented and covered on the web.

Independently these are simple. The complicated part is handling all of that simultaneously while developing; recognising the overlaps and potential conflicts. Complex features on websites are collaborations of simple pieces.

Supporting Internet Explorer is just one little piece in our complex jigsaw. It needs to be handled with the same care and attention as every other piece. Internet Explorer 6 is special in its own unique way. This should not be news to anyone who builds websites.

Yes, supporting IE6 isn't quick and easy. But it's our job as web developers to support it as long as our engaged audience uses it. (Remy Sharp's pointed reply "What do you mean, you don't like IE6? Really?" is worth reading.)

Spewing bile against IE6 has turned into a seasonal perma-thread. Every few months another embittered developer decries his fate and begs the technical community to do something about it. I'm fascinated by the arguments of why IE6 needs to be euthenised. I realise that, as those arguments are expressed, they reveal a deeper problem: a lack of a disciplined approach to web development.

The secret of failure: Leaving it to the end

The main technical argument about why IE6 support needs to end is the cost of supporting it. The current iteration of this perma-thread is a Computer Science graduate who spent two days trying to fix his already built web site to work in IE6.

He openly admits supporting IE6 was an after-thought. He didn't consider it during the development process. Why not?

When something fundamental is added onto a project after the development is complete, how can we be surprised -- as technical people -- when the amount of effort to incorporate this new requirement turns out to be expensive and painful?

Accessibility. How often do capable technical people put forward the argument that accessibility is cost-prohibitive and would put many businesses into bankruptcy if the existing legal requirements were actually enforced? (Despite a perfect case study of the commercial benefits of being accessible.)

The expense of these requirements are not because these requirements are onerous. They are because these requirements were not considered upfront as requirements and verified during the development process.

Why isn't IE6 support considered up-front at the start of a project? Why isn't a web developer asking the IE6 question at the start of the project? Can a web developer really be oblivious to Internet Explorer 6's existence and special needs?

Leaving any requirement untouched until the end of a project is asking for trouble and pain. The fault isn't in the requirement, but in the developer's approach to web development.

Forgetting IE6 exists is not an excuse for a web developer. Keeping quiet and hoping that a product person doesn't later add it as a requirement is unacceptable.

A line item on an invoice or quote detailing "Internet Explorer 6 support" is subtitling the main delivery as "couldn't build it properly the first time".

The web development process

The approach to dealing with Internet Explorer 6 is obvious. Document the support of it at the start (based on your target audience). Define what that support means. Test and verify that support as you develop incrementally.

Support isn't a binary option. It ranges from pixel-perfect rendering, to slight differences in rendering, to completely working with a simpler style, to providing only the core functionality, through to zero support at all. The right level is that which matches the enagement of your audience using that particular browser.

Typically, your site analytics will identify the browsers used by your visiting audience. This provides a useful starting point to build on. Although, don't get caught out making decisions on those stats if your exisiting site has issues and problems for the browsers you are considering support for. Obviously if a site doesn't work in Firefox, the conversion rate for visitors using that browsers will approach zero and distort the actual engagement of that portion of your audience.

Every new feature you build, every line of code you touch, adds a new set of assumptions. You need to test those assumptions while they are fresh and malleable. You need to correct those assumptions as early as possible.

Your development environment should support the regular testing of your code in multiple browsers. If your development environment doesn't allow regular testing of your code in IE6 & IE7's Trident renderers, a Webkit renderer, a Presto renderer, and a Gecko renderer you do not have a suitable environment to do web development.

As each layer of functionality is added you should be testing in several browsers used by your audience. Doing the bulk of development testing in only one browser is unacceptable, and obviously flawed. You know that IE6 and IE7 aren't at the quality levels of modern browsers, so you have no excuse not to be regularly testing in them.

Engineers and computer scientists understand the benefits of a structured approach to development and the benefits of tested and reusable code. The principles of high-quality software engineering apply just as well to high-quality web development.

Self-harm is a cry for attention

If you leave IE6 testing and fixing to the end of your project, you have no-one else to blame for the pain but yourself. This is part of your job as a web developer, do it properly and to the best of your ability.

Friday, March 04, 2011

Microsoft's anti-IE6 rhetoric

Microsoft's Internet Explorer team has launched a public campaign to upgrade away from IE6. It's a first for Microsoft, dissing their own product, and a move that's welcomed by web developers. Except it's a charade.

This campaign has no weight, or serious backing from Microsoft. They will quite happily take the money organisations like the UK government are paying them to keep IE6 fully patched and working. No amount of grass-roots developer evangelism is going to surmount the real problems of organisations locked in to IE6.

And the upgrade path to IE8 (the last IE to work on Windows XP, and over 2 years old already), is only a short-lived improvement. There is no support for HTML 5 features, or CSS 3 innovations, or XHTML in IE8, so all we are doing is replacing one non-modern browser with another.

IE6 lock-in

In 2010 the UK government received an online petition signed by over 6,000 people requesting that government departments be encouraged to upgrade away from Internet Explorer 6. This was on the basis of increased security, and promoting innovation.

The government declined, correctly claiming that upgrading from IE6 is a complex and expensive exercise:

It is not straightforward for HMG departments to upgrade IE versions on their systems. Upgrading these systems to IE8 can be a very large operation, taking weeks to test and roll out to all users. To test all the web applications currently used by HMG departments can take months at significant potential cost to the taxpayer. It is therefore more cost effective in many cases to continue to use IE6 and rely on other measures, such as firewalls and malware scanning software, to further protect public sector internet users.

Further more, the government describes a strong partnership with Microsoft to ensure the longevity of Internet Explorer 6:

The Government continues to work with Microsoft and other internet browser suppliers to understand the security of the products used by HMG, including Internet Explorer and we welcome the work that Microsoft are continuing do on delivering security solutions which are deployed as quickly as possible to all Internet Explorer users.

So as far as the Government of the United Kingdom is concerned, Internet Explorer 6 is going to be the preferred browser choice for quite a long time, because:

Microsoft's dilemma

No amount of web developer evangelism, or PR from Microsoft's Internet Explorer product team is going to resolve the lock-in of the UK Government to IE6. There is no visible evidence of actual substance to Microsoft's anti-IE6 campaign.

The current lock-in of Internet Explorer 6 in large organisations and governments isn't one that can be solved by throwing up a new website tracking it's usage. It requires Microsoft to sit down with each of these organisations and draw up a roadmap of getting them safely and cost-effectively off Internet Explorer 6 to something more modern and supported. This means figuring out a cost-effective way to fix the web applications that have been written in an IE6-only way.

A shiny gadgety site with a butt-ugly and inaccessible banner markup isn't tackling the real problem.

If Microsoft are serious about tacking the IE6 problem, then they owe it to us to publicly detail a roadmap of how they are getting large organisations, like the UK government, out of the IE6 lock-in they currently face. Otherwise, this is all blowing smoke.

Web developers beware

I caution web developers supporting this public campaign. As my good friend Steve Webster notes: Microsoft's idea of an upgrade is to IE8, which today has no support for HTML5 or CSS 3 and is already two years behind the current crop of modern web browsers. This isn't a great leap forward.

Web developers, you are being asked to voice your support for Internet Explorer 8. Resist this. Demand an upgrade path to a modern web-browser that's on the road to supporting the parts of HTML5 and CSS 3 other modern browsers support today.

Either Microsoft releases IE9 for Windows XP alongside Vista and Windows 7, or we recommend modern browsers like Firefox, Chrome and Opera. Don't compromise on an already out-of-date IE8.

Further resources

Sunday, February 20, 2011

Sacrificing the Open Web with H.264

The openness of the Web is under a direct attack. Apple and Microsoft have found an antidote to competing against free open-source software. Their solution is ingenious - force free software to charge their customers, and then drive them out of business by undercutting on price (funding that loss-leading with revenue generated from the sales of their Operating Systems).

Google defending open source browsers

Open source software has just one ace in it’s deck - Google. Google took a principled stand in deciding to drop support for the H.264 codec, and throw it’s considerable weight behind the not-yet-patent-encumbered WebM format (based on the VP8 codec). They certainly didn’t have to make this move since Google can afford the licensing cost of H.264.

Many people say Google’s decision is a step backwards for HTML5. I regard it as a step back from the brink of disaster of a patent-encumbered web, and a step towards preserving the openness of the Web. The H.264-codec is a victim of software patents. Despite it’s technical merits and wide-spread hardware support, H.264 on the web is a barrier to open-source access to video content on the Web.

Accepting H.264 as the standard video codec (de facto, or otherwise) on the web means making the choice between:

Out of the above choices the least onerous, ironically, is to accept that Flash will be filling in this gap of a lack of open and patent-unencumbered video codec for a while.

The Patent Trolls

Our current predicament on the web is a result of allowing software patents to exist. Before, tiny business entities took major commercial software companies to court and won substantial payouts for their software patents. Recently, in the smartphone industry every company is suing and being sued for software patent breaches.

In the video codec industry, Apple and Microsoft have cleverly positioned themselves with the patent trolls of the MPEG LA. They have protected themselves from being sued while having a free hand (and allies) to target open-source developers.

MPEG LA is a Delaware-incorporated company that holds a number of key software patents for H.264. It is a shell company made up of member companies across the video creation and playback industries. Every major hardware producer of H.264 products is a member of MPEG LA - from DVD & Blu-ray players, high-definition TV, portable video players and other devices that contain hardware support for H.264 encoding or decoding.

The cost of H.264

MPEG LA have recently announced that video on the Web encoded in H.264 will be royalty free if the video itself is free to visitors. The use of the format itself is free, but not the encoding or decoding of it.

Software that encodes or decodes H.264 will need a license (PDF), and the pricing depends on the number of users of that piece of software.

This is an annual cost. Every year, developers need to pay this charge for every user of software that uses a codec that encodes and/or decodes H.264. There is cap on the total amount payable, currently this is $6.5 million (for the period 2011-2015), an increase of $1.5 million from the previous period 2009 to 2010.

This pricing suits Microsoft and Apple as operating system vendors very well. Their browsers are “part of the operating system”, so they pay a standard flat-fee of $6.5 million per operating system and that covers all the users of their operating system. It’s money they can easily afford, and has a negligible effect on ongoing development investments inside the company. (Doesn’t it strike you as odd that there’s a maximum ceiling? This makes H.264 licensing far cheaper for massive commercial software companies like Apple, Adobe and Microsoft because of their scale)

Open Source software expenses

Open source browsers running on the Apple and Microsoft platforms are not so lucky. If they have native support for H.264 decoder they will be liable for this license fee payment. Both Apple and Microsoft have declared that they will develop extensions for these browsers to play H.264 video on their operating system.

That means open-source browsers have to pay licensing fees for the H.264 codec if they want to support H.264 natively in their browser. This creates a serious headaches for open source browser developers:

So popular open-source products face a financial obstacle if they have a small modicum of success. How will they fund this cost? They are left with some difficult choices:

That for open source developers, is the bitter taste of success.

Relying on browser plugins and extensions for H.264 does take away the main benefit of the HTML5 video element - avoiding the use of plugins for video. And that plugin would need to be provided either by the underlying operating system, or by a commercial third-party plugin. In this case, keeping Flash as a fallback is a much less onerous task than complying with the licensing requirements of H.264.

There’s also the case of what happens on Linux platforms (both desktop and mobile devices). Somewhere in the Open Source stack there now needs to be a commercial piece of software that provides the H.264 playback.

(I haven’t found a clear statement yet of whether licensees need to be a member of MPEG LA, or what the costs are of membership. Also I’m surprised that Adobe isn’t a member of MPEG LA.)

H.264 Linux support

It’s not viable for H.264 support to be built in on the Linux “Operating System level”. So it would be up to each Linux distribution to deal with the H.264 licensing. H.264 patents hits a primary weakness of the Linux community: there is no One Linux Community, just thousands of distributions. This rules out a very generous Linux benefactor covering these licensing costs.

Either number of Linux distributions will drop substantially, as those who can afford the H.264 licensing fees will kill off those that don’t; or Linux distros will fragment much faster by enforcing a limited supply of 100,000 downloads or less in an effort to avoid license payments.

Both would be a big blow for the Linux community. So the need for an alternative solution is still very much there.

One alternative approach I can see is forgo H.264 support in open source browsers, and find a patent-unencumbered video codec to support. And at the same time redouble efforts into nullifying software patents.

Another alternative solution is MPEG LA dropping all licensing requirements and fees for open source software decoding of H.264, allowing browsers to support native playback for free. Since everyone is adamant that hardware based encoding is far better anyway, MPEG LA won’t be losing that much revenue since they get their hardware cut already.

The fate of the Open Web

The technical merits of H.264 and it’s widespread adoption of it in hardware are strong arguments in favour of H.264. But not strong enough to surrender the open Web for it.

All over the web commercial operating-system companies Microsoft and Apple are building checkpoints to keep out their open source competitors, and directing people who chose open source browsers on their platform off to a side-road of an inferior playback experience.

Which means that products like Flash will still be required to deal with the incompatibility of video on the Web. Settling on H.264 means giving up on the free World Wide Web and cede control of it to Microsoft, Apple and Adobe.

Let me be clear, it’s not H.264 to blame here, it’s software patents. Apple and Microsoft have a fiduciary duty to their shareholders, and that shows how courageous Google is with their principled stand. The adoption of WebM is an alternative path, if it can safely navigate MPEG LA’s battle call for a patent attack. WebM is our one chance at a patent-unencumbered video codec on the Web. (At least by choosing Flash over the patent-encumbered H.264 is the lesser of two evils, open source developers leave the MPEG LA licensing problem in Adobe’s hands. Thanks Adobe.)

From my pro-Open Web perspective, the MPEG LA membership pool is a cartel to protect Apple and Microsoft from competition from their open source rivals by forcing a commercial software model on them.

The Open Web needs an patent-unencumbered video codec. We may have to wait until H.264’s software patents expire before we get there, but hopefully WebM will mature and remain a patent-unencumbered alternative soon.

Older Posts:

[ Weblog | Categories and feeds | 2011 | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 ]