2024 Standardization across layers

WEH 2024 - Standardization across layers: Experiences with HTML, JS and Unicode

• GitHub issue: https://github.com/Igalia/webengineshackfest/issues/27

• Slides: https://docs.google.com/presentation/d/1fXJEQ2uWnaMhn0uFVDGoThZx48QdVo2NqdSJK5C4FKM/edit#slide=id.p

Notes

Dan: Software stacks loosely correlate to standards with several groups of people. Valuable efforts span many layers of the stack, we should learn from the past to do better in the future.

Dan: BigInt has integration into WebIDL and WebAssembly, challenging to get reviews across standard layers. The plan can be complicated and needs to be planned to be ergonomic and provide real value to the web platform. What feedback should have been taken in, browsers feel bad that it was too much work so are cautious about (Big)Decimal. BigInt was a TC39 effort; separate from WHATWG/W3C so need to coordinate between standards bodies.

Dan: Took a year or two to link together modules (ESM) and script tags. Several features are similar in needing coordination between specs. Many CSS features abstract over the DOM and have to unify features with HTML mapping.

Dan: MessageFormat is a new feature for having i18n strings with placeholders which can be filled in depending on locale. It started as TC39 TG2, a TC39 task group, but moved to Unicode. Some trouble moving back to TC39. Also some effort putting it into the DOM again.

Dan: AsyncContext is a way to have dynamically scoped variables, to share information across code. ShadowRealms needs deciding what web APIs are visible. Signals need deciding if it should have DOM integration. Modules and Wasm GC too. Those were some examples to start the conversation, we should discuss.

Tim: With respect to the BigInt example and implementors "regretting" having implemented it, what would it take for them to be happy with having implemented it? How do you know if a feature has had success with web developers?

Dan: For example, Google has internal and external partners; they care about whether a feature is useful to those partners, specifically. It's about which stakeholders they care about, specifically. Some help from CMSs to see if developers are actually using features.

Philip Chimento: One obstacle is building trust to get working between standard layers working nicely. Each group is full of people with their own personalities/quirks, being an outsider requires energy convincing people you are worth listening to. Since it takes a lot of energy for just one group, it would take a lot to be involved with several groups. I don't think it is people wanting purity.

Dan: I don't think it is WebAssembly wanting to be separate to JS. Could you talk about ShadowRealm as an example?

Philip Chimento: You could beat your head against a wall trying to get people to listen and usually is by chance you happen to talk to someone at the right time.

Dan: Could you talk about your experience with Temporal?

Philip Chimento: Started by writing many presentation until I was seen as someone sensible to talk about it.

Dan: 4 different groups for Temporal: TC39, TC39 TG2, a IETF WG around ISO-8601 (RFC 3339, 9557(?)), W3C TAG review (web platform integration feedback). Temporal's design was influenced by feedback from all those groups. TAG review said input elements without some information (year/month/etc), so Temporal added those types, but then other people complained about having too many types. IETF was quite a mess, something about their structure allowed someone to chime in every few months that it was wrong causing it to take years. What have we learnt from other standard groups, should we have worked less on working with the IETF?

Anne: Worked a bit with IETF, dislike format used to publish standards and maintenance. Each time a new change happens you have to write an updated document, no process in place for updating existing standards (no revision).

Dan: At least W3C has an emerging norm of pointing everyone to the the editor's draft.

Anne: IETF needs a set of documents for the implementation(?) but can still mismatch.

Nico: Does IETF charge for access to standards?

Dan: No, but it has a classic format of monospace text.

Nicolò: Worked with TC39 for modules, which needs interaction with HTML. There is no stable communication channel between TC39 and other groups, individuals have to maintain contact themselves. WebAssembly and TC39 there is only a single person doing so. When I had to interact with WHATWG, it was just me and had to gain trust, no way to just say I am coming from TC39.

Dan: (?)

Nicolò: (?)

Dan: Some of this might relate to philosophy of different standards bodies. WHATWG is quite technical rather than caring what organisation you come from. Regular WHATNOT calls exist now, but are they advertised enough? Should there be mentoring for web specs/TC39?

Nicolò: Official WHATWG representation in TC39 would be nice.

Dan: People come from different browsers but just from their browser engines, mostly spreading a general web point of view.

