Skip to toolbar

Community & Business Groups

Extensible Web Community Group

The Extensible Web Community Group is an incubator for web technologies enabling authors to extends the native web technologies via scripting (ie: shims & polyfills).


Group's public email, repo and wiki activity over time

Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.

No Reports Yet Published

Learn more about publishing.

The Extensible Web Manifesto

Yesterday, it was made official that our group, by the intermediate of its founders, co-signed a manifesto for a more extensible web.

You may ask yourself what it actually means, and why this is important.  Allow us to explain.

An extensible web is a web where developers are totally incorporated in the innovation scheme of the web platform, and can actually build new features instead of just relying on the ones browser vendors could agree on.

Being able to extend the browser means many things. Firstly, it means you can provide a new feature to older versions of a browser, by implementing it in JavaScript. Currently, this approach (called polyfilling) requires a lot of hacking knowledge because web developers are not granted the same access to the browser features than browser vendors itself. One of our goals is too make sure that, when possible, web browsers leave a little bit of room to web developers to extend the browser features, without requiring us to reimplement them from scratch.

The second reason why an extensible web is more beautiful is that, even though APIs are crafted by smart people in standards committees, mistakes can be made from time to time. Don’t get me wrong, mistakes are normal: no process can be free of mistakes. However, the problem with the current standards process is that mistakes are generally irreversible; it’s difficult to make experiments with a broad audience.

Once something shipped in a browser, removing it is painful (at least) and often impossible. This is why this process is taking so much time: we have to be sure we’re doing the right thing. But, sometimes, web developers can’t wait. By shipping a very minimal set of features that allow web developers to build libraries around low-level features, we can see what works and what doesn’t work and take that in consideration when designing the final version of the API. This helps creating better in-browser features, and it also helps shipping early implementations faster. This approach is called prollyfilling.

In short, an extensible web leaves more room for short-term innovation and experiments, without compromising a stable and harmonious future.

In case you didn’t already, I invite you to read (and sign) the manifesto, and look at some of the links provided from there.

In the name of this community group,
François REMY

Scope of the Extensible Web Community Group

Hi everybody! Firstly, welcome in this group.

At nExtWeb, we have the following missions :

  • Collect good samples of prolyfills and get the prolyfill concept “known”.
  • Analyze existing prolyfills and spec new browser’s features that would make them easier to create.
  • Create samples and guidelines for prolyfills writers.
  • Get the concept of “forward polyfill” known by the other W3C groups and encourage spec editors to create prototypes using prolyfills.

To get all those things done, we need your help! If you can do one of those things, we would love to hear from you:

  • Writing shim or polyfills
  • Sharing your coding experience and pitfalls
  • Reading and editing web specifications

We’re using our public mailling list ( and (from time to time) our IRC channel to discuss polyfills and web technologies, so you may be interested in coming along to see what’s going on!


This is an example of a piano in Padua.

As a side note, our group doesn’t have the following missions:

  • Replace existing working groups by making normative specifications related to their scope (even if we reserve ourself the right to publish unofficial drafts and expose them to the relevant working groups)
  • Standardize the extensions added by prolyfills to the existing web specifications (we only standardize the way prolyfills can be written, and we propose tools to other working groups we think they should implement to make prolyfill writers life easier)

Any question? Feel free to leave a comment!