Reforming the W3C TAG

And so it has come to pass that W3C Technical Architecture Group (TAG) elections are afoot. Nominations have ended and the candidates have been announced. There are four seats open and nine candidates running, so it’s worth understanding why anyone should vote for the reformers (myself, Yehuda Katz, Anne van Kesteren, Peter Linss, and Marcos Caceres). For general background, see my previous post. Here I’ll include more specifics, so if that sounds boring, here’s a kitten!

After doing much reading of TAG meeting minutes, f2f notes, issues, delivered products, and findings I’ve come to a sobering conclusion: the TAG isn’t focused on eliminating the biggest sources of developer pain today. Now, you can argue that this might not be their job, but I won’t agree. It’s the TAGs job to help ensure the health of the platform, both for publishers and search engines, but also for authors. And the web as a platform is in some real trouble today.

There doesn’t seem to be a sense of urgency in the TAG about the corrosive effects of poor design and integration on the overall usability and health of the system. The Web to the TAG, as I can understand it through the meeting minutes and notes, is a collection of documents that represent internally-referential collections of data which are are linked to other documents, not a series of applications that are attempting ever more impressive feats of richness on a platform that stymies them every time you hit one of the seams. In reality it is (aspirationally) both things but the very real tensions between them don’t appear in the TAG’s work, leading me to believe that it doesn’t comprehend the latter aspect of web development today and what that means for the future health and viability of the platform.

I drone on and on and on about layering because explaining each bit of the platform in terms of the one below it relieves much of the tension created by disconnected declarative forms and APIs. This matters because in today’s web when you go ever so slightly off the path paved by a spec’s use-cases, the drop-off is impossibly steep, and the only way to keep from risking life-threatening abstraction level transitions is to flood the entire canyon with JavaScript and hope you can still swim in the resulting inland sea of complexity. This is what our biggest, “best” webapps do today, relying on ENORMOUS piles of JavaScript that largely serve to re-create what browsers already do in the hopes of marginally extending that capability. It’s simply nuts, but the TAG doesn’t seem to acknowledge the threat this poses to everything it holds dear: linking, declarative forms, data…it’s all about to be lost beneath the waves, and because the TAG doesn’t understand the growing importance of JS, it seemingly doesn’t see the threat. Declarative forms disappear first beneath imperatively-delivered complexity; lingua-franca APIs next. Without ways of getting what your app needs while keeping one foot on the declarative path, app developers do what they must; declarative data and relationships become “nice to haves” not “the way you do it”. Layering provides easy steps between the levels of abstraction, avoiding the need to re-create what the platform was already doing for you along with whatever custom thing you need — and it’s not the TAG’s current agenda.

