Dear W3C TAG

Last week following in tradition, TAG had an unofficial teleconference introducing old and new members and discussing the future and focus of TAG itself.  During this discussion (and prior to the election) the idea of bringing TAG closer to/making it more known in and relevant to the development community was raised (and seemingly supported by the co-chair).  Given this, I have offered the input of one developer (me) and expand on some of those points and their relevance here for anyone who cares to understand why I think these are important or relevant.

Read “build concensus” in the charter as “in the larger community”

Convince us.  Get us interested, excited and involved.  Given it’s very small size and makeup it provides (or can provide) a unique bully pulpit that has been under-utilized. One of the few things explicitly within TAG’s charter is to build consensus and I think that that has to read (though it seems to historically not been read as) as within the larger community.

Foster a More Direct Relationship With The Community

In order to use the bully pulpit, first people have to care.  Most developers didn’t even know that TAG existed until very recently.  The connections/credentials that the newly elected members have in the developer community is just one reason I actively campaigned on their behalf.  TAG members should hear, if not experience first hand, the pain and feedback that comes from the wider development community. We don’t ask that they solve each issue, merely that we feel that they understand them and aren’t off in an ivory tower somewhere saying “Let them eat cake” while we all starve.

A more public presence of TAG / members

One of the most interesting and effective things to happen in semantic web, in my opinion, was when TimBL did a couple of Ted Talks.  We need representatives that lots of people are willing to listen to, and I think we’ve just elected some good ones.  I for one would love to see blogs and talks by members (taking their TAG hats off if necessary) just to let people know that they are out there, involved and thinking deeply about significant issues whether those issues necessarily get picked up and addressed formally by TAG or not.

