We are super excited to announce the launch of the W3C’s
Web Platform Incubator
Community Group(WICG). Despite the funny name (“the
Why-See-Gee, really?”), this is a great new initiative that seeks
to make it easier for developers to propose new platform features
What we want to achieve
The purpose of the WICG:
- Make it as easy as possible for developers to propose new
platform features, in the spirit of the
- Provide a space where developers and implementers can discuss
new platform features.
- Incubate those ideas by providing guidance and a supportive and
inclusive environment to those who have never contributed to
standards (and even to those that have!:D); Ultimately
transitioning those ideas to a W3C Working Group for formal
standardization (i.e., making a “W3C Recommendation”).
- Modernize how we do standardization of platform features (yay!
no mailing lists… unless you really want one).
- Provide a
frameworkthat keeps all contributions free and open.
In short, we want to be a support group for aspiring
standardistas. We want to provide you with all the help you would
need in order to take your idea or proposal to the next level.
What we are not
We are not planning on being the new powers-that-be. You don’t
have to convince us that your idea is any good; and even if you do,
that might not help you much. What we would give you though is
feedback on your ideas formulation, and help you iterate on them to
improve the chances of them getting some traction once presented to
the appropriate group.
Are browser makers
Yes! Absolutely. Microsoft, Apple, Google, and Mozilla are fully
supporting this effort.
Inspired by what the
RICG achieved, the browser vendors
want to make it easier to have a dialog about new features in a
space that provides the required
framework with minimal red-tape. However, we require people to
join the community
Having early buy-in from browser vendors is critical for getting
something supported across browsers. Because all the browser
vendors are involved in this effort, ideas can be quickly vetted
from both a developer and browser vendor’s viewpoint.
By working together, we can create features that are fit for
their purpose and, hopefully, a pleasure to use—all while solving
How we hope to make
GitHub+ tooling + a
The elves at the W3C have been busy making sure we have the
toolsin place to make
participation as simple as possible. We will develop specs/use case
documents like we develop any open source software.
What’s the process?
Roughly, we want to follow the process already established by
the RICG, though we will adapt as we go. It will go something
State the problem: Write a description of a
limitation with the Web platform and either post it to
Discourse, spin up a GitHub
repo, or just publish it somewhere (e.g., blog post, gist, whatever
you like). This should be something you believe is missing in the
platform and would make the lives of developers significantly
easier if it were added. It can also be something you’ve noticed is
a recurring development pattern which would benefit from
Join the group: Before bringing the above to the
join the community
group , which means you agree with the terms of the
Community Contributor License Agreement (CLA). It’s critical if
join the groupor
else key members won’t be able to review or discuss your proposal.
Don’t worry if you forget, the Chairs will remind you and hound you
till you do :)
Evaluation: As a community, we will evaluate if
the problem can’t be solved already using Web tech. We will also
look at how many users of the Web might be affected. This will
require collecting data, real world usage examples, etc.
Use cases: If need be, we will formalize the above
into a use cases document. Such a document can help prove to the
community that there is indeed a need for a solution that needs
standardization (see the
Use Cases and
Requirements for Standardizing Responsive Images, for
Advocate: We circulate this with browser vendors
and the community at large—we pitch it to anyone who will listen.
Getting everyone on-board and in our corner is critical.
Specify it: Once we have buy-in from browser
vendors and the community, we put together some rough proposals
(e.g., a new HTML element, API, or HTTP header…) and we do an “
intent to migrate“: where we move the spec to a W3C Working
group to seek royalty free licensing commitments from W3C members
(you know, the “free” in “free and open”).
- (Bonus points)
Implementation: Help turn the ideas from words on
paper into working features in modern browsers.
(If you are interested in the formal process, take a look at the
Web Platform Incubator Community Group Charter)
We won’t sugar coat it: standardization is hard (just ask anyone
who survived the RICG:)).
The bar to add new things to the Web is going to remain high: We
might need to raise money. Or bring everyone together in a room,
like we once did in Paris. Or pitch ideas at conferences to get
more developer interest and get momentum behind a feature.
However, anyone who chooses to participate will be well
supported. We have some extremely experienced browser/standards
engineers participating who are here to help. If you don’t know
where to start, or don’t know your RFC2119 from your WebIDL, don’t
worry. We got your back!
Collaboration with the
So what’s the relationship between this group and the
RICG? Since we share members and
acronym parts with it, we thought it’s worth explaining.
RICGis focused primarily on pushing
essential responsive features into standards and browsers, as well
as getting more developers involved in the standards process. The
WICG will focus mostly on that second bit: incubation of new
platform features. We will help you take your idea of something
that is missing in the platform and help you grow it until it is
ready to be sent off to the appropriate group. This might even
include pushing something into the RICG.
RICGwill continue to handle all
things “responsive”, tackling the specific issues that have matured
from a gleam in someone’s eye into ready-for-prime-time
What about other
Groupscontinue to function as normal. However, the WICG
provides a one-stop-shop for features specifically targeted at web
browsers. Sometimes, new CGs might be spun off from this one to
work on a particular feature.
You can find the chairs on Twitter: