The Encrypted Media Extensions (EME) addition to HTML is effectively DRM with the blessing of the W3C. It’s bad for accessibility, bad for usability, bad for security, and as the Internet Archive rightly points out, it’s bad for digital preservation.
It’s fascinating to look back at this early proposal for CSS from 1994 and see what the syntax might have been:
A one-statement style sheet that sets the font size of the h1 element:
h1.font.size = 24pt 100%
The percentage at the end of the line indicates what degree of influence that is requested (here 100%).
A damning assessment of Tim Berners-Lee’s defeatist portrayal of the W3C:
No matter which side is right, the W3C faces an existential crisis.
- The W3C is a shepherd of the web for all, the web on everything, and a web of trust. But now it is fundamentally compromising its own principles in the name of maintaining industry relevance.
- Or, the W3C is merely an industry body for browser vendors to collaborate and its mission statement is nothing more than PR to increase buy-in from the smaller, largely powerless, members.
Both can’t be true. Neither is good news for the organisation.
Much as I respect Tim Berners-Lee, his logic here is completely flawed. First of all, treating DRM as though it’s an implacable force of nature is a category error. Secondly, EME doesn’t in any provide a standardised solution: it provides a sandbox for each DRM vendor to inject their own proprietary solution.
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.