Back in the late 1990’s and early 2000’s TimBL wrote a series of thoughts on design issues ( including one that I love called “The Evolution of a Specification” ( which contains a lot of great insights and thoughts.  With a decade and a half in retrospect, I’d love to hear updated thoughts from him and others.

Consider how W3C process/policy affect long term health

Noah (the TAG co-chair) said,  “The TAG’s charter is to focus on the long-term architectural viability of the Web, but we need to do a much better job of having impact year-by-year. My perception is that these goals are sometimes in tension. How do we help a community that’s implementing “early and often” to also build an architecture that’s clean and will scale for decades?”

Historically within W3C at at large it does seem that those two things are often (maybe always) tension, but it doesn’t seem that they inherently need be and I think that that is something I would love to see TAG discuss.  A healthy architecture requires a system/processes that promotes health and I feel that there is currently a lot that doesn’t.

An inordinate amount of fuss and time and energy is spent at what really amounts to bike-shedding and formalities that are taken because of some other obscure formality which – at the end of the day, to many of us it seems at best silly and at worst confusing.  I’d like to see TAG comment on whether fixing some of this is actually part of creating a stable and healthy architecture – I think it is.

I think that you can sum up a lot of my thoughts on this as: Paving cowpaths implies that cowpaths can be created in the first place and really, they often can’t, and I think that is unhealthy and leads to an inordinate amount of missteps.

Layers, layers, layers

If TAG deals with helping to create layers and fundamental principles that allow, maybe even encourage evolution, then it’s work (and W3C’s) will be relevant for decades to come, and we will be able to collect data to show it.  Even if certain layers are improved or replaced, we will no more mourn them than we do the loss of manual typesetting when we read a book.

What we can learn from phone numbers?

The co-chair also cited the phone number system created 90+ years ago as example of something that has stood the test of time and a kind of model of what TAG needs to do as one of its larger goals “… part of the TAGs role is to help the community build a Web that will be viable in growing in 50 years, and maybe 100.”

Here are what lessons I think are worth drawing from that:

  • Like much of the success of the early Web it’s success appears to be largely because it is really about a targeted and small thing that wasn’t necessarily technically the best – it was the best that they could sell.
  • The inventors never imagined, or tried to imagine, all of the myriad of things that telephone numbers would be used for 50 and 100 years out – and if they had, you can bet they would have missed the mark substantially.
  • While it was created in 1923, it wasn’t really the world-wide standard until it beat out all of the competition much later.  It is entirely plausible that in the intervening years something better could have come along and displaced it.
  • It was decoupled from the larger system enough in design to allow that phones, transmission lines, and wholly new ideas using this infrastrucuture could all evolve more or less independently.

I am earnestly looking forward to hearing/reading more from this group and hope that other voices in the community (like you?) will contribute to the conversations and help make our collective future a better place.

The New Gang Of Four

For programmers, when we hear “Gang Of Four” we pretty much immediately conjure up an image of the blue and white book that most of us have sitting on a shelf somewhere in which four very smart people sat down and documented design patterns which would shape the way that people think about writing software for many years to come.  However, the concept a “Gang of N” is used frequently in politics the world round to denote a group of, at least somewhat like-minded people who form a voting block big enough to matter and thus wield a greater degree of power than any one of them could individually… Power which is often used to bring about significant changes rapidly.

The Powers that Be

Most developers have probably never heard of the W3C Technical Architecture Group, so if you haven’t, here it is in a nutshell:  This is a very small group of people at the W3C – a mere 9 people to be exact, chaired by Tim Berners-Lee himself – responsible for sort of envisioning the architecture of the Web itself and championing it.  I’m not sure exactly how much formal power they have, but in the very least it wields the power of the bully pulpit at the W3C and therefore to some significant extent over the actual focus that a lot of big groups drive toward.

The Need for Change

I will let you read more in the links below, but to sum up: Most of the stuff that this group has historically concerned itself with has little to do with the reality of some of the most important pieces of the Web platform that most of you reading this live and breathe every day.  If you want to think deep thoughts about how the Web is documents full of data interlinked through URIs – this is traditionally the group for you.  Don’t get me wrong – I’m not trying to trivialize it, but the Web is about so, so much more than this group has actively discussed and in my opinion this is creating a sad new reality where it seems that the importance and influence of the once proud W3C is less important to the everyday developer. If you now reference the WHAT-WG HTML Living Standard over the current W3C version, prefer JSON despite W3C’s enormous push of “technically superior” XML family of languages and tools and really want more focus on things that you actually deal with programmatically – then you see the problem.

One GIANT Chance to Make a Big Change

Only 5 of the 9 positions in that group are elected (Sir Tim is the chair and 3 positions are appointed – hmmm).  However, it just so happens that this time around 4 of those 5 spots are up for grabs… and somehow miraculously we managed to get 4 people officially nominated who could really shake things up!

  • Anne Van Kesteren
  • Alex Russell
  • Yehuda Katz
  • Marcos Caceres

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][5].

Basically – Make it concentrate more on the stuff you really care about:

  • Layered Architecture – increasing levels of abstraction
  • Close coordination with ECMA
  • Extensibility – Web Components / Shadow DOM – new APIs including composition and templates
  • Bring a level of “from the trenches” representation.
  • In short:  Advocate and use those powers for what people like us really care most about.

Let’s Get These Guys Elected!

Here’s what you can’t do: Cast an actual vote.  Only the 383 member organizations of W3C actually get to vote – but they get to vote once for every open slot.

Here is what you can do:  Lobby…. Use the power of social media to promote this article saying HEY MEMBER ORGS — THESE FOUR ARE WHO WE WANT  YOU TO CAST YOUR VOTE FOR… Tweet… +1… Like… Blog… Make Memes…

C’mon interwebs – do what you do so well…

W3C Extensible Web Community Group

The Web requires stability and a high degree of client ubiquity, that’s why W3C is important. However, that’s also part of the reason that standards develop at a comparatively, (sometimes seemingly painfully) slow rate: They take time, deliberation, testing and mutual agreement between a number of experts and organizations with significantly different interests.

While we frequently complain, that is actually a Really Good Thing™. Standards take a while to “cook” and the Web would be a real mess if every idea became a native standard haphazardly and with great speed:  Native implementations have a way of being hard to kill (or change significantly) once the public has free access to them – the general mantra is “don’t break it” – and that makes iteration/significant evolution artificially harder than it needs to be.  It seems that the pressures and incentives are mixed up.

The W3C Extensible Web Community Group was founded with a vision toward supplementing the traditional model with a new one which we believe is a better path forward in most cases.

Polyfills and Prollyfills…

Polyfills are a well-known concept and it’s an excellent, visualizable name for it:  Something that “fills the holes” here and there on browsers which are behind the curve with regard to implementation of a pretty mature spec.  However, since the term was coined by Remy Sharp a few years ago, and it has become an increasingly popular practice, its meaning has become somewhat diluted.

No longer is it the case that they are merely “filling in a few holes” in implementations based on mature specs – more and more often it is more like they are building whole new annexes based on a napkin sketch.  Within a very short period of time from the first announcement of a draft, we have some “fills” that provide implementation.

Given this contrast, it seems we could use a name which differentiates between the two concepts.  For a while now a few of us have been using different terms trying to describe it.  I’ve written about the concept in the past and it is the subject of Borris Smus’ excellent article How the Web Should Work.  Until recently the best term we could come up with was “forward polyfill”.  Then, on October 12, 2012 Alex Sexton coined the term “prollyfill” on Twitter.

October 12, 2012 “@SlexAxton: Prollyfill: a polyfill for a not yet standardized API”  

The Benefits of Prollyfilling

One thing is clear about the idea of prollyfills:   If we get them “right” they could radically improve the traditional model for standards evolution because they have a few very important benefits by their very nature. Most of this benefit comes from the simple decoupling from a browser release itself.  Since lots more people can contribute to their creation and you only need one implementation, they can be developed with much greater speed and by a larger community.  Such an approach also puts the author of a site in control of what is and isn’t supported.  In the traditional model, an author has no ability to change the speed at which native features are implemented nor what browser users will use to view it with.  Using prolyfills could allow the author to rely on JavaScript to implement the features needed, with only degraded performance, so this is a huge advantage in general.  However, even more of an advantage is realized in that scenario is that it allows multiple competing APIs or even variant APIs to co-exist while we round the edges and iterate because the author can choose which one they are going to use – that is pretty much impossible with the traditional model.  Iteration in the traditional model is likely to cause breakage which is a deterrent to use and therefore severely limiting in terms of how many use cases will be considered or how many authors can give meaningful feedback.   Iteration in this model breaks nothing, APIs and drafts can compete for users, get lots of feedback and ultimately if there is a clear winner it is evident from actual data before native code ever has to be written.

The value of the ability to compete and iterate freely should not be under-estimated – it is key to successful evolution.  Take, for example, the “nth” family of selectors.  They took a long time to come to be and it would appear that most people aren’t especially happy with them – they aren’t often used and they are often mis-understood.  Given the ability to create prollyfills for selector pseudo-classes, it is unlikely that this is the means of accomplishing use cases that would have won out, yet those limited resources ultimately spent an awful lot of time on working out details, drafting prose, presenting, getting agreement, implementing, going through processes about prefixing, optimizing implementations, etc.  In fact, the concept of nth was being discussed at W3C least as early as 1999 and parts of what was discussed was punted to CSS Selectors Level 4.  There was a definite effort to “answer all of the nth questions now,” and while what we have might be an “academically really good answer”  – it’s hard to argue that it’s really caught on and been as useful as some other things.  It’s easy to speculate what might have been better but the truth is, we’ll never know.

The truth is, currently a very small number of people at W3C do an enormous amount of work.  As of the most recent TPAC, the W3C CSS Working Group alone currently has 58 “in process” drafts and only a handful of editors.   This means that a significant number of them are going to be de-prioritized for now in order to focus on the ones with the most support or that are further along and new ideas probably won’t be undertaken for a time.  While they are trying to streamline the process, it does tend to go in fits and starts like this… Without a doubt, several of those 58 will be years and years in the making.

If instead, these same individuals could participate in less demanding, more advisory fashion to a satellite group of Web developers submitting experimental works and after a certain threshold could take over a fairly robust and reasonably mature draft, it is easy to imagine that things could evolve faster and those resources could focus a lot more.  Of course, browser manufacturers and standards bodies could participate in the same manner:  Adobe recently followed this model for their Draft Proposal on CSS Regions, Mozilla is working on a x-tags which implements part of the still very early Web Components API via script and as a general practice, the ECMA team does this pretty often.  These are very positive developments.

The Challenges of *lyfilling.

Currently every fill is generally implemented as a “from the ground up” undertaking, despite the fact that there is potentially a lot of overlap in the sorts of things you need to implement them.  For example: If you are filling something in CSS, for example, you have to (at a minimum) parse CSS.  If you are filling a selector pseudo, you’ve got a lot of figuring out, plumbing and work to do to make that work and efficient enough.  If you are filling a property, it’s potentially got a lot of overlap with the selector bit.  Or perhaps you have a completely new proposal that is merely “based on” essentially a subset of some existing Web technology, like Tab Atkin’s Cascading Attribute Sheets – it’s pretty hard to start at square one and that means that often these fills are comparatively low fidelity.

Another challenge with polyfills and prollyfills is how to write them effectively (best practices), how to make them discoverable and communicate what needs to be communicated about the degree of parity that they provide or their method/degree of forward compatibility.

Charting the Uncharted Waters

It seems clear that we could do with some cooperation and potentially some robust and well thought out and tested prollyfills for native APIs that would make some of this easier.

There really is nothing like “caniuse” for polyfills detailing compatibility, parity with a draft or method/degree of forward compatibility.  Likewise, here is also no such thing for prolyfills – nor is there a “W3C” sort of organization where you can post your proposal, discuss, get people to look at/contribute to your prose/examples, ask questions, etc.  No group creating and maintaining test cases or helping to collect data and work with willing W3C members to help make these things real or prioritized in any way.

In short, there is no community participation acting as a group interested in this subject.  These are gaps we hope to fill (pun intended) with the W3C Extensible Web Community Group.  We’re just getting started, but we have created a github organization and registered  Participate or just follow along in the conversations on our public mailing list.