Igalia's Brian Kardell and Eric Meyer chat with Google's Rick Byers about Blink's Principles of Web Compatibility and willingness to change and even unship features.
Eric Meyer: Hello, and welcome to Igalia Chats. I am Eric Meyer. I'm a developer advocate at Igalia.
Brian Kardell: I am Brian Kardell. I am also a developer advocate at Igalia. And today we are joined by Rick Byers. Hi, Rick.
Rick Byers: Hi guys. I'm Rick. I'm a longtime engineer on the Chrome team.
Brian Kardell: And also, you have a distinction of being our most invited guest. This is, I think, your fourth visit, so congratulations.
Rick Byers: Thank you. I'm very honored.
Brian Kardell: Yeah, you're always a good guest.
Eric Meyer: One more, and you get a free guest appearance-
Brian Kardell: Free Igalia tote bag.
Rick Byers: Awesome.
Brian Kardell: I don't know if you recall a few episodes ago, Eric, we had this mail-in episode and Kent Dodds asked, 'If you could break any web feature, which one would it be?'
Eric Meyer: Yeah, we talked about that, and I took the position that you should never break a web feature, basically. I mean, I continue to make, but I am sure in that discussion made a big deal out of the web should be compatible both forwards and backwards in time. I should be able to load up the very first web page, which I can, and the very first web browser should be able to load up pages that are made today and at least get something. And then you afterward pointed out to me there's this list of 100 things that Chrome has unshipped. It has-
Brian Kardell: Over 200.
Eric Meyer: Oh, excuse me, over 200, a triple-digit number of things that have been 'broken.' Broken I'm going to put in air quotes here, because hopefully we can get more details from Rick, but not all of them were necessarily broken per se, but they were unshipped. They had been shipped and then they were removed, so they were unshipped. So Rick, what does unshipping mean exactly from your perspective?
Rick Byers: Yeah, I would say there's a continuum, and we tend to think about it as breaking changes. Unshipping is one type of breaking change, but it tends to be a lot more nuanced than that. It can be everything from, 'Hey, we unshipped Flash.' That was a huge breaking change, to sometimes we make little tiny bug fixes that we don't even necessarily consider a breaking change, but they change the behavior of the engine in some way that causes a significant breakage for users. I mean, in extreme cases, sometimes in past lives I've worked on platforms where we just sped something up. When I was at Microsoft, we made an improvement to .NET where we just improved performance and it exposed a latent race condition that meant a whole bunch of executives could no longer read their email due to a bug. And that's technically a breaking change, but there's a big continuum there. And so, we tried to draw a line in the Chromium process where we say, 'Breaking changes that are expected to have some impact or reasonably predicted have some impact on web developers or something we need to go through a pretty careful process to evaluate and consider the trade-offs around.'
Eric Meyer: And how do you evaluate that sort of thing?
Rick Byers: Yeah, it's tricky. We've developed a pattern. There's this document that I think started a bunch of this conversation that I wrote many years ago called the Blank Principles of Web Compatibility. And we try to just list out a bunch of different properties that we look for when evaluating both the risk and the benefit of a breaking change. The first big class of properties is just minimizing the end-user impact, and we go through all sorts of signals we use to try to evaluate what's the end-user impact of this change. The simplest one is in Chromium for Chrome in particular, we have these use counters that just say, 'What fraction of page loads is triggering this behavior?' That's the first heuristic we use. And you might be surprised, and if we see this behavior is used on 0.001% of page loads, we say, 'Oh crap, that's a lot. That's scary.' Because even if it's just 0.001%, that's still potentially somebody being broken every few minutes or something in the world just because so many web pages are loaded.
Eric Meyer: Okay. Yeah, I don't know what 0.001% is. How many, is that millions of pages? Hundreds of thousands of pages?
Rick Byers: I think I wrote in this document, I mean, let's see, I wrote this document back in 2017, but I wrote here that around 770 billion web pages are viewed in Chrome every month. So, you can multiply 770 billion by 0.001%. But yeah, it's tens of millions at least of web pages every month. That's the first general category is we try to evaluate the impact on the users, but that's just, it's really common to over index on that one number. Because it's a simple easy number to get, but it often doesn't tell the whole story. Sometimes there's one great example where we had a bunch of these legacy constants on the event object. I think there were some quirk in WebKit, they were never standardized. And somebody said, 'What are these, these seem useless? Why is anybody using these for anything?' And our use counter said they were used all over the place. And we went and found some examples of where they were used, and it was just generic code that said, for all properties on event copy into this log object, or something like that. And so we said, 'Oh, just because the property is red doesn't mean it's actually being used.' That was an example where we had to decide our use counters were basically useless. And instead, we did some other analysis and we tried to do some searching of the HP archive to say, 'When we see these properties used, are they always used in this silly pattern that's just kind of copying them from one place to another? Do we see the actual property names in JavaScript anywhere?' And that was one where we decided, 'We didn't have a lot of data on end user breakage, but we had this intuition that this really shouldn't be impacting any websites.' And that was one where we took the risk to just delete these, and being prepared to respond, delete them, and then see what happens with our beta channel users for example. And that was one where the other anecdotal evidence we had that is often really useful, is we ask people from Firefox for example, 'Hey, Firefox doesn't have these, do you have any bugs in Firefox due to websites not having this API? ' And I think in that case, there was no evidence of there ever being a site compat issue due to these APIs. So we decided that was enough evidence to take the risk of trying to remove them. And sure enough, we deleted them and we never heard a single complaint. That was a success, despite a very high use counter. But there's a whole other set of other properties you asked and then we could dive into any of these, but I said there's minimizing end user impact and there's various ways we try to evaluate that. There's maximizing the user experience. So this is where we get to security and privacy. If we're improving security and privacy in some ways, then that tilts the scale in terms of benefit. There's performance. Sometimes we make breaking changes because we make pages load a lot faster, and that can be contentious. There's one great example where there was this intervention only for users on 2G networks where we found that if we just refused to load third-party scripts, using blocking document.write on really slow networks. Yes, that was a breaking change, but it meant that we had 25% more page loads that actually finished. So what that told us was things were so slow in those cases that users were giving up on the web page. Well, so in some sense we were trading one type of breakage for another type. We made those web pages a lot faster such that users could use them, but we made a breaking change based on performance, which is arguably debatable. And then there's other categories as well. Big one is minimizing web developer impact. We want to go through a lot of effort to say, 'If we're going to make a breaking change, there's a responsibility on us to try to minimize the chance that web developers are going to be negatively impacted by this. Whether it's outreach or giving developers an easy way to adapt to it.' And then there's a whole other category for maximizing web ecosystem health, and there's the benefit for the ecosystem, and that includes, are we going to improve interoperability, things like that.
Brian Kardell: It's funny you mentioned the one where there's just a bunch of cons, because there's two parts of that that are, I think, interesting to me. One is, you need data, right? I mean you could just be like, well, I don't know. It doesn't seem like it's probably a thing that people use and let's turn it off and see what happens. That seems like not a great idea. So you want to gain some confidence in what you think about it. But basically the HP archive and Chrome's own use counter are I think the biggest source of data for that.
Rick Byers: I think so, increasingly now we use another type of data that's similar to our use, use counters various course. It just tells us what fraction of page is used on. We have a feature in Chrome for users who have opted in to anonymous aggregated data collection. We have a feature that we call UKM, URL Keyed Metrics. And that's one where in addition to getting a bit of whether it's used, we can get the URL on which it was used. And so we can do some more sophisticated analysis based on that. And say, 'Well, what's the distribution across? Is this a feature that's used on one popular website, in which case it's probably easier to break. Or is it a feature that's used on 50% of the top million, except for the top 100, right?' It's very tail weighted. And those are almost impossible to break, because there's hundreds of thousands of developers who would have to make a change in that case.
Brian Kardell: Yeah, I was going to say, so I only in maybe 2018 or something, I started, I guess it was a little bit more in like. But I started getting involved in some things with the HB archive and looking at that data and kind of interrogating some of these things myself. And it is surprisingly full of complex twists like that. I know I wanted to know about closed shadow do. I've always said I think that almost nobody really wants that, in my opinion. It doesn't intuit to me that that's what you would want. I get why we got it. I know where it came from and everything, but I think that ultimately people want a speed bump. They want a sign, not a cop kind of thing. Something to prevent friendly fire. Anyway, I said, 'Well, it's been shipped for a long time. Let's see what's the usage.' And it was like just as high for open, and I said, 'That's amazing. Who's using it?' And I went and with Barry Pollard at HP Archive, we went through and dug through some URLs and what we found was a lot of stuff like that where it was just iterating through properties and trying to do some kind of fingerprinting, or how can I determine that you're this browser I need to load this shim for, or whatever. So yeah, it's tricky. How do you make that interpretation with that data? Or we had another thing where we were writing the markup chapter and we found this 64-character long, same weird typo that caused a tag name to be 64 characters long of weird escape characters. And it's like you know that didn't occur on 10,000 pages independently. That's common cause, but it looks like a really popular thing. Because it's just the same system showing it on 10,000 pages. So, getting at that data and making sense of it is really complicated.
Rick Byers: It is.
Brian Kardell: Do you think that, does it worry you? Do you have other ideas about how, I guess you just told us one. Other ideas of how we can gain more confidence?
Rick Byers: There's a lot of things. I mean, there's some amount of trial and error and there's some amount of judgment here. But I do think as a whole we have come a long way. I think we've learned a lot about how to do these things in a responsible manner. And the reason you're surprised to hear that there's 200 or something is because almost all of them go off without a hitch, right? You've probably seen a couple press stories about some that didn't go off without a hitch. And if you read this document, a lot of it is about trying to take a really honest accounting and learning from our mistakes, so that we can get better and better over time. And so, for example, one of the things we've learned is we used to rely really heavily on our beta channels and say, 'Well, let's try this and see if people file bugs in beta.' And that's useful. It actually is meaningful, but there's just the type of user who installs a beta version of browser is not representative of the users who install all browsers. We tend to under miss enterprise, for example, in beta. And while we still get some value from that, I would argue we've learned over the years now Chrome relies much more on what we call early stable, where we upgrade ... When we're ready to push out a new version of our browser, we upgrade say 1% of our users a week ahead of everybody else. And we look at metrics and we look for bug reports during that period. And then in addition we make sure ... We know there's always going to be mistakes. It's a fallacy, it's a trap to think that you can ever be perfect at this kind of risk analysis. And what you need instead is to engineer a really good feedback loop. Having a really good feedback loop is more important than trying to do a perfect job of prediction. And so for example, this means that we need to have a bug reporting, triage, routing and diagnostics pipeline that we can trust so that when we have a breaking change and someone reports it, we can have confidence that within 24 hours or less we've detected it. And then we now have a policy, for example, that anytime we're making a change that we think may be breaking, including shipping a new API, we do it under a runtime flag, which means we have the ability to toggle the behavior without shipping a new binary. And so that also gives us some confidence. We can say, 'Oh, we're doing this thing we think is safe, but we're not 100% sure it's safe. And so we're prepared with what we call a kill switch that we can deploy to all Chrome users to reverse the decision on very short notice if we're wrong. And then that gives us, when we have confidence in our feedback system and our ability to react to that feedback, now we can be comfortable taking a little bit more risk. And this is always a balance and it's a trade-off kind of, but I think we've learned a lot over the last 10 years of doing this that generally we can manage the risks pretty well, I think.
Brian Kardell: A lot of this goes into processes and a lot of the things have changed over the years. Processes evolve over time. When I look at this list, I see a lot of features that I don't think would have made it into the system necessarily today, because they were from earlier processes. So you have these, cruft that was introduced in maybe early Firefox and it was just copied along. But turns out nobody really used it, so it was relatively easy to get rid of. Or there was one that was in here that was, I liked it was added for Apple's dashboard in 2004. It was this composite attribute on image elements. I didn't even know that existed. And in the Google thing, it had Philip saying, 'I didn't even know this existed either.' And it turns out that nobody else did either, so it was not hard to unship it. But I think that a lot of those things maybe would have had some more scrutiny today. The blink process is actually pretty involved today. Maybe can you give us a quick, super high level? How does something get shipped in Chrome to not 1%, but to all of the percent?
Rick Byers: The high level is that we try to have a process that balances. That is both maximally transparent and inclusive. We look for signals from all the other browser vendors. We look for signals from the tag. We look for what's the status of spec maturity. And critically we added a number of years back, we look, we want to see a high quality conformance test suite before we add features. And so we're kind of looking at that. But also, we want a process that a lot of processes have a tendency to evolve into stop energy. And they just, 'Hey, we're trying to mitigate risk. Let's just move slower and slower and slower and slower.' And so we've tried to be careful design a process that promotes velocity and therefore is comfortable with taking some risk and making some mistakes. And so our shipping process and our breaking change process have really evolved hand in hand. Because if we had no confidence in our ability to make breaking changes, I think we would need a much, much higher bar. We'd have to ship things a lot slower and have to be a lot more careful in what we ship. And we've learned over time there's a lot of nuance here. It depends a lot on the shape of the API. For example, we've learned that when you add a new CSS feature, you're probably not going to get it option until have it supported across all major browser engines, and then you're probably going to get pretty widespread adoption that's going to be really hard to change. But there's a class of JavaScript features, JavaScript features that are targeting specific big players. For example, we have a feature called FedCM that really targets identity providers. And it turns out that if you're shipping a new JavaScript feature for FedCM, you can expect it's going to be a lot easier to change because you probably, even if it's used on a lot of websites, it's probably used on a lot of web space via five big IDPs. For example, payment request is in the same, there's not that many payment processors, even though they're used on lots of websites. And so, one of the things I learned early on, I was surprised by some of the requests for breaking changes to payment request. And I said, 'This sounds crazy. How are you going to know this is safe?' And the answer was, 'Well, because I know the three people in the world using this API and we talk regularly and they've all told me that they've made the changes necessary to not rely on it anymore.' I said, 'Oh, I came from a world where I spent more time in CSS, for example.' And it's just wildly different types of APIs with wildly different compatibility properties. Sorry, I forget what your question was though. I don't know if I answered it.
Brian Kardell: No, I was asking you to maybe talk about the process to get something shipped.
Rick Byers: Right. So, we're trying to balance, so I mean, tactically the way the process works is. We have this tool called Chrome status that tries to manage a lot of this process, but ultimately boils down to an email thread, to a public mailing list called Intent To Ship. 'Hey, I want to ship this thing, and here's the data we have, here's the signals we have. What's the speck, what's its level of maturity, what are the conformance test suites? What signals do we have from other browser vendors? Signals do we have from tag? That sort of thing. And then we have a set of API owners. The Chromium project has, I'm not sure what it is right now, historically, somewhere around 12 or so API owners and three of them need to say, this seems like a good trade-off to me, the benefits seem to outweigh the risks of shipping this to me. But key to the process though is acknowledging that we're never going to get it perfect. And that we're going to make mistakes. And that we have to be comfortable correcting ... With having a process to correct for mistakes. And so that's what the flip side of Intent To Ship is intent to deprecate and remove, which is really, we probably should have given it a better name, intent to break or something anytime you want to make a breaking change. When we're shipping the primary risk that we're evaluating is interoperability risk. What's the risk that this API is not going to eventually work the same in all browsers? And where for breaking changes, the primary risk that we're evaluating is compatibility risk. What's the risk that this change is going to cause existing websites to behave differently or be broken in some way? And sometimes you have them both at the same time. In fact, shipping any new API can also be a compatibility risk. For example, as part of the reporting API, we shipped window.report at some point and we did some analysis. We thought it was safe. We didn't account for this big enterprise application that was relying on having an iframe with a name of report. So you could say iframe name equals report. And then somewhere in the code they had window.report. And they expected that to give them their iframe. This is some legacy DOM feature that has been discouraged for a long, long time, but still works in all browsers. That was a case where, 'Hey, turns out we just can't, can never ship an API called report, because we're going to break this major enterprise application that assumes no such API exists.'
Brian Kardell: That was invented by Brendan Eich way back in the very, very early days, because I was complaining about it on Twitter way back, and he was like, 'Yeah, that was me.'
Eric Meyer: I'm glad I know who to blame.
Brian Kardell: Right. Exactly.
Eric Meyer: Brian, it is usual. I mean it usually gets back to Brendan when we're talking about DOM stuff.
Brian Kardell: Right. So yeah, I was asking about the process, because I think it also evolved over time to try to find ways to prevent things leaking out. Because it used to be that even we would just ship something, we ship things with vendor prefixes back in the day, and those worked all over. You could have prefixed, IDL you could whatever you can-
Rick Byers: But in some ways prefixes were just a different way of trying to balance this trade off I'm talking about-
Brian Kardell: Exactly, right.
Rick Byers: ... profitability, risk and velocity. And it turned out we were putting blinders on. We were deluding ourselves into thinking that they gave us a sweet spot between interoperability risk and velocity. They just gave us the velocity and just allowed us to ignore the interoperability risk, right?
Brian Kardell: Exactly. And so, I think there are examples of this today where all of the browsers have to respect some WebKit properties. Because they turned out to be just too widely relied upon. And so, the example that I like all the time, it kind of doesn't matter what we write down, what matters is what everybody does. And it's important that we try to write it down so that everybody who does the implementation gets as close as they can, and then we continue to refine it. But I know there's plenty of things that happen sort of de facto that leaked out there like that. But I think that this process then evolved a little bit. So there's, like you said, there's Canary. We have these things behind a flag, so you have experimental web platform features you can enable in all of the browsers. So, there's steps to prevent it from ... The experiment from leaking out before. We are confident that it's at least pretty good take and that we can slam on the brakes if we need to, right?
Rick Byers: Part of the challenge here, I think has been that we used to assume that confidence came from really careful thinking and careful debate in standards committees. And certainly that is valuable. But I think at least I feel like I've learned, I think we've learned as an industry that confidence comes more from actually validating product market fit. And actually getting people using something, seeing does it actually solve the problem? What problems does it cause in that practice? Or at least you need that as well. It's not enough to just get wide review. You actually need experience. And so to me, the main thing that's helped us find a sweet spot in this trade-off, has been Origin trials. And that started as a discussion, I think it was Jacob Rossi from the Edge team who first brought this up at a TPAC brainstorming session of like, 'Hey, can't we find a safe way to experiment that gives us what we wanted from prefixes without the downsides?' And the history for us has been so Origin trials, if you're not familiar, it's just a way, I think Chrome and Edge, I don't know if there's other browsers that support it, but Chrome and Edge each have a system where a Developer can sign up and get a key that's tied to their origin that they can put on their web page that enables an experimental API for them that they can use in public. But in order to get that key, they have to click on a thing that says, 'I understand this is an experiment it's time limited and it will stop working. It will break at some point.' And they also have to supply an email address so that they can be notified of what the breaks are going to be and when they are. And we started very conservatively with the design of origin trials. We were very afraid of just reintroducing prefixes. And I think what we've learned is now we've done hundreds and hundreds of origin trials, and I'm not aware of a single example where we've felt boxed in by something. Where we've actually, where origin trials have failed to prevent the interoperability risk. And so, we've slowly gotten a bit more lax. We used to require a gap at the end of an origin trial before shipping a feature. So, we thought promising that there be a period where the API didn't work was important to preserve the safety. Turns out we eliminated that. We haven't seen any downside to that. So that was a place we've been able to just move a little bit more in the direction of velocity and not seen. But it is something we've had to learn and figure out I think. And I imagine we will see some examples of it not working perfectly that we'll want to use to push us back in the other direction over time as well.
Eric Meyer: So, is there anything special you have to do to be an origin?
Rick Byers: No. Origin trials are designed, one of the properties we wanted was to make sure that all websites were treated equal. You just have to give ... So, you have to have TLS. So I don't consider having HTTPS something special anymore, that's table stakes, but maybe for some people they still consider that a burden, I don't know, because we can't trust what the origin is if you don't have TLS. But once you have a TLS connection with a cert, then you can just sign up and say, 'Hey, I want' ... In fact, anyone can go and get a key for any origin. You can go and get an origin trial key for google.com if you want. It's just not going to be very useful to you, unless you actually have the ability to put it on a page served from Google.com. Because then the idea is the browser just checks, uses the key, checks to make sure it's signed by the right private key and then checks to make sure the origin matches the origin of the website.
Eric Meyer: If I have my own website, I could get an origin key, put it on there, and then that would cause anyone who's loading my site to essentially participate in the origin trial?
Rick Byers: Yep, exactly. So, it still means for us to put something in origin trial, we still have to go through security and privacy reviews if we're launching it. Right, it has as much risk on that side. We don't have to be quite as worried about the state of the standard. We don't have to. We can let people experiment with something in production and learn about what works, what doesn't work, and then we can feed that back into the standards process. And make breaking changes to the API before we really say, 'Hey, this is a mature specification that we think is at the level to ship.'
Eric Meyer: So, that's a breaking change as in we're going to change the stuff that's being origin trialed.
Brian Kardell: Yep.
Eric Meyer: CSS anchor positioning is probably a recent example of this where the anchor positioning specification has gone through changes. As people have tried things out, as it's been discussed, the original anchor positioning specification is not exactly what the specification says now. So, there are breaking changes in there where, 'Oh, we discovered that this particular combination of properties and or values doesn't work out. We had to adjust it.' That is a 'breaking change.' But it hasn't really shipped publicly yet.
Rick Byers: Yeah, exactly. Generally, when we say breaking change, normally we mean a change to something that's already publicly shipped. So if it's just behind a flag, it's just experimental web platform features or it's just origin trial, it's expected that those things are going to change. And so, maybe it's going to break some websites somewhere, but that's on the site at that point, it's not on the browser. So, there's no approval, there's no policy required really for making a change to an API that hasn't gone through our Intent To Ship process yet.
Eric Meyer: Okay. Yeah, that's very cool. So anyone listening to this could basically opt to their own site into an origin trial, and then yeah.
Rick Byers: It's how we learn. A lot of design has been done. I think select menu is done this way as well. There's a lot of design where, especially for more complex features where it's really hard to know how exactly to balance some of the tradeoffs of the design. I think we're able to do the design much better by, in some sense having the implementation and one or two real-world deployments proceeding in parallel. And kind of feeding off each other, learning from each other. And only then do we get to the point where we say, 'Oh, now we really understand how this thing works.' Now, we usually don't even write a spec by that point. We have an explainer, we require an explainer for an origin trial, but we don't require a spec, but then we make sure origin trials are time limited. We don't want things to stay in that state. So eventually, if you're running an origin trial, you have to request, I think you get to run it for up to six months, and then you can request three months extensions one at a time, but you have to show the progress on standards and then what you've learned, how you've evolved the standard. And we have had cases where API owners have said, 'Sorry, we're not extending your origin trial, because you're not making progress towards shipping this as a proper specification, so it's just not going to be available anymore.'
Eric Meyer: Interesting.
Rick Byers: Yeah. Yeah. There's all sorts of things that could go wrong here.
Eric Meyer: I'm sure.
Rick Byers: But in practice it's worked surprisingly well. In fact, I've been surprised at how we've been able to get more and more value out of it without having some of the negative side effects that we're worried about.
Brian Kardell: But looking at the list of things, like there was multiple shadow roots. I know, it's interesting to look at some of these things and say, well, I don't know. Was it the right mix, right? Did we let it escape too early? But multiple shadow roots, I don't think, there were no origin trials. We could not have put them in origin trials. That was too early. In fact, that work might have begun before the split even, right? The work on-
Rick Byers: Yeah. Yeah, it did. Yeah. I remember Dimitri Glazkov and others were landing patches in WebKit for Web Components
Brian Kardell: Yeah, right.
Rick Byers: I don't know.
Brian Kardell: There were a couple of things in this list of things that were unshipped that were interesting to me because they were shipped, then they were like, it's actually the implementation is not very good, so we have to unship it. And then later on they were reshipped. So one was CSS variables was there was an initial implementation that was, I guess the implementation was not very good. And it was unshipped both. It was in the fork and it was unshipped from Blink and also from WebKit. When WebKit saw that you were unshipping it, they looked at it and actually Andreas Kling who was on the show and is doing Ladybird, was the one who approved removing it from WebKit too. So that was interesting. And then one that's close to me, MathML was also a casualty for the same reason. And I mean it is really unfortunate that that happened at that point in time. I think we would probably be better off if we had somehow managed to do what we did with MathML ultimately back then. But I think MathML will be better off in the end for the fact that we didn't just roll with what was going on in there because it did force scrutiny to say, 'Yeah, but how does it align with the platform? How does it work with CSS? Why isn't there any IDL for any of these things?' So yeah, I mean, I think it can improve things too, even though there's a temporary and maybe sometimes way too long pause in there. The process though, because the process, you have these steps that are good to watch and I think of them as kind of forcing functions. So if you watch, there's intent to experiment, right? That's one. And that was broken out after I think the toast incident, I would say. I don't know how you want to refer to that, but.
Rick Byers: I think we introduced intent to experiment. I think we had that from the beginning of origin trials. That's just about getting an approval to run an origin trial, and I think we introduced that as soon as we had. Maybe you're thinking intent to prototype, maybe.
Brian Kardell: That's the one. Yeah.
Rick Byers: So that's where we ... Yeah, that came later. We didn't have that initially, I think. And the idea there was to try to make it ... We used to call it intent to implement, which caused a lot of confusion. People were like, 'What do you mean you're implementing? This isn't this ready to be implemented?' And we said, 'No, no, all we mean is we're starting to prototype and experiment and learn about what this API is. And so intent to prototype is about we encouraged people to, and it's not required in the process, but it's encouraged to send this email as a heads-up saying, 'Hey, we're starting to land code for this to help front load discussions and raise awareness.'
Brian Kardell: That's interesting though because it's like a forcing function, like I said, so when it was called intent to implement, people looked at it with a new degree of scrutiny. They were like, wait a minute, this is ready to ship. That's what I understand. So I better look at this before it ships because once it ships, then it's harder. So you got a lot of comment. And it was like, we don't want that kind of comment right now, because we're not really implementing. We're intending to begin prototyping. So you can be involved in that and direct all those comments over there, that would be great, but we're not shipping, don't misunderstand. And now it is intent to ship is more like what I think is a forcing function that people can watch. And the reason I say forcing function is that a thing that I've noticed, part of the reason that we got into this conversation in the first place was, I watch too many things and as a result, things in standards frequently take many years. And as a result, occasionally you need to say, okay, I need to step back away from that one for a while and then just check back in when it's serious, when it's ready to take its next step or whatever. And seeing something intended to ship, if I see that it goes, oh, now is that time. But that's also unfortunate because it means that there is this time when you Google or whoever is the people working on that, they're trying really hard to work on it and they're not getting the feedback. Because there's not enough people who have the time and budget to look at it critically in the same way. I don't know. It's a difficult balance. Do you think about that internally in the team at all? This sort of push-pull and where's the risk? Maybe this kill switch idea is sometimes a really good forcing function and maybe I'm not encouraging that you should use it, but I'm just saying, do you think about it that way sometimes?
Rick Byers: Think about the kill switch as a forcing function?
Brian Kardell: Yeah. Could you just let a thing go? We're going to ship it. Because we want to make sure that people really paying attention because we think it's really good and it's just not getting the feedback and don't-
Rick Byers: First of all, I think there's often a misunderstanding in terms of feeling like intent to ship is the last chance. And I think we've all learned it's really not. Interoperability is an ongoing process and we've got lots of examples where we've shipped some, where we've had trouble getting much engagement outside of the Chrome team, for example. Or sometimes it's other teams working on a feature that they have a particular reason to care about it and want to push it forward and just nobody else really seems to have a reason. So, it's hard to get people to prioritize looking at something. And then you ship it and it gets some usage somewhere. And then now it's a lot more interesting. It's like, 'Oh, now I see it being used on this website.' And because one of the reasons I've cared so much about our breaking change process is because I think having some confidence in our breaking change process means that we can have more confidence in saying, 'It's okay that Intent to Ship is not the last chance to change something.' To say, 'Really what we want to get to is standardization and full interoperability. And what's the fastest way to get standardization and full interoperability? I think in some cases it does mean shipping something in one engine to learn about it. And maybe, like we always said, we want to make it cheap to fail. We have some examples. Request Autocomplete is one that blew my mind. I thought request Autocomplete was a great feature. It's like, 'Hey sites, we know that sites convert faster, people check out more often and complete things on sites when Autocomplete is there to fill in their credit card information for them, for example. And so we added an API that sites could use to help provoke it and make the autofill experience better. And for whatever reason, it just literally got zero usage. And that's one where I'm glad other browsers didn't spend time debating the spec for this thing because it turned out to just not, I was going to say not be a good idea. I don't know if it was a bad idea or if it was just a good idea at the wrong time, but for whatever reason, it failed to find product market fit. And so we just, at some point a year or two after it shipped, we said, 'This thing has failed, let's remove it.' And the use counter was like zero. I was like, 'Wow. Yeah, the use counter is zero. Yep, it failed. Remove it.' And so I think making things cheap to fail is key to enabling an iterative process of high-quality standards engineering, where we can get to interoperability and full standards compliance, conformance from all the browser engines over time. Especially, I know in your other shows we've talked about investment asymmetry, where's the money for investing in new web platform features? And if it's concentrated in one place or the other, you're going to struggle. You can't do everything by consensus and mutual investment.
Brian Kardell: Yeah, I mean, this is what I was getting at. I suppose I should have pointed to previous shows where we've mentioned that Chrome Google plays the role of the R&D arm currently of the web platform. So, you do a lot of the research and development that other organizations can't afford to do. Or well, I don't want to say can't afford to, they probably could afford to. But don't invest in for whatever reason. And I'm not claiming there's a right or wrong answer to that question. But the way it is currently, the R&D of the web is largely done by Google and it means a few things. Like one, it means that Google directs the R&D, like maybe not everybody agrees with the particulars of the R&D that you're doing in some cases. Or maybe there is this asymmetry where you can't afford to pay attention, and so you feel dragged along a little bit sometimes. Yeah, so that is what I was getting at. I was saying, I think this thing about this forcing function is, I think about standards as sort of degrees of real. And I look for signals along the way to say, 'Hey, this thing just got more real.' I mean, we have this product that we make BCD watch that you can go to bcd-watch.igalia.com and you can see there's an implementation report and it will tell you every week tiny little report that is like these are the things that got implemented, got recorded as being implemented in a third engine. So it's like a super tiny list, and you can just open your RSS reader every week and you can be like, 'Okay, it's those five things.' And it's really easy to keep up if you want to know what things as a web developer you probably can safely learn about. Because they're not going to be radical changes. They're not questions about whether these are going to ship, they're in all the engines. They might not be shipped everywhere yet. They might not be available. That's what baseline and all that is for, but this is a signal that give you a nice heads up. So I look for those and I look for the forcing functions like I said, that the rest of us can watch. And I don't know if there's some opportunities here to maybe improve that so that we have easier to follow signals so that people know, when it's like, 'Hey, this is ready.' For in standards. We would kind of call this wide review. But I think that the public version of that is just like, 'Hey, we're going to do this. If anybody cares.' Whether that's privacy people or security or accessibility or just JavaScript developers, whatever. You're going to get the feedback if people start to look at it. So, how do we raise good signals? I think there used to be a Twitter bot that was intense Twitter bots, did Google run those? Do you know?
Rick Byers: No, no. I think it was just community-run thing just off of our mailing list. It's just mining. The blinkdev mailing list is where these go. So, multiple people who have built different tools that mine the blinkdev mailing list. But I mean, part of the challenge here is you got to ask, 'What's the right time to do what level of review?' And we have this even with tag review, we've got early tag review and then full design reviews. And in a lot of cases we hear from tag, in some cases, if this feature only has interest from one browser vendor at the moment, maybe it's too early for tag review, it's not a good use of tags time to look at it. There's only one browser vendor really interested in this feature. And I think that's part of the crux in this, I don't think there's any one perfect answer to that question, 'What's the right time to review this?' I think of it more as expanding circles. You want to start with, there's maybe a small group of who are ... And I'm not saying that should be constrained in some way, but I'm saying, new ideas, doesn't make sense to have 10,000 people reviewing them. Have one web developer who's going to be using this feature, have one browser vendor. Maybe have one accessibility expert, something like that. And then you want to widen the circle of reviews more and more over time. And by the time something gets to a rec class standard, it should have had very wide review. But of course, there's always this challenge of, the earlier something is the easier it is to change it, right?
Brian Kardell: I don't know. I like the circles that we've called that, like layers of an onion. I like to say standards have layers like an ochre.
Eric Meyer: Or an onion.
Brian Kardell: Yeah.
Eric Meyer: When you cut right through them you cry. Anyway.
Rick Byers: But I do think, I mean, your point about forcing function is, I think a lot of this is about creating the structure such that we tend to get a good outcome by design, instead of by requiring some kind of heroics. If you think back to the way we used to do web API design, even with standards process, it took a lot of heroics to get to a good outcome, to get to interoperability, to get to something that actually solved. Didn't have accessibility problems, didn't have privacy and security problems and whatnot. So, I absolutely agree with you, a lot of ... In the perfect world this whole process we have with Chromium where we have API owners, sometimes people think about it as, 'Oh, the API owners are like these expert judges.' My perfect world, the API owners is just a script. It's just like a checklist. Do we actually have the culture and the engineering discipline and the processes such that everyone involved in shipping a new API knows how to do a good job of standards and web platform tests and tag review and whatnot? And you just need to make sure that all the boxes got ticked, or something like that. To me, it's more, and we've seen this happen with web platform tests, for example, right? When we started and we said, 'Hey, if you want to ship' ... We started by saying, 'If you want to ship a new feature in Chromium, you need to either point to web platform test or explain why that's not easy.' And we have a lot of pushback from that. And a lot of people said, 'Well, it's not easy here and it's not easier.' And I funded a team at that point to go and hammer down all those. Somebody said, 'It's not easy here, go invest and make it easy so next time there's no excuse.' And a lot of that we shifted our culture such that now it's just the expectation that anytime you ship something new, of course, it comes with web platform tests, you're going to probably write those near the start, instead of as some ... I remember back in the day, sometimes we'd hire some vendor to go after the fact when everybody was already done and everything, all the work was done. It's like, 'Oh crap, we forgot to check the conformance test suite. Let's go find a low-cost vendor somewhere who can whip out some conformance tests for us.' But the only way we've been able to do things like the interop program and whatnot is we've really ingrained that we've used it as a forcing function to ingrain it into our culture that writing conformance tests is as important as writing specifications in how we engineer the web now.
Eric Meyer: Honestly, more important in my opinion, but.
Rick Byers: Thank you. I agree. I didn't want to go that far, but I agree with you. I think they're more important than specifications.
Brian Kardell: One thing that I wanted to ask about, if just this past week Sarah Soudin wrote a thing about the CSS carousels, which is a thing that we talked about that led to some of these conversations, and this week on the ShopTalk Show they were also talking about primarily that article and the things around it. And they asked, 'How does a thing ship if it has issues?' And I was just wondering if you want to respond to that?
Rick Byers: Yeah, I don't know the details of Carousel. I know there's been some debates about some aspects of it. But in general I would say, from an engineering perspective, everything has issues of some sort. And maybe it looks reckless. Hey, maybe it is. I think reasonable people can disagree about this, and I welcome constructive debate about this. And it's part of the reason why we have our intent to ship threads on a public mailing list that anyone can comment on, because we want to hear contradictory perspectives on this. But if we acknowledge that everything has issues, the question then becomes, what are the issues that are easier to recover from and what are the issues that are harder to recover from? And some of that requires a good understanding of what breaking changes are easy, what breaking changes are hard? Because a lot of the time we use shipping, just like we use ordering files to understand what's working and what isn't. Sometimes we ultimately need to fall back on shipping and saying, 'Hey, there hasn't been a lot of engagement on this, so we think now is the right time to get something out. And we think by doing that we're going to learn something from it.' My favorite example of this may be is one I do know more about is the scroll-to-text feature, URL fragments where you can ... We extended the grammar of URLs to refer to text fragments. And that was controversial, right? This was one where we chose to ship it in Chrome. We were pretty convinced, we had evidence that it really brought value to users, and others felt like it wasn't ready yet. And so, we shipped it, Edge turned it off, and their browser are based on Chromium. And then other people looked at it, and eventually everyone else shipped it and said, 'Actually, now that we've looked at it does look like it's probably okay.' There's still some debate over it, but that's one where I think we were a little aggressive. And part of the reason we were aggressive, so I was pretty comfortable saying, 'If we need to turn this off, we can.' It's not like it's going to stop pages from working. This is a change that we can make where it's a two-way door, it's a reversible decision, right? So, we got to be a lot more careful about the one-way doors and we should be more comfortable taking risks when there's a two-way door that we know can have confidence that we can correct mistakes for in the future.
Eric Meyer: That makes sense.
Brian Kardell: Thanks. Thanks Rick for coming on.
Eric Meyer: Thanks a lot, really appreciate it. Always good conversation.
Rick Byers: Thanks for having me, guys.
Eric Meyer: So, remember, next guest, you get the free tote bag.
Eric Meyer
Brian Kardell
Rick Byers