Anne: Are groups large enough to have an official channel/collaboration? At least with WHATWG there are only a handful of editors (reviewers). Having people talk on behalf of the entire WHATWG seems bad, should just use PRs and discuss there instead of having a separate channel. A PR seems easier for discussion than a backchannel.

Dan: Engaging with individuals seems easier than representing orgs.

Luca: Import assertions/attributes shows that doesn't work. Sometimes the problem being solved can be unclear and take years with TC39.

Dan: The same case with Mozilla/WebKit (?)

Luca: WHATWG was the problem not TC39.

Brian: Is the problem similar between CSSWG WHATWG and OpenUI WHATWG? What about the task force meetings (?)

Brian: Similar layers of the stack exist and some people open issues to move to the correct place. OpenUI tries to involve developers and figure out how to best go to WHATWG/HTML standard. There are plenty of engine/standards people there but different things were considered. PRs can be out of sync with discussion.

Dan: Can you give a concrete example?

Brian: There are working groups (WGs) and community groups (CGs) at W3C. There are some super groups (?). OpenUI is an example. Anyone can join a CG. OpenUI tries to style and extend existing HTML controls, eg: select. Much more complicated select is possible and used in the web already, how can we make select better (more stylable, more capable)? Some people discussed and a PR was made (?)

Keith: For select, an example is filtering and unbounded lists. By large, select lacks the extensibility to do so without having to reimplement it from scratch, which many design systems do. New implementations web developers do often have a11y problems. Going for a whole new element instead of trying to hack things into select, but WHATWG disagree with that idea. If there was more collaborative iteration it probably would have taken less time, it took a lot of time to get there. There is a satisfactory outcome today but there are some scars from that. Not sure what there is to learn from exactly but more open collaboration is great.

Dan: (?)

Keith: A more iterative process is where we are headed. Open Stylable Task Force (?) is looking at how to see what parts compose a selectmenu and how it could be used to style it. Form controls are interesting because they often use the native UI of the underlying OS in browsers. The implementations can be disjointed.

Anne: When designing something new it is often useful to have a small group of peers to give feedback so you can iterate quickly. But if you don't question your assumptions or ask other people you could accidentally make an echo chamber and lead you to have to redesign decisions made early on. At what point should we reach out to experts and to what extent, you don't want them to be fully engaged as that can take a lot of time. I try to file issues proactively or email people on other sides to get thoughts. Balance requires improvement. One group off doing something(?) so are left behind. There might be a better way but requires time.

Dan: For me with TC39, filing those issues or encouraging others it feels like the issues have to be perfect to get constructive reviews since the group of people to give feedback is small.

Anne: Only so many experts to go around. More editors is possible but shrug.

Nico: I haven't really been involved in standard bodies and most experience is from a consumer. TC39 and WHATWG seem inaccessible to me, for contact or to get a usable response if I did. TC39 has many proposals and stages, looked at getting involved but last activity was 2 years ago so seems unlikely anything will happen. Reminds me of a discussion in the Rust (lang) core team of there only being so many experts. They are actively working on trying to get more people involved. They have an RFC process but unless you get that RFC perfect you just get denied and have to try again. There is a new space to propose problems and solutions which seems interesting.

Dan: There are some attempts with that too, eg you join Matrix channels. But people still feel like it is inaccessible.

Keith: Web Components CG is interesting, we have monthly regular sessions but also a quarterly implementers f2f. A lot of people involved are consumers not implementers so there is some discussion there, but we prefer to discuss rather than have concrete solutions for better collaboration with actual standard authors or engine implementers. Sometimes the CG spins their wheels in monthly meetings, and an implementers meeting often directs and invalidates the last few months of meetings due to not having the feedback due to a slow iteration cycle.

Anne: Another problem is not having enough people with both knowledge and free time to turn problems into solutions. There is a balance with editors of having (?) but also needs the company they work for to want them to work on. There is only a limited amount of time people have, so giving feedback can sometimes be a problem as there is not such full responses due to that lack of time, which could be seen as dismissive.

Dom Farolino: When going to editors/experts for feedback it could be trying to get some time in a WHATNOT meeting rather than just dumping an explainer. Getting the key items from an explainer requiring approval from experts is nicer rather than requiring experts read through entire proposals. It has been useful for me to get actionable feedback. Repeated feedback on WHATWG feeling inaccessible, but you can filing issues, we havie open calls, chat, etc but people still say it feels inaccessible. From the inside it feels accessible so why do people think so?

