Clay Shirky wrote Napster, Udacity, and the Academy the other day. It is well worth reading in its entirety, but let me selectively quote a part that struck me:

Once you see this pattern—a new story rearranging people’s sense of the possible, with the incumbents the last to know—you see it everywhere. First, the people running the old system don’t notice the change. When they do, they assume it’s minor. Then that it’s a niche. Then a fad. And by the time they understand that the world has actually changed, they’ve squandered most of the time they had to adapt.

It succinctly captures what I am involved with and see happening in the web standards world. Now for the second time in fact. First we had the decision in 2004 at a W3C Workshop around Web Applications (now referred to as “The Workshop”) to no longer work on HTML and JavaScript, but instead focus on XML. To counter that decision the WHATWG was formed and proved the W3C wrong. The W3C now heralds HTML5 as one of its success stories.

Now the WHATWG is our new story and it has ably demonstrated that the bureaucracy of the standards process can be circumvented. More became possible, if you will. The second time came when the W3C reaffirmed its stance on a restrictive license for specifications. Specifications belong to anyone. They prove themselves by being in wide use. That combined with the fact that the W3C Process requires editors to do a lot of make work, of which complaints during my seven years there went unaddressed, made me feel my time would be better spent elsewhere.

Having written about my departure from the W3C last month, it seems only fitting to write about my return now. I was elected to its Technical Architecture Group, as part of a reform campaign driven by Alex Russell. Alex has great ideas on improving modern day web development and I share his passion for figuring out how the web is layered and how we can expose those layers for the world to do something wonderful with them.

In the beginning I had some misgivings about Alex, in particular the Web IDL bashing^[1]. I understand now that his concerns are with developers coming from a C/C++ background designing horrific JavaScript APIs. And that DOM for someone from TC39 (designers of JavaScript) means Web-IDL-designed API, rather than DOM.

I was also pessimistic about this TAG adventure, and since five reform candidates were running for four slots I was hoping I would not make the cut. But now I look forward to it. Taking a more high-level perspective with a different set of people than I usually hang out with will be a great learning experience. And ideally that leads to better standards writing down the road.

[1]To me Web IDL was the first real attempt to make it easier to define JavaScript-friendly APIs with some enforced consistency with respect to argument handling. Its predecessor, aptly named OMG IDL, was terrible in that respect.

As the sad news broke that my former employer will stop developing its own browser rendering engine, John Lilly wrote the following:

What we do know is that in technology, we’ve never been served well by monocultures — we know this for sure. I worry that in our desire for clearer definition, easier standards, faster progress, we’re forgetting that we know this.

Time to get back to prevent that from happening.

TV manufacturers are digging their own grave. I just moved to London and am trying to acquire a TV. In the stores I noticed they are promoting features once again, rather than ease of use. TVs come with processors these days. Some better than others as the sales guy made clear. A better processor gives you better streaming 3D on your connected TV. Most have a browser and offer a YouTube “app”. I used YouTube once via a remote control — it was a hilarious demonstration of a user interface disaster.

The complexity increase stands in stark contrast with added end-user value. Pretty much exactly as we were used to with music players, phones, and computers. Drawing the parallels is easy. What users care about is battery life, usability, aesthetics… Not the amount of CPUs a device carries. All I want is a display to which I can stream content, that looks somewhat nice, and is somewhat big. I do not care about connectedness, 3D, 3D glasses, processors, and the myriad of other options.

It seems to me that in their haste to make money out of large monitors they forget that this opens a door. Someone will offer a way cheaper largish display that is integrated with AirPlay (or equivalent) and lets me control it from whatever device I happen to be holding at the moment. No remote control, no features, just “display this”.

Within the standards world every now and then modularization comes up. “Standards should be modular!” One could imagine Jeff Jaffe (W3C’s CEO) going on stage at one of W3C’s conferences and yelling “modularity! modularity! modularity!” and one would not be too far from the truth. The standards created however are often not modular, but rather bolt-on solutions on top of the existing stack (often bolt-on solutions themselves). So rather than modules that evolve over time, we have an ever increasing set of standards that patch each other, often in non-obvious ways.

One way this is evident is that the software that uses these standards often uses a different architecture. In software CSP is not a single module, but rather would be part of e.g. HTTP (header processing), fetching (protocol for retrieving bits out of URL used by HTML’s img element and every other piece of content that can be used to initiate a request), and some mediation part that enforces the policy. In part it makes sense to design new features separately initially. This helps implementors to grasp the work that needs be done and developers how they can make use of this new feature. But long-term it harms the understanding of the platform. Say we introduce a new feature that performs a fetching operation. What will its effect be on CSP? What will its effect be on other specifications bolted on top of fetching? You do not just need to use the fetching protocol in the right way, you also need to patch CSP and potentially other places. In other words, the modularity has left the building.

The standards process needs to become more flexible so the documents that describe the web platform can evolve over time and change shape to meet new demands and constraints. The WHATWG has been pioneering this model for close to a decade now and given the superior class of documents that have been developed it seems about time to take note.