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.
Either:
- 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.
A new handy little performance testing tool from the W3C along the lines of Page Speed Insights.
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.
Many people are—quite rightly, in my opinion—upset about the prospect of DRM landing in the W3C HTML specification at the behest of media companies like Netflix and the MPAA.
This would mean that a web browser would have to include support for the plugin-like architecture of Encrypted Media Extensions if they want to claim standards compliance.
A common rebuttal to any concerns about this is that any such concerns are hypocritical. After all, we’re quite happy to use other technologies—Apple TV, Silverlight, etc.—that have DRM baked in.
I think that this rebuttal is a crock of shit.
It is precisely because other technologies are locked down that it’s important to keep the web open.
I own an Apple TV. I use it to watch Netflix. So I’m using DRM-encumbered technologies all the time. But I will fight tooth and nail to keep DRM out of web browsers. That’s not hypocrisy. That’s a quarantine measure.
Stuart summarises the current situation nicely:
From what I’ve seen, this is a discussion of pragmatism: given that DRM exists and movies use it and people want movies, is it a good idea to integrate DRM movie playback more tightly with the web?
His conclusion perfectly encapsulates why I watch Netflix on my Apple TV and I don’t want DRM on the web:
The argument has been made that if the web doesn’t embrace this stuff, people won’t stop watching videos: they’ll just go somewhere other than the web to get them, and that is a correct argument. But what is the point in bringing people to the web to watch their videos, if in order to do so the web becomes platform-specific and unopen and balkanised?
As an addendum, I heard a similar “you’re being a hypocrite” argument when I raised security concerns about EME at the last TAG meetup in London:
I tried to steer things away from the ethical questions and back to the technical side of things by voicing my concerns with the security model of EME. Reading the excellent description by Henri, sentences like this should give you the heebie-jeebies:
Neither the browser nor the JavaScript program understand the bytes.
Alex told me that my phone already runs code that I cannot inspect and does things that I have no control over. So hey, what does it matter if my web browser does the same thing, right?
I’m reminded of something that Anne wrote four years ago when a vulnerability was discovered that affected Flash, Java, and web browsers:
We have higher standards for browsers.
I was up in London yesterday to spend the day with the web developers of a Clearleft client, talking front-end architecture and strategies for implementing responsive design. ‘Twas a good day, although London always tires me out quite a bit.
On this occasion, I didn’t head straight back to Brighton. Instead I braved the subterranean challenges of the Tube to make my way across london to Google Campus, where a panel discussion was taking place. This was Meet The TAG.
TAG is the Technical Architecture Group at the W3C. It doesn’t work on any one particular spec. Instead, it’s a sort of meta-group to steer how standards get specified.
Gathered onstage yesterday evening were TAG members Anne van Kesteren, Tim Berners-Lee, Alex Russell, Yehuda Katz, and Daniel Appelquist (Henry Thompson and Sergey Konstantinov were also there, in the audience). Once we had all grabbed a (free!) beer and settled into our seats, Bruce kicked things off with an excellent question: in the intros, multiple TAG members mentioned their work as guiding emerging standards to make sure they matched the principles of the TAG …but what are those principles?
It seemed like a fairly straightforward question, but it prompted the first rabbit hole of the evening as Alex and Yehuda focussed in on the principle of “layering”—stacking technologies in a sensible way that provides the most power to web developers. It’s an important principle for sure, but it didn’t really answer Bruce’s question. I was tempted to raise my hand and reformulate Bruce’s question into three parts:
There’s a charter and that contains a mission statement, but that’s not the same as documenting design principles. There is an extensible web manifesto—that does document design principles—which contains the signatures of many (but not all) TAG members …so does that represent the views of the TAG? I’d like to get some clarification on that.
The extensible web manifesto does a good job of explaining the thinking behind projects like web components. It’s all about approaching the design of new browser APIs in a sensible (and extensible) way.
I mentioned that the TAG were a kind of meta-standards body, and in a way, what the extensible web manifesto—and examples like web components—are proposing is a meta-approach to how browsers implement new features. Instead of browser makers (in collaboration with standards bodies) creating new elements, UI widgets and APIs, developers will create new elements and UI widgets.
When Yehuda was describing this process, he compared it with the current situation. Currently, developers have to petition standards bodies begging them to implement some new kind of widget and eventually, if you’re lucky, browsers might implement it. At this point I interrupted to ask—somewhat tongue-in-cheek—”So if we get web components, what do we need standards bodies for?” Alex had an immediate response for that: standards bodies can look at what developers are creating, find the most common patterns, and implement them as new elements and widgets.
“I see,” I said. “So browsers and standards bodies will have a kind of ‘rough consensus’ based on …running code?”
“Yes!”, said Alex, laughing. “Jeremy Keith, ladies and gentlemen!”
So the idea with web components (and more broadly, the extensible web) is that developers will be able to create new elements with associated JavaScript functionality. Currently developers are creating new widgets using nothing but JavaScript. Ideally, web components will result in more declarative solutions and reduce our current reliance on JavaScript to do everything. I’m all for that.
But one thing slightly puzzled me. The idea of everyone creating whatever new elements they want isn’t a new one. That’s the whole idea behind XML (and by extension, XHTML) and yet the very same people who hated the idea of that kind of extensibility are the ones who are most eager about web components.
Playing devil’s advocate, I asked “How come the same people who hated RDF love web components?” (although what I really meant was RDFa—a means of extending HTML).
I got two answers. The first one was from Alex. Crucially, he said, a web component comes bundled with instructions on how it works. So it’s useful. That’s a big, big difference to the Tower of Babel scenario where everyone could just make up their own names for elements, but browsers have no idea what those names mean so effectively they’re meaningless.
That was the serious answer. The other answer I got was from Tim Berners-Lee. With a twinkle in his eye and an elbow in Alex’s ribs he said, “Well, these youngsters who weren’t around when we doing things with XML all want to do things with JSON now, which is a much cooler format because you can store number types in it. So that’s why they want to do everything in JavaScript.” Cheeky trickster!
Anyway, there was plenty of food for thought in the discussion of web components. This really is a radically new and different way of adding features to browsers. In theory, it shifts the balance of power much more to developers (who currently have to hack together everything using JavaScript). If it works, it will be A Good Thing and result in expanding HTML’s vocabulary with genuinely useful features. I fear there may be a rocky transition to this new way of thinking, and I worry about backwards compatibility, but I can’t help but admire the audacity of the plan.
The evening inevitably included a digression into the black hole of DRM. As always, the discussion got quite heated and I don’t think anybody was going to change their minds. I tried to steer things away from the ethical questions and back to the technical side of things by voicing my concerns with the security model of EME. Reading the excellent description by Henri, sentences like this should give you the heebie-jeebies:
Neither the browser nor the JavaScript program understand the bytes.
But the whole DRM discussion was, fortunately, curtailed by Anne who was ostensibly moderating the panel. Before it was though, Sir Tim made one final point. Because of the heat of the discussion, people were calling for us to separate the societal questions (around intellectual property and payment) from the technical ones (around encryption). But, Sir Tim pointed out, that separation isn’t really possible. Even something as simple as the hyperlink has political assumptions built in about the kind of society that would value being able to link resources together and share them around.
That’s an important point, well worth remembering: all software is political. That’s one of the reasons why I’d really appreciate an explicit documentation of design principles from the Technical Architecture Group.
Still, it was a very valuable event. Bruce has also written down his description of the evening. Many thanks to Dan and the rest of the TAG team for putting it together. I’m very glad I went along. As well as the panel discussion, it was really nice to chat to Paul and have the chance to congratulate Jeni in person on her appearance on her OBE.
Alas, I couldn’t stick around too long—I had to start making the long journey back to Brighton—so I said my goodbyes and exited. I didn’t have the opportunity to speak to Tim Berners-Lee directly, which is probably just as well: I’m sure I would’ve embarrassed myself by being a complete fanboy.
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.