The W3C TAG meeting I attended in Boston went better than expected. I got to meet the rest of the group and we discussed a variety of interesting topics without ever getting too far into lalaland (although the Polyglot Markup discussion was pushing it). I did think it was a bit too formal, though fortunately Jeni and Tim supplied a healthy dose of comic relief.
I thought I would outline some of what we discussed here and quickly jot some thoughts down for further reflection later:
Authoritative Metadata: We know that the most popular user agents out there are not respecting this finding. We know that the HTML Standard is not respecting this finding. We know that developers do have not sufficient control over their server, even now (one of the issues with httprange-14, CORS, CSP, deploying new formats such as WebVTT). While authoritative metadata may be good in principle (and I think that in retrospect for Content-Type file signatures would have worked just as well with a safe fallback), it has not worked out in practice. We should at least indicate in the finding that what it requires is not what is practiced.
Layering: Yehuda and Alex outlined a vision for a more layered web platform. While the network stack has pretty good layering, it gets messier once you get to the bits that go over the wire, such as HTML and JavaScript. I think this one is pretty non-controversial, though it is a lot of work and we need to watch out along the way to not constrain new implementations architectures (insofar they are not already). If you are interested in this space look at where Web Components is heading.
API Design: Both Alex and Yehuda are frustrated with W3C/WHATWG APIs. Part of this is due to IDL not encouraging the kind of APIs that are close to JavaScript, part of this is people from a non-JavaScript background exposing low-level functionality to the platform. I personally feel that we have been hearing this problem aired for a while, but it never goes much further than that. I tried to point out that people would be supportive of doing this better, but we are resource constrained and lack the advice. Yehuda and Alex will take this back to TC39 to see if they can bring something to the table.
Capabilities: Over dinner we discussed URLs to a particular resource where the access rights to that resource were part of the URL itself by means of a token in the path and the various implications of using that over a more traditional access control list model. E.g. whether we should have an HTTP header that indicates part of the URL should be hidden just as we hide passwords today. Jeni is currently sole keeper of these notes, but they should be public soon. (This was part of a larger discussion on Web Intents, Web Activities, and unhosted.org.)
DRM: One contentious bit of standardizing DRM is that it standardizes the API to talk to the black box, but the black box is not standardized and will likely end up being highly proprietary. An argument in favor of standardizing DRM that has been made is that when we standardized the video element we also standardized the API and left the black box (the codec) as an open question for which we eventually found WebM as an acceptable solution. (Of course WebM is not universal so whether this is completely okay is to be seen still unfortunately.) As a corollary, standardizing the API for the DRM black box will bring more content out of plugins and may at some point lead to a standardized black box (presumably then a white box). A counter argument goes that while everyone would be happy with a open codec, not everyone would be with W3C-blessed DRM. And that even while you could envision an “open” black box, nobody would use it because it does not provide the protection deemed necessary.
You can find the raw minutes here: March 18, March 19, and March 20. Time to get back to London.