The Extensible Web Summit: An Unexpected Journey

Still from Peter Jackson’s “The Hobbit: An Unexpected Journey” credit MGM/New Line Cinema/Wingnut thehobbitblog.com

This past Friday, two remarkable things happened. First, “we” held the first ever Extensible Web Summit in San Francisco, California (I’ll get to the “we” bit). Second, I attended it. While the former is amazing, the later is actually kind of incredible on several levels too – not because it is such an amazing thing to have me (believe me, my self opinion is not that high). Let me explain…

First, on a personal level, you should know that I am actually a hobbit. You see, I don’t do this sort of thing – at all.

“It’s a dangerous business, Frodo, going out your door. You step onto the road, and if you don’t keep your feet, there’s no knowing where you might be swept off to.”

I haven’t attended a conference since the late 1990’s, despite requests, demands, and even in one remarkable case where my own software was presented. Hell, I don’t even leave my house to go to work – my employer allows me to telecommute from my hobbit hole in the shire (rural Vermont – thank you for that Apollo Group). Except online or in places where I am employed or very comfortable I’m about a step away from Golem sometimes. It’s not healthy, I know, and recently I’m working on it – but for the past decade or so it’s been the case. So, my attendance is a small personal accomplishment for me. It was such an incredible pleasure to not just meet, but be warmly welcomed by so many of the great friends that I’ve made online that I felt compelled to share this very personal information. You all rock more than words can describe.

More importantly though, because I’m just a developer – and I went. Until very recently I’ve not been a member of anything officially in Web standards – and this meeting included my input. Not just me, but others like me. No one treated us as second class, though not many of us spoke up as much as I’d hoped we would have. It gave us an opportunity to see what’s going on, connect with other developers, standards writers, chairs and – very importantly – implementers to discuss things that are important to me and more fully understand the larger scope of what’s going on.. In other words: To play a role.

“That, my dear Frodo, is where I come in. For quite by chance, and the will of a Wizard, fate decided I would become part of this tale. It began, well, it began as you might expect. In a hole in the ground, there lived a Hobbit. Not a nasty, dirty, wet hole, full of worms and oozy smells; this was a Hobbit-hole, and that means good food, a warm hearth, and all the comforts of home.

Developer involvement and engagement is tremendously important to the vision we set out in the Extensible Web Manifesto. It’s critically important that we begin to work together to break down, tie together, prioritize and create an environment where we establish a virtuous cycle. To change the way we develop the Platform itself to be adaptable and evolutionary is an enormous effort – it’s not the natural state of existing standards bodies in general.

Your typical Web Standards Discussion…
Bilbo: Good morning.
Gandalf: What do you mean? Do you mean to wish me a good morning, or do you mean that it is a good morning whether I want it or not? Or, perhaps you mean to say that you feel good on this particular morning. Or are you simply stating that this is a morning to be good on?

But now, things are changing – and they are changing for the better. Obviously, in general, the manifesto is helping to change things, I believe we are actually approaching an architecture that lends itself to adaptation and evolution… But there is another thing worth noticing here too: Until a year or so ago, the vast majority of developers had never heard of the W3C Technical Architecture Group (TAG) and the general consensus was that they just weren’t that important. But then, developers got involved and helped elect a good group of folks across two elections and the TAG is turning out to be super useful in two ways: First, at helping to look across the working groups and break down the architecture of the platform, see connections and facilitate communication and realignment in working groups where it is necessary. Second, to help carry the voice of “We the developers” to places it was difficult for our voices to previously reach. This summit was actually an example of both. And it’s all out in public now – github, twitter, etc. If you write to TAG, they listen. I call that an incredible win.

You might recall that in the first sentence I said “we” held the first Extensible Web Summit. While the W3C was prominent, and it took place coinciding with a TAG face to face and other W3C meetings, it was not officially a W3C event. I am immensely grateful to Anne van Kesteren (whose TAG term has ended, but continues to be involved directly in the trenches/outreach) for championing this through TAG, and the whole TAG for setting it up and attending despite the fact that it was unofficial – that’s a really nice signal to us developers. And a huge thanks to Adobe for agreeing to provide a substantial location and to implementers and finally – to developers and implementors for laying down cash and budget to allow us to all show up.

It wasn’t perfect, don’t misunderstand. But no first attempt is. It was too short. The topics competed in not great ways such that we couldn’t get necessary people into all of them. There wasn’t enough setup/groundwork for more significant engagement so some sessions kind of jumped off the rails before they could really get started. Personally, I got much progress through side conversations in hallways and before/after – maybe as much I did in sessions themselves – but these are all things we can learn from and improve. It was good, but we can do better and I’m confident we will. If you were less than thrilled, provide some feedback and give it another chance. I’ll try to write about that in another post perhaps, or more likely to the TAG mailing list – but there were many, many positive aspects and I consider it a substantial step.

thcc_bilbo_01

Galadriel: Why the Halfling?
Gandalf: I do not know. Saruman believes it is only great power that can hold evil in check, but that is not what I have found. I found it is the small everyday deeds of ordinary folk that keep the darkness at bay…


All of this really stresses the importance of more direct developer involvement and finding ways to open the doors to the W3C/standards without creating total chaos. If this sounds good to you too, keep watching as my next post will be about an incredible opportunity arising there – which, as many of my posts – involves an election and requires your help. Stay tuned.

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 prollyfill.org.  Participate or just follow along in the conversations on our public mailing list.