Nico: I wasn't even aware there were regular meetings open to attend.

Dan: TC39 is in a similar place where we have tried to be open but also get feedback saying it feels inaccessible.

Luca: I know regular meetings exist and talk to people, but it still feels incredibly difficult to propose something to WHATWG unless you implement it in an engine (or find someone else to do so), or find a case for implementors to do so themselves. The bar feels very high, even for trivial changes with clear benefits. WebSocket constructor's second argument is currently an array. Deno wants allowing having headers passed to it, turning the second argument into an options bag or an array. Trivial change, I could implement it easily in all engines. But still hard. Finding people to listen is difficult, I can ping Domenic but still takes months to get feedback. I understand why some people don't care but it still feels inaccessible.

Dan: TC39 does not have the structure of having people file issues for problems. Once people propose a solution we require gradual buy-in before getting consensus from browsers to get implementor support.

Anne: Recently you could agenda+ issues and nominate to the next stage. We copied TC39 stages (for the most part), so those now exist to try and push things through. whatwg.org/stages

Dom Farolino: If you add the Agenda+ label on issues, it will be scheduled for the next WHATNOT meeting, which is how you get things in front of the people who can move things around. Should be publicized more.

Dan: Glad you publicised it now.

Luca: Seems useful to tweet about (@whatwg).

sideshowbarker: Put weekly meetings in an issue template for advice on how to escelate it (if wanted). Rotating schedule, there is no guarentee it will not get pushed to the next meeting due to people missing. Can we put that in an issue template or pin somewhere?

Nico: How can we advance stages? By attending meetings? It should be advertised. I did not know I could add something to the agenda for meetings.

Dom Farolino: You need triage access but you can ask someone to put it on the agenda to get traction. Maybe it should be advertised more.

Nico: There could be too many people trying to do too many things

Brian: How is it not a problem that we only have one IRC/Matrix channel for WHATWG? It has never been an issue before.

Dom Farolino: Still bounded by the amount of work required. More important things or easier things getting through though.

Dan: Matrix can cause a small barrier of entry. I setup a Discord for the Signals Proposal which seems much more active than the Matrix channel for it. Getting contributors through Discord is nice. Even if someone signs up to Matrix, you could not notice notifications, etc. Maybe slight barriers of entry are good?

Nico: Viewing the history of a Matrix channel or browsing the list of channels can be difficult.

Dan: Discord does not make it easy to browse history which was one of the reasons we went with Matrix. There is a bot we use in TC39 and WHATWG to log the Matrix history: https://matrixlogs.bakkot.com/

Dan: Should we talk more about other standards bodies (due to time)?

Keith: I have been attending CSSWG meetings for a few months. It has heavy discussion for big topics but there are some agenda items that constantly fall off the list. What is the solution to that? I understand big headline features need more work but I want other stuff to be discussed too. Web Components WG wants some Shadow DOM encapsulation issues to be addressed, but there is no time to put them on the agenda.

Valerie: I am the chair of the ARIA WG at W3C, have been for a past few years. When you join the WG you get an onboarding email which is not great. But then once a few new people have joined we propose an onboarding call/discussion to discuss. All docs (Matrix, chats, etc) will never be as good as 1 on 1 outreach. Hard problem to solve. Inter-personal connections get people involved, if we care about making specs more open then we need to allocate labor of helping new individuals get involved. How can that scale? WGs should think about having onboarding people as well as chairs, or somehow paying people to do so. W3C pay people to help with organisation of working groups, could they have onboarding people for various groups?

Dan: At least for TC39/WHATWG (?) people are putting a lot of work into this too. TC39 has welcome emails and beginner sessions too. The pipeline of stages is good but not enough. Formally allocating onboarding seems tough, you could join just to listen. TC39 is perceived as friendly just to get input, but when you try to push a proposal through it seems a lot less friendly. It makes sense to some degree but we should probably work on it.

mrego: On the CSSWG, there is usually a long backlog. Keeping things until F2F to discuss in person. There are just a few people working full-time on CSS specs, 2/3 people? (?)

Oriol: re: backlog of issues. Less F2Fs due to COVID could have caused it. Now it is normal to have 60 issues with agenda+, meaning somewhat urgent, but it can take months to be discussed. Having more F2Fs or having longer meetings some weeks could help the situation a bit but complex topics (anchor positioning, view transitions) need so much discussion they worsen the backlog. For people who want to resolve their issues it could be demotivating having to wait for so long. An example was an issue about floats, which I scheduled for the last F2F but it wasn't discussed, I wanted to discuss it in today's (?) meeting but it also was not.

