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.
We want to provide a clear path from building the things you need using the tools you already have—markup, CSS, and JavaScript—to writing specs and inspiring native implementations. We want to help carve out a path toward real ad hoc web standards. A handful of professional standardistas paving a singular way forward for all of us won’t cut it; not as quickly as the web moves.
Today, most new features require months or years of standardization, followed by careful implementation by browser vendors, only then followed by developer feedback and iteration. We prefer to enable feature development and iteration in JavaScript, followed by implementation in browsers and standardization.
source
The gist of the Extensible Web Manifesto is exactly the process that the RICG envisioned from the start: the average developer gaining a voice in web standards not by picking semantics fights on arcane mailing lists, but by solving real problems with the tools we have at hand—markup, CSS, and JavaScript. We thrive on tricky problems, solving unsolvable issues like responsive tables, fixing unfixable mobile browser bugs, and adapting native syntaxes to better suit our needs. These solutions all represent a need for native browsers to more quickly adapt to the way the modern web is being built.
For emerging JavaScript standards, this approach works well. Developers who want to contribute features to the language are encouraged to prove the need for solution while providing a potential solution at the same time—not to write code the browsers would repurpose for themselves directly, but to use existing JavaScript syntaxes to shim and illustrate the pattern the new syntax might use. The same kind of community-championed standards efforts that gave us Promises/A+ continue to evolve the language with individual features like Array.prototype.includes. Transpilers like Babel/Traceur allow the average developer to do even more experimentation with syntax extensions while allowing us to start using those new syntaxes right away.
Picturefill started out the same way, though the end goal was a new markup pattern. The original Picturefill was written using divs and data- attributes to mimic the markup pattern that a native picture element might use, then made to work using JavaScript. This left us without the native advantages of speculative preparsing and a single request for the most appropriate source—things we couldn’t tap into on the front end—but it was enough to prove the usefulness of the markup pattern itself. As Picturefill matured along with the proposed standard, we ended up with a prollyfill that came pretty damn close to the spec—closely enough that it started seeing use before a single native implementation had landed.
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.
How do we prepare developers for a type of responsibility we’ve never had until now? To prepare a script for implementation in a browser means more than just a handful of unit tests; it means sharing and adapting tests between native and JavaScript implementations. It means a level of rigor not all of us are necessarily used to when producing a lightweight and “good enough” polyfill for a feature. It means stability and compatibility considerations we may not be able to fully understand. Then, anything we add to development overhead for the sake of ensuring native compatibility means adding a burden that any of us could opt out of. What would be useful for building stable software while having the added benefit of preparing that software to be treated as a real-world browser implementation?
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.