If elected, I will work to fix that. The TAG is the right group to formulate and articulate a theory of good layering in the web platform’s architecture and it’s the only group at the W3C whose mission is to help spec authors wrestle with large-scale design and integration problems like this. My background is in apps, and JS, and browsers, and I work at one of the few places deeply invested in ensuring that we maintain a healthy, declarative web for the future. I care tremendously about the viability of the largely-declarative web. Through my work with Dimitry Glazkov and many others on Web Components I’ve done as much as anyone in the last decade to help build a bridge between the JS and declarative worlds. Dimitry and I created and led the team here at Google that have put Shadow DOM, CSS Variables, Custom Elements, Mutation Observers (and Object.observe) into specs and on the platform agenda, all with the explicit goal of creating better layering; explaining the magic in today’s platform and drawing connections between the bits that had none before. And I think we need to keep building more of those bridges, but it’s hard when W3C culture views that agenda with suspicion. Why would any WG concern itself with integration with specs outside its charter? It’s the TAGs job to inject that global perspective. I believe the TAG should pursue the following work as a way of filling its charter:

  • Getting reconnected to web developers: today’s TAG isn’t composed of web developers (Sir Tim excepted) and the general level of familiarity on the committee with the pressing issues in web development seems low. As a member I’ll press to ensure that at least one of the face-to-face meetings each year overlaps with an industry web development conference (not an academic symposium). Having the TAG simply go and listen, and perhaps answer questions in such a forum, would do much to illuminate the gulf in understanding. I also support Marco’s agenda of direct developer outreach (G+, AMA, IRC, etc.)
  • Forming and expressing an opinion about idiomatic JS APIs: the W3C is the body that specifies JavaScript’s largest, most important standard library yet it doesn’t seem to treat that task with any care. Poor integration with JS types, idioms, library conventions, and calling conventions are the calling card of W3C APIs. The detrimental effects are pervasive and corrosive. The TAG should produce a guide on designing idiomatic JS APIs for WGs to use. Additionally, the TAG should use its spec review perch to call out poorly designed JS APIs as such and propose changes that improve full-stack integration. Lastly, the TAG should be open to facilitating (or teaching!) classes on how to design good APIs for the web. It’s a skill that can be learned like any other, and the TAG has a unique responsibility towards ensuring that the next generation of APIs is better than the last.
  • Bridge building to TC39: I’ve served on ECMA TC39 — the standards body for JavaScript — since 2007 and in that time I’ve seen how the dysfunctional relationship with the W3C enables terrible API design. Needless to say, the results haven’t been great. For a small taste, go look at some IndexedDB samples. There are dozens of terrible DOM APIs (from the perspective of JS) and JS fails to help describe interfaces well enough (from the perspective of DOM). The impasse has even been codified. For the sake of the platform and the developers who must use it, we need to do better. I will push to ensure that at least one of the face-to-face meetings of TC39 each year overlaps with a TAG meeting. I’m hopeful that with my fellow TC39 delegate (Yehuda Katz) and the maintainer of DOM (Anne van Kesteren) also on the TAG, we can make serious progress on this front, actively building a culture of understanding between TC39 and the W3C and furthering the common goal of a web that’s competitive and well integrated.
  • Advocate for layering: it’s the TAGs natural role to advocate for coherence in the platform, not only at the markup level, but also inside the app runtime bits that take up so very much of the time in W3C’s most active WGs. If the TAG doesn’t do this, asking the important questions at the right time and working to show the benefits of collaboration and cross-API thinking, who will? To combat this, I propose that the TAG take as an open issue the lack of coherence in the client side platform and work to identify the largest developer pain-points in findings that work to set an agenda for WGs in the future. There is no hope for a well-integrated, layered platform without every WG accepting some responsibility for the usability and layering commons, and if elected I will work to ensure the TAG is a tireless advocate for that commons.