Brian: There are ~5000 open issues in the CSS repo. It is a super group. There are people doing full-time work on the spec, implementers, and more. Needs focus from each group of people contributing. Sometimes meetings are dedicated to solving problems on entire projects, which is sometimes used to make breakout sessions. There were weeks of CSSWG meetings of just CSS grid topics. It'll happen eventually when there's a lull, or when you convince other people to put it on the agenda for the next meeting.

Dan: Not sure how but at TC39 we went through our backlog. Bringing the topic back to working between standards groups. How should we facilitate those overlap points? We agree iteration should happen but also some groups are overloaded. What should we do?

Keith: At work we have a big a11y problem with some a11y experts. We also have a champions program (?). It seems like an effective model to scale, has it been tried? We have a11y experts who train people to be faciliators of a11y issues, so they can diagnose/solve those issues instead of needing experts every time. Things requiring more fine expertise get funneled into the time-constrained a11y team, but smaller issues can use the champions instead helping to free the backlog.

Valerie: How could this work cross-spec? But it is a good idea to propose. ARIA has a similar issue. ARIA and WHATWG are separate even though it is so HTML-related. At what point should new features in WHATWG/CSSWG reach out to ARIA? We are constrained by the platform and assistive technologies.

Dom: We have experts in WHATWG areas which are not editors, whose views might align with editors but the real key (for WHATWG) seems to be having more editors. One thing we are looking at more is clearing defining the criteria for editorship, allowing new people to become editors. Instead of people grinding to the top to become an editor, having a process measure where they are vs where they need to be to become an expert. Having more experts in the room helps more with both intra and inter org needs.

Dan: (?)

Valerie: Individuals who interface with HTML (just one, Scott O'Hara) are on the edge of burnout. We need more people acting as an interface between specs. Can someone motivated about a11y come to us when there are new features?

Andreu: re: at which point do you consider a11y. Something similar in a different area is AsyncContext. It needs integrating it into Web APIs (eg setTimeout): events and most things taking a callback. Sometimes you need to trace through the data flow, and sometimes specs and implementations can differ on that data flow. How can we make sure people working on Web APIs have to care about this? Just having one document isn't enough because how can you know when to check it, and could it cover every case?

Anne: a11y interfacing does not work as well as I thought it did. We try to proactively file issues and tag issues with "a11y" which should trigger some process on the W3C side indicating those issues need to be looked at. We have a GiHub team for a11y which has a number of W3C a11y experts, I try to tag them in issues requiring their attention. There are sometimes we dropped the ball by thinking about a11y but not blocking PRs requiring it. Another past hot topic was if we should define the a11y mapping in the HTML spec itself, which would require more consideration for PRs.

Valerie: I appreciate the effort but it will always been an effort. CSS is more of a problem recently. Having mappings be in WHATWG would be nice but ARIAWG have all the experts (screen reader users, API maintainers, etc). a11y should definitely block HTML features from landing.

Dan: Blocking on time-limited groups isn't great but it should have approval.

Anne: We should change our PR template for certain criteria, checking a11y/i18n needs checked. We already have it for filing MDN issues and others, adding another checkbox doesn't seem terrible.

Brian: Only the spec would get blocked, not implementations, which is also a problem.

Valerie: Not landing in a spec means someone is keeping track of whether an implementation is complete. Editors/champions nag implementations.

Dan: Glad some editors care. Burnout cases (eg ARIA HTML) are sad. Getting bad reviews can make people burnout faster. Getting support is good but what can we do instutionally to not be dragged between several organisations to avoid burnout since we want work like that? This is the precise risk for people not wanting to contribute to HTML not contributing to ARIA(?)

Valerie: I think burnout is happening because there is more work to do than people have time. Overwork is not really supported well financially.

Dan: What should we do as next steps?

sideshowbarker: We could continue this afternoon in my session, since there's a lot of overlap (how to build a new feature in the web platform).

Dan: This sort of cross-spec work is needed to make some features. Everyone here is encouraged to get involved in the groups you want. Becoming a bridge between two groups is very valuable so encourage it, but don't burnout.