Really good advice for anyone thinking of releasing a polyfill into the world.
This document provides Best Practices related to the publication and usage of data on the Web designed to help support a self-sustaining ecosystem. Data should be discoverable and understandable by humans and machines.
The security research that went into improving the spec for the Battery Status API. This is why it’s so important that the web holds itself to high standard.
Even most unlikely mechanisms bring unexpected consequences from privacy point of views. That’s why it is necessary to analyze new features, standards, designs, architectures - and products with a privacy angle. This careful process will yield results, decrease the number of issues, abuses and unwelcome surprizes.
A complete list of HTML elements, past and present. They’re all hyperlinked to the relevant specs.
Written in 2001, this history of the web takes in CERN, hypertext, the ARPANET, SGML, and lots more.
I just noticed that I’m mentioned in the acknowledgements of this most handy of W3C documents. This pleases me disproportionately.
Paul Ford’s potted history of web standards, delivered in his own inimitable style.
Reading through the standards, which are dry as can be, you might imagine that standardization is a polite, almost academic process, where wonks calmly debate topics like semicolon placement. This is not the case.
A cute videolette on web standards.
HTML5 is now a W3C recommendation. Here’s what a bunch of people—myself included—have to say about that.
Here’s the chat I had with Jen and Doug about the prospect of DRM in browsers.
This is the worst idea for a W3C community group ever. Come to think of it, it’s the worst idea for an idea ever.
Scott gives us an excellent State Of The Web address, looking at how the web can be central to the coming age of ubiquitous computing. He rightly skips through the imitation of native apps and gets down to the potential of just-in-time interactions.
Dr Harry Halpin writing in the Guardian about the crucial crossroads that we have reached with the very real possibility of DRM mechanisms becoming encoded within HTML:
Most of us are simply happy to launch our browsers and surf the web without a second thought as to how the standards like HTML are created. These standards are in the hands of a fairly small set of standards bodies that have in general acted as responsible stewards for the last few years. The issue of DRM in HTML may be the turning point where all sorts of organisations and users are going to stop taking the open web for granted.
Bruce sits down for a chat with Hixie. This is a good insight into the past and present process behind HTML.
Bruce writes about a worrying trend in standards work:
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.
There’s a W3C community group now for looking at the responsive images question.
Alex weighs in on the newly-reopened debate on vendor prefixes, roundly squashing Henri’s concerns.
Daniel responds to Henri’s call-to-arms on vendor prefixes. While he stridently disagrees with most of what Henri suggests, there is also overlapping agreement: they both want vendor prefixes to ship only in experimental builds, not stable browser releases.
This encapsulates the difference between the WHATWG and the W3C: a concern for interoperability matched against a concern for procedure.