If that sounds like meaningful progress to you, I’d appreciate your organization’s vote; along with your consideration to vote for my fellow reformers: Yehuda Katz, Anne van Kesteren, Peter Linss, and Marcos Cáceres. AC reps for each organization can vote here and have 4 votes to allocate in this election. Voting closes near the end of the month, and it’s also holiday season, so if you work at a member organization and aren’t the AC rep, please, find out who that person in your organization is and make sure they vote. The TAG can’t fix the web or the W3C, but I believe that with the right people involved it can do a lot more to help the well-intentioned people who are hard at work in the WGs to build in smarter ways that pay all of us back in the long run.


  1. Sam Tobin-Hochstadt
    Posted December 7, 2012 at 6:18 am | Permalink

    I’m curious what you think we on TC39 can do to improve this relationship. Do we need to spec more libraries (so that the W3C doesn’t try to design MultiMaps in the guise of URLs)? Or write a best practices document (can we call it “Effective JS”)? Or something else?

  2. Posted December 7, 2012 at 6:56 am | Permalink

    hey Sam!

    I see a couple of concrete routes: first, we need on the TC39 side to make subclassing of intrinsics a serious priority. It’s something that DOM does thorough the back-door all the time because we haven’t provided any other avenue. Allen’s Object Model Reformation gets my vote as one of the highest-priority things we can do for ES7.

    Next, I think we can simply go and meet W3C members where they are. I tried to get folks excited about going to TPAC this year, but no joy. Norbert, Rafael and I were the only ones there. If we plan a year in advance, I think there’s hope we can pull it off. TPAC is long enough that we could co-locate the meetings and overlap by a day or two.

    There’s also a ton of room to import and to the “architectural archeology” process WRT DOM. I’m working on a DOM Promises proposal right now, and eventually I think we should have Promises in the JS std lib. Same for events. Truly common stuff in DOM should very often get imported into the JS API where they make sense. Right now DOM is to COM as JS is to C++, and a meaningful solution to everyone is to expand the language’s API and semantics to fold in truly common needs over time. Else folks get left straddling the chasm, either as spec authors or as users.

    I do think TC39 needs to coordinate with TAG or someone else at W3C on an “Idiomatic JS API Guide”. We’ve gotten a couple of important things done — notably moving DOM properties to prototypes in WebIDL — but DOM and WebIDLs maintainers view it as the job of individual WGs to design sane APIs (punting on things like constructors to my great dismay. See:, so we should at least try to communicate what “good” looks like.

    So that’s my list. What do you think? What else would you like to see?

  3. Posted December 7, 2012 at 9:32 am | Permalink

    Putting together a best-practices document is *vital*. I try to agitate internally for good design, but I’m often late enough that it’s painful to remake early decisions. Getting this shit written down and promoted would be a huge help.

  4. Posted December 7, 2012 at 10:18 am | Permalink

    @Sam, #1:

    Note that it’s actually the WHATWG that’s designing MultiMaps in the guise of URLs. ^_^ It’s the effort of me and Anne, one of the other people running for the TAG.

    Anyway, I’m doing my best (and explicitly coordinating with tc39) to make sure that our API will be palatable to tc39 when they design MultiMaps.

  5. Sam Tobin-Hochstadt
    Posted December 7, 2012 at 10:32 am | Permalink

    Hi Alex,

    As far as TPAC goes, I don’t remember if you were at the previous join TPAC/TC39 meeting, but it didn’t seem like a particularly productive endeavor. Hopefully future joint meetings would be more useful.

    I’m a little confused about the connection between builtin subclassing (which is definitely important) and object model reformation (which is a much bigger change). Can you clarify what you mean?

    One more radical idea is that DOM APIs should just stop using the full power of the JS MOP to define their APIs, and only define things that can be expressed in JS. Obviously this can’t work for NodeLists and things like that, but why should new APIs (eg URL) take liberties with the language that we wouldn’t even take on TC39?

  6. Posted December 7, 2012 at 11:08 am | Permalink

    Hey Sam,

    I wasn’t at the previous TPAC where TC39 attended, but I’d hope for some sort of meeting where there would be a real agenda, the DOM folks in the room, and some pre-defined list of things to work through.

    I’m all for DOM APIs not using the MOP. I honestly think that from now on, anything that appeals to Proxies to define a DOM API must have a legacy reason to do so or it should be considered bad style. Being idiomatic is about doing what user code can (usually) do. Some of that is about excavating power and handing to everyone. Some of it is about not using extraordinary power for ordinary things. I think we need more of both kinds of restraint.

    Re: built-in subclassing and and OMR, think “how do I subclass Array?”.

  7. Posted December 7, 2012 at 11:31 am | Permalink

    Just to nitpick: Jeni also is a web developer, having done some brilliant work on the UK website of Acts and Statutes of Parliament. Admittedly, she’s Tim’s appointed member. :-)

  8. Sam Tobin-Hochstadt
    Posted December 7, 2012 at 1:17 pm | Permalink

    Tab, for best practices, just following what Alex says about Proxies would help, in part because once you can’t use magic as a crutch, you’re forced towards the kinds of designs JS programmers use. Dave Herman’s new book is also good for “best practice” JS.

    Also, it’s been great that you’re coordinating with TC39 (and following the above rule :).

    Alex, I still don’t understand about subclassing, OMR, and Array. Are you just thinking of the `length` weirdness?

  9. Posted December 8, 2012 at 3:53 am | Permalink

    Important correction:

    today’s TAG isn’t composed of web developers (Sir Tim excepted)

    Tim isn’t a web developer. He’s not built a serious web site (by modern standards) ever. He’s built a reasonably significant Web App (tabulator) but that was unlikely to generate any of the typical experiences that web developers face (no customers, purely for his own fun, no serious user base, etc.).

    Tennison is, in fact, a web developer, albeit an XML centric one with Semantic Web leanings.

    I’ve been vehement of by criticism of the TAG and would love to see some serious reform. But I like the details to be accurate!

  10. Posted December 8, 2012 at 5:14 am | Permalink

    Bijan: follow the link. It’s a joke.

    Regarding Dr. Tennison, I’ll let her speak for herself if she’s offended by my categorization. I will say, though, that in the sense I had intended it — someone who works with front-end tech — I don’t think the label would stick. But if a correction is due ill make it.

  11. Posted December 8, 2012 at 5:30 am | Permalink

    D’oh! Sorry!

  12. Posted December 12, 2012 at 3:31 am | Permalink

    Sam: Sorry I forgot to respond!

    Yes, the .length weirdness is probably the worst of it, but it’s related to using indexing operations. Should you, e.g., write into a slot beyond the current .length, you get the .length extended, meaning some sort of trap was handled based on the index operation.

  13. Sam Tobin-Hochstadt
    Posted December 13, 2012 at 9:23 am | Permalink

    Hi Alex,

    I still think this isn’t really about object-model reformation, and mostly just about other kinds of strangeness. It happens that you can’t syntactically write `myarray.7`, and so Allen’s proposal is enough to implement most of arrays (although length being a data property means you’re still hosed). But the basic point is that Arrays are weird, and we need to be able to *subclass* them easily, and reimplement them possibly (which Proxies work for). So I still don’t think OMR gets you what you want.

  14. Posted December 15, 2012 at 9:53 am | Permalink

    I get the impression that people like to conflate the platform or the browser and the architecture of the web. These are not the same thing and should not be the same thing.

  15. DigDug2k
    Posted December 18, 2012 at 10:53 am | Permalink

    Wanted to post a comment on your css-prefix post, but its closed for comments. Its been almost a year. There’s been a good concerted effort by webdevs to support multiple prefixes, as well as very very strong efforts by MS, Mozilla and Opera to advocate to sites as well as unprefixing by them. The W3C has moved these specs forward.

    In fact, the only two action points from your original blog post that I haven’t seen action on are

    1.) Add build flags to allow WebKit-based products to enable/disable vendor prefix support independently.

    and 2.) Chrome/Safari sunset prefixes as soon as is practicable post-standardization.

    Any word on what’s going on? I honestly didn’t expect anything to happen, but Webkit and Webkit vendors need to be called out on this stuff, and if the calling out can come from inside it has a lot more weight than when it comes from other browser vendors.

  16. Posted January 8, 2013 at 4:45 pm | Permalink

    Hi, forgive me for playing devils advocate a little.
    While the TAG could no doubt do with some fresh blood, and input from web developers, a couple of things worry me.

    1- Having read all four blog posts, at times it reads as, hey likes taken over this group to make them deal with our issues and ways of working. You may argue that isn’t a bad thing, but babies and bath water spring to mind. A TAG that only considers current web developer issues may be little better than the current.

    2- The TAG can look too academic, sure, but is not because they are looking at the web in 5 or more years time and discussing the issues, rather than the problems people face today. They are looking at building a combustion engine rather than the problems with the horse carriage (which isn’t to liken web development to a horse carriage).

    Linked Data, URIs and RDF may look like it has nothing to do with web development, but look at how much the web has changed in the last few years, key technologies now would seem irrelevant to those building web sites 10 years a go.
    Many applications are data rich. Imagine building a mapping site/app (hello Apple) but instead of pulling in data from various sources just magically pulled in data for places and locations from relevant sites on the net, and this was just a standard feature with no special API. A semantic and integrated web could offer applications and opportunities that at the moment can not be conceived. I’m not saying this is exactly what is in mind, but I think there is an argument that the TAG needs to look at both the short and long term, even if the latter may seem somewhat academic.

  17. Posted January 12, 2013 at 1:58 pm | Permalink

    Congratz. But please, try to deliver your promise ;)

