Meeting minutes
<weiler> 2020
cwilso: Welcome. My pronouns are he/him. I work at Google, manage standards process, serve as AB rep, worked on web browsers since NCSA Mosaic.
… Want to discuss how the standards process should adapt to a world with fewer engines.
… Process at the W3C depends on multiple interoperable implementations of web features. WGs and CGs have started inserting this into the charter.
… How do stakeholders have influence?
… Several features have gotten stopped in the standards process because 2/3 of the engines don't have the bandwidth to work on them, even though other stakeholders think the features are important.
… Devices & Sensors, especially. But we also don't want to change the rules so a single stakeholder can define and standardize a feature without any other input.
… Don't have a presentation, but expect lots of interesting discussion.
bkardell: I seem to recall, in the early chaos, Tim thought we should have 2-3 implementations. Now we have 3. What needs to change there. Historically, there were some shared resources, and there are still shared resources. How do we apply that?
cwilso: When we started NCSA Mosaic, we used libwww, and then immediately forked it.
… Shipped on 3 platforms, with 3 entirely separate implementations.
… Today, with Web Audio, code is shared across "implementations".
… which isn't a great thing, but is.
<Zakim> jeff, you wanted to comment on adoption and testability
jeff: As a math problem, if we're down to 3 engines, and we might drop down to 2 or even 1. And with 1 we couldn't ship any standards with multi-implementation support.
… Thinking of reasons. Adoption and testability. Adoption: if there's a single implementation of something, it's hard to call it a standard. Want to have a process that recognizes things implemented by multiples. And for testability: want the standard to be clear enough that if someone new is implementing from the standard, it's sufficiently clear that it's possible to reimplement from there.
… Instead of thinking what to do with a waning number of engines, look at the original motivations for requiring multi-implementation support and figure out how to get them. Might be an easier problem.
<Zakim> michaelchampion, you wanted to ask about consensus across "stakeholders" and "implementers". It's one thing for multiple stakeholders to want a feature and only one engine implementer has the bandwidth. It's another if other stakeholders opposer
michaelchampion: Want to distinguish between multiple implementers but some don't have bandwidth to do features they want, from small number of implementers, some of whom actually oppose the feature for the web platform.
michaelchampion: Don't want a situation where the implementer of the dominant browser can force things into standards over objections. Want to still seek consensus.
<Zakim> mjs, you wanted to comment on bandwidth vs opposition in principle
mjs: Might be redundant with michaelchampion. Specific example, with Generic Sensors API, it's opposed by 2 implementers, not just lacking in bandwidth.
… Do we want to run a standards process that's not blocked on people thinking something is a good idea?
<tantek> Indeed when an implementor *unships* something (e.g. DAS APIs), that's a very strong negative signal, and clearly has nothing to do with bandwidth
mjs: We have a pool of stuff that hasn't reached multi-implementer interest strong enough to go into a more formal standards track. Some are in the bandwidth category, but others have been actively rejected.
<fantasai> +1 to not putting those two in the same category
mjs: Important not to put those things in the same bucket. Boundaries also blur. Sometimes there are lots of proposals in one area. NativeIO would bring us up to 4 different filesystem APIs, most of which come from one place. Why are there so many? Lack of bandwidth to review all of them might blend into disagreement that there should be so many.
… Want to agree with parts of what jeff said. The purpose of a standards process is interoperability. If you have 1 product and are writing how it works, it's documentation not a standard.
… Great to document these things, and there's a chance that they eventually become standards, but standards process isn't necessarily the right thing.
<cwilso> rbyers
<tantek> +1 mjs
rbyers: This is an awesome group of people. Re adoption, and want to separate out diversity in engines from diversity of opinion. To what extent do different browsers built on a common engine feel empowered to have different opinions from the primary maintainer of the engine?
… It's critical that different browser products are empowered to have their own opinions, e.g. on privacy, whether to expose Generic Sensors. Want to hear more from people who build more on top of these shared codebases.
<Zakim> Domenic, you wanted to comment on value of specification process for devices & sensors example
<ekr> I would like to observe that there's a big difference between the choice to ship or not to ship a feature and the choice of the structure of the feature
<AdrianHB> +1 to ekr
<ekr> So, for instance, if Fx implements a big feature in a certain way, it's not really plausible that Tor will implement it significantly differentlt
Domenic: Building on mjs and rbyers' points. If something's opposed by 2/3 engines. Will only get 1 independent implementation. But there's still a lot of value in the specification process and the w3c venue for documentation. Want to lay out a path for others to implement eventually, write web platform tests. Collaborate with IPR concerns handled. And wide review, with multistakeholder discussion, beyond just engines. TAG, web
… developers, other browsers..
<AdrianHB> Standardising the structure of the feature brings interop. Implementations can still opt to not ship at all
<ekr> It's not like Torbrowser has their own WebRTC stack. They just turn it off
Domenic: Specifications process is still valuable, and W3C's various venues are a good place to do that.
… Does W3C want to work on specifications or just REC-track standards?
<Ian> +1 do Domenic's points
Travis_: I've been working with standards for a while at Microsoft. When new people from industry start working on standards, they're confused because they look at the spec, and wonder what the implications are for an implementation that doesn't meet the standard.
… Just having a specification doesn't mean you have to implement it, or that it will always be complete. There's no consequence.
<tzviya> +1 to Travis_
Travis_: In different standards organizations, they handle this differently. Certification programs to try to ensure implementations are conformant. Marketing angle. The W3C hasn't historically invested in this, perhaps for good reason.
… Re rbyers, Edge works inside the Chromium project, uses that as our engine. The ability to take a different opinion on a standard is something we find very important. Not just from the ideal "it's possible we could diverge" standpoint, but also we've practically made several changes. Depending on how the decision process evolves, we still want to count and have a voice.
<Zakim> wseltzer, you wanted to discuss multi-sided interop
<AdrianHB> +1 to Travis. Key is the ability for different implementors using the same engine to be able to take different decisions about which APIs to implement and how to surface features to users and developers
<mjs> +1 to ekr's IRC comments
wseltzer: Thanks for gathering ideas. Re Domenic's point on specification. A lot of the things we're specifying are things with 2+ sides. Browser engine interoperating with things web developers are building. A specification helps in that sort of interop too. I agree it's valuable to have documentation and review and a place to mark "what are the levels of implementation and support?"
Ian: In the payments space there are even more sides. Banks, payment service providers, merchants. Getting agreement is even more challenging, and having a place like the W3C is valuable.
… For browser vendors, is there a big distinction between the underlying engine code and what you deploy? Does the shipping browser have enough proprietary layers on top that it shoudl be considered a separate browser, or is it mostly the same? e.g. in WebAuthn there's more underlying codebase and the full platform behavior. CSS rounded corners might be less difference.
<Zakim> dsinger, you wanted to ask whether there is something we can do to the specifications to lower barriers to entry?
dsinger: We've constructed a world where shipping an engine means you've implemented the whole of a LOT of things. Could we break this down so there's less of a mountain to climb to enter the market. Answer is probably no or we'd have done it a long time ago.
<fantasai> CSS has Levels =)
dsinger: Back to Domenic, we've toyed with the idea of "Registered Disclosure" where participants publish proprietary practices. IETF has Informational track, where you can publish without consensus. Overdue for W3C to have such a track?
<Travis_> It's more a matter of building an engine that will actually work with the body of code that is deployed in the wild (web)
<AdrianHB> +1 to Travis on IRC
<weiler> [Informational RFCs published through the IETF stream still require IETF consensus. There is an independent submission stream that does not requires IETF consensus.]
cwilso: The mountain of stuff that we've created, and the open source engines especially Chromium. People who build on Chromium don't want to look at the mountain of stuff but want to look at specific features. What priorities do those people get in the standards process if they're not writing the engine itself?
<weiler> [and Informational docs can be published in either of those streams]
cwilso: Do the engine owners get a veto because they don't like/don't want to work on/etc particular features?
<Zakim> cwilso, you wanted to respond to Jeff on interop and testability, sufficiently well-defined.
cwilso: There are plenty of places where there's not enough will to dig in even though there's an industry that wants something. e.g. Web MIDI, where an industry is waiting. If other engines don't want to implement, that's fine, but what do we do then? Don't want to offend people by shipping features, but how do we push on the web platform to move it forward?
<mjs> Web MIDI is also a feature that Apple and Mozilla actively object to (for security reasons)!
<Domenic> mjs: Mozilla has not taken a standards-position on Web MIDI.
<cwilso> mjs: actually, not true - mozilla does not object
bkardell: Want to tie Chris, Rick, and mjs' comments. cwilso asked "How do we (Igalia) feel?" as contributors to all engines and makers of 2 WebKit forks.
<cwilso> they have concerns, but we've discussed them, and given them a clear path.
<ekr> cwilso: I'll clarify this at the mic, but our position about webmidi is not about bandwidth, but rather security
bkardell: Blurry line between priority and disagreement. We feel the ability to disagree with priority, and respond by advocating and building consensus. Did this with MathML in Chromium, and doing it with things in WebKit. Things are important to us but aren't immediately on Apple's list. As far as big things where we know about disagreement because of "What is the Web?", I don't think we've had any of those.
<ekr> I agree that there have been some proposals for how to address them, not so sure I agree it's a clear path
<Zakim> jeff, you wanted to +1 Domenic's point about W3C as a place for "documentation" for things that are not ready for REC track
<ekr> We actually have a WebMIDI impl, so it's not about code bandwidth
<cwilso> ekr: and your official position is "under consideration".
jeff: Domenic asked if there's a home at W3C for things that only 1 engine likes, since W3C has a lot of healthy process. Clearly answer is yes. We've created Community Groups for incubation, which is a wide term. >10k people signed up for CGs. Big part of W3C.
<ekr> cwilso: agreed, I'm just clarifying the reason for that
jeff: Raises another question that might be out of scope here. Some things that go into the rigors of the W3C Process, like Horizontal Review, aren't required of all CGs. With 10 years of experience, do we need to provide some structure? Maybe optional structure. So specs that are appropriately in CGs for a long time have some process. Process CG is looking at this.
<cwilso> ekr: fair, and I apologize if I was taken as speaking for Mozilla
ekr: 3 points: 1. We've marked WebMIDI as under consideration, but we still have security concerns. We actually had an engineer implement it, but we're not sure we're ready to ship it.
… 2. This is framed as if decisions are binary. e.g. Tor turns off WebRTC. But the question of broad industry input isn't just about turning things on or off, but also about the shape. Can someone downstream of the main engine actually change the shape of a feature? Not very much, or at least it's a lot of work and engagement with the engine maintainers.
<mjs> FWIW I don't think Apple would have a problem with Web MIDI if the security issues could be adequately resolved. As it is, we would not ship it even if someone else contributed an implmentation to WebKit.
ekr: Engines aren't generally built as a bunch of replaceable components. Easy to turn things off, not to replace them.
<jeff> +1 to ekr that status of documents must be clear
ekr: 3. Point about a home for non-REC documents. I think it's valuable for those documents to be published and clear IPR statements. Experience has shown that people can't distinguish those documents from ones that have standard status. Constantly having to explain to people at Mozilla that various documents at IETF and W3C are just people's opinions, and not really a standard or something we'll ship.
<fantasai> +1 to making the status of such documents clear
<mjs> +1000 to making the status of documents clear
<bkardell> +1
hober: Domenic said that if there's no appetite at the W3C, have to take them elsewhere. Where is that? WHATWG is even less friendly to single-engine features.
… ? said TAG review was valuable. We'll review just about anything. We have a firehose, mostly from Blink engineers working on some proposal. Very unclear the status of these things. Do they institutional backing? One person's side project? Are they going anywhere? We care how to prioritize the firehose. The clearest signal for prioritization is around multi-engine interest.
<cwilso> I disagree that this is clear.
<Zakim> noamr, you wanted to discuss experience contributing to multiple browser engines from "outside"
noamr: I work independently on several engines and specs. Experience with the Paint Timing (?) API was that getting Mozilla and Apple want to implement it significantly improved the quality of the spec. It's a blessing to have the feedback. If we could have "all 3" as the requirement, it would be even better. Like code review.
… For newcomers, I'm a contributor without being a part of a big company. Same difficulties as any other open source project. Have to prod a whole bunch of people you don't know. Lots of dependencies. HTML takes ages for something to go in. APIs go much faster. HAve to wait for reviewers who are packed with other things. Some specs take a long time. For people not inside the browser companies, this is difficult and not transparent.
<ekr> To clarify what I was saying about shipping policy, we generally attempt not to ship things that are just individual proposals, either IETF individual I-Ds or CG stuff. When we get to the point where we think it's time to ship, we would like to get it into some standards forum. The Exposure Guidelines (https://
yoav: Connected to noamr's point about being an external contributor. I used to be one. In some cases, multi-implementer actually shipping features meant that a single person had implemented the feature several times in several engines.
… Talked about the need for multiple implementers implementing. Testability: Having the feature implemented in multiple places doesn't need to mean the spec is legible, e.g. if one person implemented multiple times. It does mean that the feature aligns with multiple implementation architectures.
… Maybe other ways to validate that.
… Maybe other ways to validate spec legibility and spec quality without full-fledged implementation.
… Re adoption: On ensuring this is something the web needs, if we over-index on implementers, we leave other stakeholders behind. EKR's right that it's hard to replace the underlying infrastructure as an external browser vendor. But it's easy to change/patch/reimplement features on top of existing infrastructure, even if it's turned off by the other project's owner. Adoption has more dimensions than end-to-end implementation
… interest.
<Zakim> mjs, you wanted to comment on better distinguishing standards-track, incubation, and single-implementation documentation and to
yoav: Similar on opposition, everyone should have a voice, but nobody should be able to veto.
<ekr> One thing I wish I had said but is not worth getting into the queue for, but I think that most of the specs I have been involved in have been significantly improved by multi-vendor input, even though the original proponents may have found it annoying at the time.
<ekr> .... In that they just wanted to ship.
<cwilso> strong, strong +1 to that, ekr.
mjs: Wanted to comment on ... have a bunch of documents that have different status. We have things on the standards track, mostly produced by WGs, although there's also CGs with a direct pipe to WGs. Like WebAssembly. Incubation documents that are getting ready for standards track and will probably get there. And also thinsg that will likely remain single-implementer. Despite the effort to make these documents distinguishable with
… styling, it's hard to tell the difference.
<tzviya> +1
<yoav> +1 as well
<miriam> +1
mjs: Would benefit from more explicit labeling. Looking at a WICG draft, it has all the official-looking W3C logos, and then "Unofficial Draft" styling in the background.
<mjs> https://
mjs: Looking at WebUSB and Web Share as examples.
<mjs> https://
mjs: [describes visual appearance] Would be very difficult for an outsider to tell the difference.
<ekr> FWIW, this is no better in IETF. For instance, we recently had confusion about 6525bis and draft-west-cookie-incrementalism
<ekr> FWIW, this is no better in IETF. For instance, we recently had confusion about 6525bis and draft-west-cookie-incrementalism (at Mozilla)
mjs: Someone would especially not be able to distinguish between CG documents that have differing amounts of multi-implementer support.
<jeff> [mjs, Thanks for raising the issue of W3C docs needing clearer distinctions. Recently, PLH took an action (based on a discussion in ac-forum) to improve the situation. We'll get your comments to him (he is currently at a different breakout), and I also encourage other folks to send him suggestions.]
<Zakim> fantasai, you wanted to react to mjs to comment on usage of EDs
mjs: Important for lots of groups to be able to tell the difference. e.g. MDN
<ekr> I think this point about prognosis is quite important: there's a big difference between "this is a pre-standard draft that has a fair amount of consensus" and "this is an individual document that doesn't have any real standards status"
fantasai: ED styling: To the extent that a document has the same Status, we can't create styling difference. Need different statuses for CG Reports with different tracks.
<wseltzer> tr-design repo is a good place to put issues on styling
fantasai: To distinguish between EDs vs CG-Reports, we did update tooling *and* the W3C Process to make it possible to keep every spec up-to-date on TR. The latest thoughts of a working group can be published as WDs. EDs should eventually stop being things people reference.
<3 Echidna
<hober> I have filed WICG/admin issues re: increasing the styling difference, but not much has happened, due to opposition, primarily from one vendor. e.g. https://
fantasai: As of Process 2020 all of WD, CR, and REC can be updated with the WG's latest thinking directly on w3.org/TR
<Zakim> AdrianHB, you wanted to describe Coil's experience as a non-UA vendor in incubating a proposed standard
<Domenic> fantasai: two problems with that. As long as EDs exist separate from /TR, then Chromium (and WHATWG) will prefer referencing EDs. And even if you eliminate EDs so only /TR exists, the /TR namespace will be a mismash of untrustworthy out of date stuff; the namespace is tainted.
<Travis_> Normal people don't distinguish between what's on TR/ vs. not. They find specs via Google search.
<Ian> (Adrian is speaking about Web Monetization incubation I believe)
<tantek> +1 Travis
AdrianHB: As a non-vendor, we see a spectrum of options. Can roll out your own browser. Pay someone to add it, but you still depend on existing implementers to accept and ship it. Easiest is to roll out extensions. That's what we had to do to incubate our proposed standard. All of these have big hurdles. Financial to hire people. Rolling out a browser is very hard.
<wseltzer> [I'm queued to consider where we might continue these good conversations]
<mjs> We (Apple, and the WebKit project generally) often use EDs vs WDs as an implementation reference (depending on process of the relevant WG). In using an ED example, I didn't necessarily mean to highlight that distinction.
AdrianHB: Anticipating tantek, it's important to us that, even though we could roll out an extension, it's important that it's seen as potentially something that could become a standard. We don't want to do that to trick or fool anybody. We put a big disclaimer at the top of the spec that it's not standards track, but it's what we hope it will look like if it gets to the standards track.
<fantasai> Domenic, at the point that all EDs are reflected on TR in a way that's not out-of-date, TR will be as useful as EDs. Yes, there's a lot of random not-updated stuff on TR, but that's true of EDs as well. You have to pick out the relevant specs.
<fantasai> I'll also note that material in EDs is not protected by the Patent Policy, only material on TR.
AdrianHB: Happy to provide more detail offline. We've done as much as anyone could be expected (and don't know whether it's succeeded or failed) as a non-browser to bring something to the platform.
cwilso: 1 minute per speaker!
<Zakim> tantek, you wanted to warn about openwashing/standardswashing, e.g. using W3C to publish single-engine specs (misleading the industry about interop), or worse, zero-engine specs with browser requirements (e.g. Web Annotations), or barely implemented specs ("data models") that get lobbied into legislation attempts
tantek: 3 points: 1. Want to avoid "standards-washing", all the criticism of presentation of docs is right. Once you put a W3C logo on reports, you make it impossible for layfolks to distinguish standards vs not. Web conferences have pitches.
<mjs> jyasskin, somethings things are giving the impression that they potentially could become a standard, but that's misleading in their specific case. Furthermore, some people even get the impression that they _are_ a standard, even developer relations folks from browser engines are sometimes confused about this.
tantek: 2. There are 0-engine specs out of the W3C that are even more problematic. Web Annotations placed browser requirements in the spec without any browsers commit to it.
tantek: Are W3C RECs that are barely-baked. That have been used in California to support lobbying and legislation. I had to debunk one of these.
tantek: Presentation is an issue. W3C logo is a problem. 0-engine specs. Specs used for lobbying.
tantek: DID spec, AB 2004
<tantek> DID data model REC from last Nov IIRC
cwilso: labeling of specs: Things are specs. There's a goal of cross-implementaion support. Problem that it's a pipeline, and people want to get in the pipeline. Lots of things have W3C logos. What should it say instead? We have 3/4 of WICG chairs here, and it's a consistent question, and we keep trying to make it more obvious.
… How do we make it clear?
<ekr> It seems like it would be nice to have some terminology: spec (anything that describes a protocol/platform feature), official spec (e.g., it's been adopted in a WG), standard.
<Domenic> We should address the problem head on: it's not about logos or how many DRAFTs there are. There should be links to engine and other stakeholders' standards positions, and wpt.fyi pass rate #s, in the spec headers.
<Zakim> cwilso, you wanted to respond to "non-standards document"
<Zakim> slightlyoff, you wanted to make Chromium governance a bit less opaque
<jensimmons> ideas being drafted up should not have visual styling that looks like a standards-group discussed spec. We can ship another theme in bikeshed, and require people to use it until the doc is futher along
<dsinger> I'll type my comment. "Independent" asks multiple questions and we have only looked at one. Is there multi-vendor support? is the spec. clear enough to be independently interoperably implemented? and the hard one – is the spec. specific or favoring an architecture — at what point is a fork an independent basis for implementation? (and unanswerable question again, I think)
slightlyoff: To hober's point, the TAG gets a great deal of "business" from the Blink process, with the intention that the TAG can affect the work while it's still malleable. Hope for the TAG's mode of work, and the Blink process, is that we make Blink folks talk to people with other perspectives, and keep design malleable early on so they can take feedback. We care less about whether another browser likes a feature than whether it's
… designed right.
jensimmons: From the point of view of authors. Netscape and IE3 were a nightmare because of a lack of interoperability. Developers assume that when things land in a browser it went through a process where all the vendors agreed. Developers don't realize the actual dynamics of what's going on.
<tzviya> +1 to jensimmons
jensimmons: Help developers understand that it's implemented in one browser and hasn't gone through all that review.
<rbyers> +1 to Domenic. Chromium has a process for citing implementor support in launch process (https://
<slightlyoff> why do non-Chromium browsers allow features to ship that don't see a public process like Blinks?
jensimmons: This causes a lot of confusion, and we could make it a lot clearer.
<Zakim> jyasskin, you wanted to talk about how to distinguish
<slightlyoff> (to @jensimmons point)
<cwilso> jyasskin: I'd like to see that section on top of each spec, that shows implementer spec position information
<Zakim> wseltzer, you wanted to discuss follow-up
<tantek> Thanks all, really appreciate this session.
<Travis_> Wonder if engines could also help by advising to web developers when an API is only implemented in their engine...?
<tantek> Have to run to another meeting.
wseltzer: Great conversation. Want to continue the conversation. Process-related questions might come up in Process CG that dsinger chairs. TR-Design github repository can take styling comments. Is there a virtual workshop that could help?
<AdrianHB> Want to note that there are specs that are being drafted INSIDE WGs that are also only implemented by a single vendor (i.e. not just limited to CGs so the work is not just to re-style CG reports)
<Zakim> rbyers, you wanted to propose a standard format for documenting engine & browser support levels inside of specs (rather than trying to track independently in sites like chromestatus.com and Edge platform status) and to propose a standard format for documenting engine & browser support levels inside of specs (rather than trying to track independently in sites like chromestatus.com and Edge platform status)
<fantasai> https://
cwilso: Thanks everyone. Some clear followup, especially around delineating specs vs standards. Will be pinging people.
<fantasai> https://
<cwilso> And I forgot to say: Jeffrey, thank you so much for the excellent scribing!!
<Travis_> +1 nice scribing jyasskin
<jyasskin> s/shows caniuse style info/shows caniuse style info for shipped things, and has implementers pick from an enum of opinions for other things./
<bkardell_> if anyone is still here (and he hasn't already mentioned it since I lost the history) mike champion has shared https://github.com/WebStandardsFuture/browser-engine-diversity to continue this