Illustration by Sue Lockwood
Participating in the creation of a new standard means joining listservs that look like they were put together circa 1850 and asynchronous arguments in IRC channels that span any/all timezones. It means devoting your nights and weekends to learning how to tinker with specs and fighting with professional web standards reps. To get certain things done for real, you need to start attending F2F meetings—so, be prepared to buy the occasional out-of-pocket plane ticket to Europe and to burn through your vacation time. On top of it all, as a web developer, expect to have your vote count for less than that of a browser representative, and the vast majority of web standards participants are browser reps. It has all the makings of a lousy part-time job, minus the pay. Whenever I encourage web devs to get involved—to help change the power balance by sheer force of numbers—I do so with an unspoken apology.
While championing the standards that matter most to the community, the RICG has never been particularly quiet about its secondary goal: making itself obsolete. For web standards to move as quickly as the web itself, we designers and developers can’t be content to defer to the influential voices; we can’t assume that “important web standards people will figure these things out.”
A small group of full-time browser representatives can’t have the same level of perspective on day-to-day web design and development as those of us that are doing it eight hours a day. The RICG aimed to change that imbalance by meeting web developers where they were, engaging them through polls and casual channels like Twitter while working alongside browser reps and implementers. But no matter how good the intentions of a group of web standards personalities might be, that still leaves a small group of individuals with all the power—it still leaves a single body, nebulous though we may be, as the web standards gatekeepers. Being web developers ourselves doesn’t give us that right.
Picturefill started out the same way, though the end goal was a new markup pattern. The original Picturefill was written using
data- attributes to mimic the markup pattern that a native
Even before the Extensible Web Manifesto existed we were living up to its ideals: developer adoption proved the demand for a native solution. Picturefill wasn’t just a polyfill—it had become an implementation.
But mistakes were made. Picturefill shimmed features that didn’t yet exist in browsers, and no matter how closely we stuck to the spec it could never be one hundred percent realistic. Browsers are apt to interpret the spec in slightly different ways—no matter how carefully those specs are written—and they’ll make mistakes of their own. Picturefill broke native implementations and we had compatibility issues; web developers’ work was being counted as an implementation and native implementations were being compared to it, and we didn’t plan for that. We wouldn’t have known how to plan for that if we’d tried. Picturefill was so widely used that browsers were unable to ship browser features that caused issues in Picturefill, and we were unable to fully test Picturefill against features that didn’t exist in browsers yet.
For all their lofty goals, both the Extensible Web Manifesto and the RICG end up short on details and long on questions.
Process-wise, there were times when Picturefill delayed real implementations. “What’s the rush? Developers already have a solution for this in Picturefill.” So, where’s the line—what’s the hand-off? How do we build something that drives native implementations—and acts as a reference implementation itself—without disincentivizing the real thing? How do we engage browser representatives directly; how do we collaborate with browsers, solicit feedback, and—with their help—guide a script that countless developers might already be using in their day-to-day work toward acting as a reference implementation?
Even with the TC39 approach to ad hoc standards development—where things have worked out fairly well—there’s potential for things to get out of hand. At what point does a popular syntax extension become a de facto standard, and at what point does that de facto standard become an expectation in our tooling? Babel is extremely accepting of new syntax extensions, but other projects may have compelling reasons to take a more considered approach.
Bocoup has recently begun talking with browser representatives about these issues, and about the role developers and designers will play in web standards going forward. They’re matters of outreach and education, of development processes, and of testing and tooling—none of which can be solved in a vacuum. To do this, we’re asking for the support of browser representatives and implementers who understand that web standards can’t keep up without encouraging direct input from designers and developers. We’re asking that web developers not sit idly by, waiting to see whether a key group of web standards personalities have seen their shadow and heralded six more weeks of AppCache. We want to help web standards adapt to the realities of the way we all work, and we can’t do that alone.
Personally? I want answers. I want the Extensible Web Manifesto to not be some grand, sweeping set of philosophies, but a concept as built into the way we work as open source is now. That’s how I think about Bocoup’s mission of “moving the open web forward”: we can build a great website—we can build fifty great websites—but that alone won’t move the web toward something better, faster, or more inclusive. That work is our basic responsibility to the web. Empowering any designer or developer with a good idea to add their voice to the web platform—changing how the web itself is built by all of us, day to day—that, to me, is moving the open web forward.
We moved off of Disqus for data privacy and consent concerns, and are currently searching for a new commenting tool.