5 Trackbacks

  1. By Web Reform « Clint Hill on December 7, 2012 at 7:44 am

    […] Web Reform « Previous / Next » By Clint Hill / December 7, 2012 / JavaScript / Leave a comment This is what our biggest, “best” webapps do today, relying on ENORMOUS piles of JavaScript that largely serve to re-create what browsers already do in the hopes of marginally extending that capability. Alex Russell […]

  2. By The New Gang Of Four | briankardell on December 8, 2012 at 8:45 am

    […] If you don’t know who these guys are – I think you just aren’t paying a whole lot of attention…   They are smart, super active (dozens of influential working groups and important open source projects) and not the sort of guys who sit quietly and go along if they disagree.  A few of them have written some good articles about what they think is wrong with TAG now and what they plan to do if elected [1][2][3][4]. […]

  3. […] fellow “TAG reformists”, Alex Russel, Marcos Cáceres, Anne van Kesteren, and Yehuda Katz have already written extensively about this […]

  4. By TAG, You’re “It” | Brendan Eich on January 11, 2013 at 12:53 am

    […] is great news: four out of the five reformers […]

  5. […] to write about my return now. I was elected to its Technical Architecture Group, as part of a reform campaign driven by Alex Russell. Alex has great ideas on improving modern day web development and I share […]