When Bruce Lawson tweeted about an opportunity to meet the TAG, I managed, at the last minute, to get a ticket and joined a room full of very smart people discussing some technical aspects of the web medium.
Although Bruce and Jeremy have already written a much better summary of this fascinating evening, I will share my thoughts nonetheless.
The TAG?
‘TAG’ is an abbreviation of ‘Technical Architecture Group’. They are a special working group within the W3C, overseeing which web standards are developed and thinking about the general direction of the web.
The meeting
The meeting took place in the form of a Q&A session at the Google Campus in London, followed by beers. The atmophere was good, the TAG members interesting and the audience interested.
Archeology
When I entered the room, sorry I was late, there was a discussion about which design principles the TAG has. The web and its possibilities have extended tremendously over the past years, and the main concern of the TAG is making sure that the capabilities of the web ‘platform’ are well documented. Many things a web browser needs to do are not formally described by a spec, but nonetheless, they need doing. Those who put web standards together have to do some sort of ‘archeology’ into what browsers do to find consensus.
DRM
Then, someone asked a question about a drm. An extension of HTML, agreed upon by the W3C, provides APIs ‘to control playback of protected content’. It has been called unethical and bad for the web. In response to the question, the TAG pointed out that they are merely responsible for technical architecture, not for policy. However, individual TAG members did respond. Anne van Kesteren said he personally thinks DRM does not work and is bad for the web. Tim Berners-Lee, after explaining DRM is already in a lot of things that almost all of us use, pointed out the DRM issue is not simple and goes much beyond just technical problems. Many little procedures that make the web work and resulted in its popularity have a social aspect as well as a technical aspect. Someone in the audience noted that the technical DRM discussion ought to be preceded by another, about how, as a society, we want to value content creators. Because surely, we all want to read great books and watch interesting films, and no one would deny the makers of these things to do it for free. I agreed, this discussion has implications beyond tech.
Web Components
In the HTML5 spec, a number of new elements were introduced. Commonly used classnames, like header, footer and section had gotten there own element. When those new HTML5 elements were introduced, they appeared to have been carefully chosen, to make sure the standard remained simple yet effective. With Web Components, it will be possible for developers to use any element they like. Then, asked Jeremy Keith, with some irony, ‘what do we need standards bodies for?’ Now of course it is still good to standardise commonly used elements. Web Components are not meant to create your own <div>-like elements, although you can. They are meant to create the kind of elements that have extra features, like <input type="range">. For standard elements, the browser has APIs to ‘do’ those features. If you make them with a web component, you provide the API yourself, with JavaScript. Then, if some web components become very common, the W3C may decide standardise them, so that they can be used declaratively. In the future, commonly used Components and their JS APIs could be standardised and become part of browsers, just like commonly used classnames were standardised as elements. Now the web is being used more and more as a platform, some developers serve empty <body> elements with a lot of JS. With Web Components, they can serve <body> elements containing meaningful custom elements.
URLs
As the very last question, Andrew Betts brought up an issue that he had with the web product he works on. He felt it was not always possible to represent what was on the page with its URL. One concern he mentioned is that context is not always taken into account. In his organisation, some teams wanted to have different content in different contexts, and there is nothing in URLs that can help specify which context is currently used. The assumption of different web contexts have been argued to be wrong , but Andrew’s case was interesting and lead to the TAG’s final conclusion: ‘we all love URLs!’
Comments, likes & shares
No webmentions about this post yet! (Or I've broken my implementation)