But as I was faffing around drafting, Terence Eden wrote about it, expressing it much better than I did, so I leave him to express my final thought of the year:

I just want us all to get along. I want my disparate equipment to talk to each other. I don’t want to live in a house where ever component has to be made by the same company otherwise nothing works correctly. I don’t want to be stuck using a crappy product because they’re the only ones offering service X.

I don’t want toys that only run on your flavour of batteries.

I don’t want to be part of your fucking ecosystem.

No wonder bad governments want to tame it, censor it, control it or ban it. Don’t let them.

I’m on the Web 10 hours a day, 5 or 6 days a week, and the problems I have with web sites are seldom attributable to a developer failing to minify a stylesheet or neglecting to shave a few vimtoseconds off a JavaScript loop — they’re to do with lack of accessibility, bad information architecture, or usability catastrophes like requiring me to sign up for endless spam before I can give my credit card details to buy the product.

In situations where networks are really slow, or devices under-powered, spending time testing sites across mobile browsers, and focussing on the user’s needs rather than bloating sites with organisational vanity publishing should be your priority.

Vendor prefixes are like skidmarks on the underwear of web standards: sometimes unavoidable, but best washed and rinsed out as soon as possible.

In any industry, standards are vital, and the Web industry is no different.

After the dark days of the browser Wars, in which Microsoft and Netscape competed on adding ever more proprietary whizz-bangs to lock developers in – ahem, more deeply engage developers into their eco-systems, I mean – we’re in an age when all browser and tool vendors compete to tell you how great their standards support is. And this is A Good Thing™.

As Bismarck never said “Laws are like sausages. You should never see them being made” and the same is true of standards. There are many ways to make a standard – some more palatable than others.

Some things are defacto standards – GIF, JPG, webM, h264. Others, like JavaScript (more accurately, ECMAscript) are made by a committee in a smoky room – in the case of ECMAscript, a group with the sinister name of TC39.

Others are retrospectively standardised at the end of their evolution from proprietary whizzbang to defacto standard to real standard. Examples of this are some of Microsoft’s best gifts to the Web: XMLHttpRequest (XHR) which powers almost all Ajax-driven sites, innerHTML and contentEditable.

Another example, this time from Apple, is <canvas> – invented for Apple’s dashboard widgets, liked by everyone and so reverse-engineered and improved by Mozilla, reverse-engineered and implemented by Opera, reverse-engineered and specified by Ian Hickson as part of the HTML5 effort. When Microsoft wanted to implement it, they didn’t have to waste hundreds or thousands of man-hours reverse engineering, with its stupid waste of time and potential to introduce interoperability-damaging bugs: they just picked up the spec and implemented what it said.

But as the editor of HTML5, Ian Hickson, said of <canvas>, “The real solution is to bring these proposals to the table, get some consensus between the relevant vendors and other interested parties, and then use that.”

The best kind of standards process involves as many competitor stakeholders as possible going completely crazy:

• sharing ideas
• trying out ideas in their own labs and sharing results
• discussing openly
• compromising where necessary to achieve concensus
• implementing what has been specified.

This is how the HTML5 effort has worked. Anne van Kesteren described it:

We developed HTML in the open, taking input from anyone, and pretty much from anywhere (mostly tracking blogs back in the day). Until that point HTML was by and large developed by a committee in private meetings.

But the collegiate, co-operative, productive working environment that bloomed so encouragingly seems to be withering.

More and more, we see different companies seeking to solve similar problems secretly, and without discussion. This is why we have many formats for packaged/installable Web applications. Of course, each company promises that it will eventually standardise its solution to the problem, leading to a proliferation of “standards”.

Trying stuff out (perhaps with vendor prefixes) and reporting back is a vital part if standardisation. But presenting whole new features as a fait accompli, and encouraging their use by developers on the open Web loses discussion, the sharing of ideas and results from the process. The end-result loses ease for developers and, ultimately, interoperability for consumers – you know, the great unwashed that we actually make Websites for.

Tossing a specification that you’ve written in-house, in secret and already implemented onto a table at W3C, saying “here, standardise this” as you saunter past isn’t a Get Out of Jail Free card for proprietary misdemeanours. And it isn’t standardisation.

“You can’t”, I replied. He was horrified. I don’t know who was more surprised: him, because of my answer, or me because of his reaction to it.

Every desktop browser has included a view-source option, which is odd when you think about it: you cannot view the source of a PDF or a Word document.

The Web has thrived on people viewing source, copying and pasting, then tweaking until they get the page they want. Any number of free scripts (of varying quality) can be found to make Tinkerbell fairies follow your mouse pointer. Freely available shivs and polyfills abound. Great people (like many of those who write for Pastry Box) spend hours of their own time blogging tips and tricks that in other communities might remain jealously guarded competitive advantages.

So the next time you hit upon a clever technique, blog about it. Or if you write some code that could be useful to someone else, put it on Github. Put something back into the community.

It’s good for us to remember that, too, as we finesse our design or finesse our APIs: all the design, all the tech is merely a vehicle for communication. That’s what we’re building.

In April 2009, the marketing manager noticed that there was a lot of traffic to the site from Singapore, Malaysia, India and South Korea. By June, they had more visitors from India than any other Asian nation. In January 2010, Ignighter made the decision to re-launch itself as an Indian dating site. It gains the same number of Indian users a week as it gained in America in its first year. (Read more about Ignighter.)

If Ignighter had only been coded with single-vendor prefixes and browser-sniffed to work only on iPhones, it probably wouldn’t have been able to grow like this, as that’s a highly aspirational product in India where it costs many times a professional’s monthly salary. But it was a website, capable of being looked at on the feature phones that are so widespread in Asia.

Obviously, there’s no guarantee that you’ll have similar success if your website works across browsers and across devices. But if your website doesn’t, it’s pretty much guaranteed that you won’t be able to develop a market in the fast-growing economies of India and China, where 40% of the world lives.

And once you’ve done that, serve it to everyone, whatever the device.