13:52:54 RRSAgent has joined #engine-scion 13:52:54 logging to https://www.w3.org/2020/10/29-engine-scion-irc 13:52:57 RRSAgent, make logs Public 13:52:58 Meeting: The Waning Web Platform Engine Diversity 13:53:02 Travis_ has joined #engine-scion 13:54:11 rego has joined #engine-scion 13:55:11 yhirano has joined #engine-scion 13:56:05 wseltzer has joined #engine-scion 13:56:12 rrsagent, pointer? 13:56:12 See https://www.w3.org/2020/10/29-engine-scion-irc#T13-56-12 13:56:50 cwilso has joined #engine-scion 13:57:21 florian_irc has joined #engine-scion 13:57:40 weiler has joined #engine-scion 13:58:23 jsbell has joined #engine-scion 13:58:34 present+ 13:58:38 dsinger has joined #engine-scion 13:58:43 cpn has joined #engine-scion 13:58:49 I'm requested a passcode from zoom. Is that expected? 13:59:03 present+ 13:59:04 2020 13:59:24 oh thanks 13:59:49 present+ Joshua Bell 13:59:55 jeff has joined #engine-scion 13:59:59 smcgruer_[EST] has joined #engine-scion 14:00:03 present+ 14:00:08 present+ Chris_Needham 14:00:21 present+ 14:00:56 Domenic has joined #engine-scion 14:01:06 miriam has joined #engine-scion 14:01:09 vivien has joined #engine-scion 14:01:28 JoshuaLindquist has joined #engine-scion 14:01:36 present+ 14:01:38 smaug has joined #engine-scion 14:01:42 present+ 14:01:47 mjs has joined #engine-scion 14:01:51 rbyers has joined #engine-scion 14:02:02 jyasskin has joined #engine-scion 14:02:06 present+ 14:02:07 kleber has joined #engine-scion 14:02:13 present+ 14:02:17 scribenick: jyasskin 14:02:17 present+ 14:02:19 lgombos_ has joined #engine-scion 14:02:21 present+ 14:02:25 jamesn has joined #engine-scion 14:02:26 present+ 14:02:26 present+ 14:02:29 chair: cwilso 14:02:31 present+ 14:02:34 present+ 14:02:39 present+ 14:02:54 cwilso: Welcome. My pronouns are he/him. I work at Google, manage standards process, serve as AB rep, worked on web browsers since NCSA Mozaic. 14:03:01 present+ 14:03:08 s/Mozaic/Mosaic/ 14:03:08 ... Want to discuss how the standards process should adapt to a world with fewer engines. 14:03:13 michaelchampion has joined #engine-scion 14:03:13 yoav has joined #engine-scion 14:03:20 JohnWilander has joined #engine-scion 14:03:21 present+ 14:03:23 present+ 14:03:27 present+ 14:03:40 ... Process at the W3C depends on multiple interoperable implementations of web features. WGs and CGs have started inserting this into the charter. 14:03:41 hober has joined #engine-scion 14:03:45 present+ 14:03:51 ... How do stakeholders have influence? 14:04:07 gerrit has joined #engine-scion 14:04:21 present+ 14:04:26 ... 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. 14:04:47 present+ Gerrit_Niezen 14:04:52 ... 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. 14:05:00 q? 14:05:07 q+ 14:05:08 ... Don't have a presentation, but expect lots of interesting discussion. 14:05:08 q+ to comment on adoption and testability 14:05:09 eeeps has joined #engine-scion 14:05:18 ack bk 14:05:21 q+ 14:06:22 bkardell: I seem to recall, in the early chaos, Tim thought we should have 2-3 [engines?]. 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? 14:06:23 rachelandrew has joined #engine-scion 14:06:35 fantasai has joined #engine-scion 14:06:42 cwilso: When we started NCSA Mosaic, we used libwww, and then immediately forked it. 14:06:45 garykac has joined #engine-scion 14:06:51 ... Shipped on 3 platforms, with 3 entirely separate implementations. 14:06:52 q+ to comment on bandwidth vs opposition in principle 14:07:02 ... Today, with Web Audio, code is shared across "implementations". 14:07:07 q+ 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 14:07:07 ... which isn't a great thing, but is. 14:07:09 ack jeff 14:07:09 jeff, you wanted to comment on adoption and testability 14:07:18 rtoyg_m2 has joined #engine-scion 14:07:21 Ian has joined #engine-scion 14:07:34 s/[engines?]/implementations 14:07:42 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. 14:08:37 ekr has joined #engine-scion 14:08:41 jensimmons has joined #engine-scion 14:08:48 present+ 14:08:49 sheila has joined #engine-scion 14:08:51 ... 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. 14:08:52 present+ 14:08:59 q? 14:09:05 present+ 14:09:14 igarashi_ has joined #engine-scion 14:09:22 vq? 14:09:23 ... 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. 14:09:25 present+ 14:09:27 present+ 14:09:27 ack mc 14:09:33 ack mi 14:09:33 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 14:09:34 present+ 14:09:36 ... implementer has the bandwidth. It's another if other stakeholders opposer 14:10:01 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. 14:10:08 q+ to respond to Jeff on interop and testability, sufficiently well-defined. 14:10:13 AdrianHB has joined #engine-scion 14:10:17 q+ 14:10:23 q- later 14:10:31 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. 14:10:45 ack mjs 14:10:45 mjs, you wanted to comment on bandwidth vs opposition in principle 14:11:23 q+ 14:11:34 mjs: Might be redundant with michaelchampion. Specific example, with Generic Sensors API, it's opposed by 2 implementers, not just lacking in bandwidth. 14:11:46 q+ on value of specification process for devices & sensors example 14:11:53 ... Do we want to run a standards process that's not blocked on people thinking something is a good idea? 14:11:58 q+ 14:12:05 Indeed when an implmenetor *unships* something (e.g. DAS APIs), that's a very strong negative signal, and clearly has nothing to do with bandwidth 14:12:23 ... 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. 14:12:27 s/implmenetor/implementor 14:12:47 +1 to not putting those two in the same category 14:13:22 ... 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. 14:13:26 q- as mjs just made the point I wanted to add about blurring 14:13:32 q- 14:13:45 q+ re multi-sided interop 14:13:49 ... 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. 14:14:07 q+ 14:14:10 ... Great to document these things, and there's a chance that they eventually become standards, but standards process isn't necessarily the right thing. 14:14:20 rbyers 14:14:25 ack rbyers 14:14:36 +1 mjs 14:14:36 q- later 14:14:37 q+ to ask whether there is something we can do to the specifications to lower barriers to entry? 14:15:29 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? 14:15:45 vq? 14:16:00 q- later 14:16:05 ... 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. 14:16:07 tzviya has joined #engine-scion 14:16:14 ack Domenic 14:16:14 Domenic, you wanted to comment on value of specification process for devices & sensors example 14:16:26 q+ 14:16:31 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 14:16:44 +1 to ekr 14:16:49 rrsagent, pointer 14:16:49 See https://www.w3.org/2020/10/29-engine-scion-irc#T14-16-49 14:17:03 q? 14:17:15 present+ 14:17:18 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 14:17:23 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 14:17:23 developers, other browsers. 14:17:33 Standardising the structure of the feature brings interop. Implementations can still opt to not ship at all 14:17:36 It's not like Torbrowser has their own WebRTC stack. They just turn it off 14:17:38 ... Specifications process is still valuable, and W3C's various venues are a good place to do that. 14:17:52 q+ to +1 Domenic's point about W3C as a place for "documentation" for things that are not ready for REC track 14:17:57 ... Does W3C want to work on specifications or just REC-track standards? 14:17:59 q+ 14:18:00 ack Travis 14:18:12 +1 do Domenic's points 14:18:32 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. 14:18:48 ... Just having a specification doesn't mean you have to implement it, or that it will always be complete. There's no consequence. 14:18:51 +1 to Travis_ 14:18:51 q+ 14:18:53 q+ re. experience contributing to multiple browser engines from "outside" 14:19:20 q+ noamr 14:19:24 q+ re experience contributing to multiple browser engines from "outside" 14:19:26 ... 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. 14:20:08 q+ 14:20:38 ... 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. 14:20:49 ack ws 14:20:49 wseltzer, you wanted to discuss multi-sided interop 14:21:26 +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 14:21:35 +1 to ekr's IRC comments 14:22:05 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?" 14:22:06 ack Ian 14:22:40 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. 14:23:11 q? 14:23:33 ... 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. 14:23:36 ack dsinger 14:23:36 dsinger, you wanted to ask whether there is something we can do to the specifications to lower barriers to entry? 14:24:05 AramZS has joined #engine-scion 14:24:19 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. 14:24:28 CSS has Levels =) 14:24:57 q+ to comment on better distinguishing standards-track, incubation, and single-implementation documentation 14:25:06 ... 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? 14:25:19 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) 14:25:33 +1 to Travis on IRC 14:25:38 [Informational RFCs published through the IETF stream still require IETF consensus. There is an independent submission stream that does not requires IETF consensus.] 14:26:03 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? 14:26:15 q? 14:26:19 q+ to describe Coil's experience as a non-UA vendor in incubating a proposed standard 14:26:20 [and Informational docs can be published in either of those streams] 14:26:24 ... Do the engine owners get a veto because they don't like/don't want to work on/etc particular features? 14:27:02 Judy has joined #engine-scion 14:27:17 ack cw 14:27:17 cwilso, you wanted to respond to Jeff on interop and testability, sufficiently well-defined. 14:27:17 ... 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? 14:27:18 Web MIDI is also a feature that Apple and Mozilla actively object to (for security reasons)! 14:27:19 ack bk 14:27:37 mjs: Mozilla has not taken a standards-position on Web MIDI. 14:27:42 mjs: actually, not true - mozilla does not object 14:27:57 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. 14:28:02 q+ to express anxiety about the state where we require N implementations and there are M engines and Nā‰…M 14:28:06 they have concerns, but we've discussed them, and given them a clear path. 14:28:11 q? 14:28:32 cwilso: I'll clarify this at the mic, but our position about webmidi is not about bandwidth, but rather security 14:28:52 ... 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. 14:28:57 I agree that there have been some proposals for how to address them, not so sure I agree it's a clear path 14:28:58 ack jeff 14:28:58 jeff, you wanted to +1 Domenic's point about W3C as a place for "documentation" for things that are not ready for REC track 14:29:32 We actually have a WebMIDI impl, so it's not about code bandwidth 14:29:53 ekr: and your official position is "under consideration". 14:29:56 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. 14:30:11 q+ 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 14:30:18 cwilso: agreed, I'm just clarifying the reason for that 14:30:55 ... 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. 14:31:00 ekr: fair, and I apologize if I was taken as speaking for Mozilla 14:31:54 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. 14:32:38 vq? 14:32:43 ack ekr 14:32:48 ... 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. 14:33:02 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. 14:33:09 ... Engines aren't generally built as a bunch of replaceable components. Easy to turn things off, not to replace them. 14:34:42 +1 to ekr that status of documents must be clear 14:34:44 q+ to respond to "non-standards document" 14:34:51 ... 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. 14:34:53 +1 to making the status of such document sclear 14:35:06 s/document sclear/documents clear/ 14:35:09 +1000 to making the status of documents clear 14:35:20 +1 14:35:28 rhiaro has joined #engine-scion 14:35:29 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. 14:36:32 ... ? 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. 14:36:34 I disagree that this is clear. 14:37:00 ack hober 14:37:02 ack noam 14:37:02 noamr, you wanted to discuss experience contributing to multiple browser engines from "outside" 14:37:38 slightlyoff has joined #engine-scion 14:37:42 present+ 14:37:51 present+ 14:37:51 noamr: I work independently on several engines and specs. Experience with the 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. 14:38:15 s/Timing/Paint Timing/ 14:38:57 ... 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. 14:38:59 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://wiki.mozilla.org/ExposureGuidelines) try to encourage this, but we're updating them clearer. 14:39:01 ack yoav 14:39:17 q- 14:39:21 vq? 14:39:24 q+ to ask about "independent" 14:39:42 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. 14:40:21 ... 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. 14:40:26 ... Maybe other ways to validate that. 14:40:31 q? 14:40:42 ... Maybe other ways to validate spec legibility and spec quality without full-fledged implementation. 14:42:00 ... 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 14:42:00 interest. 14:42:00 q+ to make Chromium governance a bit less opaque 14:42:10 q- later 14:42:10 q+ 14:42:11 I have made the request to generate https://www.w3.org/2020/10/29-engine-scion-minutes.html fantasai 14:42:16 ack mjs 14:42:16 mjs, you wanted to comment on better distinguishing standards-track, incubation, and single-implementation documentation and to 14:42:17 ... Similar on opposition, everyone should have a voice, but nobody should be able to veto. 14:42:17 q+ re follow-up 14:42:58 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. 14:43:08 .... In that they just wanted to ship. 14:43:27 strong, strong +1 to that, ekr. 14:43:35 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 14:43:35 styling, it's hard to tell the difference. 14:43:38 +1 14:43:43 I have made the request to generate https://www.w3.org/2020/10/29-engine-scion-minutes.html Ian 14:43:44 +1 as well 14:43:48 +1 14:44:07 ... 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. 14:44:12 https://wicg.github.io/webusb/ 14:44:16 ... Looking at WebUSB and Web Share as examples. 14:44:23 https://w3c.github.io/web-share/ 14:44:44 ... [describes visual appearance] Would be very difficult for an outsider to tell the difference. 14:44:58 q+ to talk about how to distinguish 14:45:09 FWIW, this is no better in IETF. For instance, we recently had confusion about 6525bis and draft-west-cookie-incrementalism 14:45:16 FWIW, this is no better in IETF. For instance, we recently had confusion about 6525bis and draft-west-cookie-incrementalism (at Mozilla) 14:45:26 vq? 14:45:38 q- later 14:45:43 mjs: Someone would especially not be able to distinguish between CG documents that have differing amounts of multi-implementer support. 14:45:57 [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.] 14:46:00 ack fantasai 14:46:00 fantasai, you wanted to react to mjs to comment on usage of EDs 14:46:04 ... Important for lots of groups to be able to tell the difference. e.g. MDN 14:46:34 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" 14:46:42 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. 14:47:18 -> https://github.com/w3c/tr-design tr-design repo is a good place to put issues on styling 14:47:26 fantasai: To distinguish between EDs vs CG-Reports, we did update tooling. The latest thoughts of a working group can be published as WDs. EDs should eventually stop being things people reference. 14:47:32 <3 Echidna 14:47:57 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://github.com/WICG/admin/issues/102 14:48:00 fantasai: Everything can be published on w3.org/TR 14:48:13 ack adrian 14:48:13 AdrianHB, you wanted to describe Coil's experience as a non-UA vendor in incubating a proposed standard 14:48:28 zakim, close the queue 14:48:28 ok, cwilso, the speaker queue is closed 14:48:43 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. 14:48:43 s/tooling/tooling *and* the W3C Process to make it possible to keep every spec up-to-date on TR/ 14:48:52 vq? 14:49:11 Normal people don't distinguish between what's on TR/ vs. not. They find specs via Google search. 14:49:11 q+ 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) 14:49:20 zakim, open the queue 14:49:20 ok, cwilso, the speaker queue is open 14:49:22 (Adrian is speaking about Web Monetization incubation I believe) 14:49:33 q+ 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) 14:49:35 q+ rbyers 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) 14:49:44 +1 Travis 14:49:47 zakim, close the queue 14:49:47 ok, cwilso, the speaker queue is closed 14:49:51 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. 14:49:59 [I'm queued to consider where we might continue these good conversations] 14:50:00 s/Everything can be published on w3.org/All of WD, CR, and REC can be updated with the WG's latest thinking directly on w3.org/ 14:50:06 vq? 14:50:43 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. 14:50:55 ... 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. 14:51:07 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. 14:51:24 I'll also note that material in EDs is not protected by the Patent Policy, only material on TR. 14:51:45 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. 14:51:54 cwilso: 1 minute per speaker! 14:51:54 ack tantek 14:51:54 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 14:51:57 ... with browser requirements (e.g. Web Annotations), or barely implemented specs ("data models") that get lobbied into legislation attempts 14:52:23 vq? 14:53:02 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. 14:53:04 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. 14:53:38 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. 14:54:04 I have made the request to generate https://www.w3.org/2020/10/29-engine-scion-minutes.html fantasai 14:54:11 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. 14:54:22 vq? 14:54:34 tantek: Presentation is an issue. W3C logo is a problem. 0-engine specs. Specs used for lobbying. 14:54:52 tantek: DID spec, AB 2004 14:55:10 DID data model REC from last Nov IIRC 14:55:45 s/All of WD/As of Process 2020 all of WD/ 14:56:06 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. 14:56:21 ... How do we make it clear? 14:56:23 q? 14:56:26 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. 14:56:26 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. 14:56:38 tuukkat has joined #engine-scion 14:56:44 ack cwilso 14:56:44 cwilso, you wanted to respond to "non-standards document" 14:56:49 ack sli 14:56:49 slightlyoff, you wanted to make Chromium governance a bit less opaque 14:57:41 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 14:57:53 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) 14:57:54 q- 14:57:56 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 14:57:56 designed right. 14:58:03 ack jen 14:58:43 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. 14:58:59 +1 to jensimmons 14:59:00 ... Help developers understand that it's implemented in one browser and hasn't gone through all that review. 14:59:06 +1 to Domenic. Chromium has a process for citing implementor support in launch process (https://docs.google.com/document/d/1xkHRXnFS8GDqZi7E0SSbR3a7CZsGScdxPUWBsNgo-oo/edit). This feels like the wrong place - the spec should be the canonical source for such links to implementor positions. 14:59:18 why do non-Chromium browsers allow features to ship that don't see a public process like Blinks? 14:59:19 ... This causes a lot of confusion, and we could make it a lot clearer. 14:59:26 ack jyasskin 14:59:26 jyasskin, you wanted to talk about how to distinguish 14:59:28 (to @jensimmons point) 14:59:49 jyasskin: I'd like to see that section on top of each spec, that shows caniuse style info 15:00:00 ack ws 15:00:00 wseltzer, you wanted to discuss follow-up 15:00:04 Thanks all, really appreciate this session. 15:00:08 Wonder if engines could also help by advising to web developers when an API is only implemented in their engine...? 15:00:12 Have to run to another meeting. 15:00:12 s/caniuse style info/implementer spec position information/ 15:00:28 vq? 15:00:45 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? 15:00:45 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) 15:00:48 ack rbyers 15:00:48 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 15:00:51 ... 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 15:00:51 ... independently in sites like chromestatus.com and Edge platform status) 15:01:15 https://github.com/w3c/tr-design 15:01:21 cwilso: Thanks everyone. Some clear followup, especially around delineating specs vs standards. Will be pinging people. 15:01:22 https://github.com/w3c/w3process 15:01:47 And I forgot to say: Jeffrey, thank you so much for the excellent scribing!! 15:02:01 +1 nice scribing jyasskin 15:02:12 I have made the request to generate https://www.w3.org/2020/10/29-engine-scion-minutes.html Ian 15:02:16 rrsagent, draft minutes v2 15:02:16 I have made the request to generate https://www.w3.org/2020/10/29-engine-scion-minutes.html wseltzer 15:02:19 s/shows caniuse style info/shows caniuse style info for shipped things, and has implementers pick from an enum of opinions for other things./ 15:02:26 rrsagent, draft minutes v2 --style=old 15:02:26 I'm logging. I don't understand 'draft minutes v2 --style=old', wseltzer. Try /msg RRSAgent help 15:03:40 rrsagent, draft minutes v2 oldstyle 15:03:40 I'm logging. I don't understand 'draft minutes v2 oldstyle', wseltzer. Try /msg RRSAgent help 15:03:48 rrsagent, draft minutes 15:03:48 I have made the request to generate https://www.w3.org/2020/10/29-engine-scion-minutes.html wseltzer 15:04:59 s/2020// 15:05:17 s/I'm requested a passcode from zoom. Is that expected?// 15:05:23 s/oh thanks// 15:05:43 rrsagent, draft minutes 15:05:43 I have made the request to generate https://www.w3.org/2020/10/29-engine-scion-minutes.html wseltzer 15:09:43 s/vq?//G 15:09:45 rrsagent, draft minutes 15:09:45 I have made the request to generate https://www.w3.org/2020/10/29-engine-scion-minutes.html wseltzer