My first TPAC conference
Two weeks ago I attended the W3C TPAC conference. In this post, I'll go over my experience and learnings. Read on if you're interested in how the "sausage is made" when it comes to web features.
W3C is the standardization organization that develops most of the specifications for the web features that web browsers implement today. TPAC is W3C's annual face to face meeting (though it was hybrid this year) for the various working groups that work on new web features.
The 40 (or so) W3C working groups are made up of people who have an interest in the particular technical area a group focuses on. For example, there's a group about browser automation and tooling, and in it are people from the various browser maker companies, Selenium, and other companies who are particularly invested in browser testing.
The groups hold video-conferencing calls on a regular cadence in order to review proposals and make updates to their specifications. So, when TPAC comes, they all meet in one geographical location to have a series of face-to-face meetings. This is a great forcing function for the various working groups to come to consensus, make decisions, come up with new proposal, as well as meet with other working groups.
That's my high-level definition of TPAC anyway, and this was the very first time I attended this conference. Other people who are more used to it might have different definitions. To me, though, this is all about the people and making connections. Being in one place, surrounded by hundreds of people who basically make the web happen is pretty awesome. It's a great chance to get to know people personally, break the ice, and create long lasting working relationships.
The location
This year, TPAC happened in Seville, Spain. And, my, what a beautiful place. I had been to Seville as a teenager, almost 30 years ago. But at the time, I wasn't really paying attention to the same things. Plus, I blanked most of it from my memory. So I discovered the city all over again. Mind you, I wasn't there as a tourist, and certainly didn't have a lot of time to visit. But I had the opportunity to go and explore on the Sunday before the conference, and then early mornings and late evenings too.
The city is just super pretty, with narrow streets in the older part of town, a beautiful and gigantic cathedral, people playing guitar and dancing flamenco in the parks or squares, many tapas restaurants with people dining on the terrasses. Taking a stroll in the city is very special.
As for the conference venue and hotel, it was at a distance from the city center (maybe 15 minutes walk), but super close to the Plaza de EspaƱa which is a very nice park.
There were many meeting rooms and they were spacious enough, sometimes even too spacious. The one downside was the acoustics of the meeting rooms, which was pretty bad. The rooms had a lot of echo, and just moving your chair, pouring a glass of water, or clearing your throat would be disturbing to the meeting. Remote attendants on Zoom must have had a hard time with the sound quality.
How W3C meetings go
I was very impressed with the processes and tools in place for the working group meetings. But, then again, these folks have been meeting for years, slowly perfecting ways to run efficient and inclusive meetings. Now I'm not saying the meetings are necessarily perfect, but the process in place comes with important benefits:
- Meetings are always minuted, making it possible to go back to past discussions, which is very important when working on (generally) slow-moving spec documents.
- Anyone can ask a question without being an extrovert and having to interrupt somebody.
The process comes down to using IRC (yes, very 90s style, it's hard to believe it's still used, but the working groups have a few bots and commands that would be time-consuming to replace). For each and every meeting, the working group uses their dedicated IRC channel, and starts a bot that handles creating a minutes document and manages the question queue. Participants signal their presence with a command, and there's another command to put yourself on the question queue.
The person who drives the meeting can then just ask the IRC bot to go through the question queue, therefore letting people say what they have to say, one by one. It does make it a little bit awkward, at times, with conversations that need a lot of back and forth discussion. However, it's really good, especially when you're an introvert, that you don't have to impose yourself verbally to say something.
The scribe (the person who takes notes) tries their best to record what people say in real-time by writing it all down in the IRC channel. At the end of the meeting, the bot posts the full minutes to the relevant GitHub issue, or to the working group's website.
One downside I see with this system is that the full minutes don't only include what people said. It also includes the various commands people typed during the discussion, like when they want to ask a question. So the IRC minutes are a little hard to read.
Some working groups used Google Docs instead. It made it a little bit trickier to manage the question queue, but it worked. The scribe would take notes in one area of the document, and people would write their questions in another part, dedicated to the question queue.
Overall, I thought this was a very good way to run remote meetings and, as a fully remote employee, I wish we did this systematically at work too.
The meetings
I attended a bunch of working group meetings and breakout sessions. Among others:
- The Web Applications working group, which reviewed the status of a bunch of specs, from low-level device and sensor APIs, to screen locking, geolocation, and Image Resource APIs. The group also reviewed Microsoft's proposal for an imperative way to install PWAs with
navigator.install()
. PWA launch handling was also reviewed. - The future of cross-browser web apps breakout session, which was mainly focused on the installability criterias that browser expect of PWAs, and whether they were still needed. Not suprising since Apple recently shipped support for installing any website in Safari, whether it's a PWA or not.
- The Web Incubator Community group, which discussed about low-level device APIs, MIDI, and permissions.
- The Browser testing and tools working group, which went over various issues and proposals related to the WebDriver BiDi spec.
- A breakout session about the Interop project, which helped me more clearly understand the feature selection process.
- Multiple breakout sessions from the WebDX community group about Baseline and doing developer surveys.
I also co-hosted a breakout session, together with Florian Scholz (Open Web Docs) and Rachel Andrew (Google). The topic was technical writing and how spec writers and implementers can help get their features more easily adopted by helping technical writers document the features on MDN.
The breakout sessions day was super fun and informative. It's basically a day in the week where anyone at TPAC can propose a topic to present or discuss about. These meetings are shorter than the working group meetings, and are usually best for presenting a new idea and getting some quick feedback or hosting a Q&A session about a particular project or idea.
The other days were filled with working group meetings which, based on the ones I attended, tended to fall into two main categories:
- Business as usual, the working group goes through its list of regular issues, takes decisions if needed, agrees on next steps, etc.
- The other case is when the working group talks about new proposals. The vibe is clearly different in this case. Usually a browser vendor comes with a proposal that makes sense to them for whatever internal strategic reason, presents the proposal, and then attempts to build consensus on it with the other working group members. The tricky part is that the other members often include people from other browser vendors who might have different priorities and strategies in mind.
Don't get me wrong, it's all for the better. Out of the thousands of random ideas that people have for what web features should exist, it's great that they go through so much scrutiny, and that only a few of them make it. It's also great that this happens as a result of stakeholders debating and agreeing on the details of how a feature fits in with the rest. It does sometimes get tricky when browser vendors go ahead and implement their proposed ideas before they're even spec'd. In fact, this almost always happens. When you go and present a feature proposal, it's common to have specified it in a non-official place already, and to have implemented a quick prototype of it. It's tricky when the feature has started getting adopted, or even became a de-facto standard already. Having cross-browser agreement about the feature and how it should be spec'd is challenging at that point.
It was very interesting witnessing some of the more heated discussions, and seeing how people represented their respective organization's points of view.
Attending TPAC was pretty eye-opening. Even though I have been working on browsers for 10 years, I've not been super involved in the standardization aspect of the work. If this aspect interests you, I can only recommend following what the various working groups do, and maybe getting involved in one of the many community groups.