Igalia's Brian Kardell sits down to chat with Google's Rick Byers and Microsoft's Rossen Atanassov to continue our discussion of rendering engine diversity and ecosystem health.
Brian Kardell: Okay so I'm Brian Kardell from Igalia, and we've been talking in our past chats about the topic of browser diversity and ecosystem health. Last time I was here with Jeremy Keith and Stuart Langridge and today I have two other guests want to introduce yourselves?
Rick Byers: Sure... So, I'm Rick Byers. I'm the director of engineering for the blink team at Google, and for the purposes of this conversation really I'm wearing a different hat. As many people on the Chrome team, I'm someone who just cares a lot about the open web and wants to see the open web succeed... and so it's kind of that intersection of what makes sense for Google kind of from a business perspective and then what is good for society in the web as a whole, right? That's where I try to focus.
Rossen Atanassov: And I am Rossen Atanassov. I am with Microsoft. I work on the Microsoft edge browser. I was previously part, of all the way back to Trident days of IE, then onto EdgeHTML and Edge, and most recently I was part of the transition to Chromium. And, similar to Rick, today I am wearing a different hat. Mostly, again, as a citizen of the web community and the community that really cares about the open web pushes the open web forward. I'm also part of the w3c TAG where I serve with a very, very similar role which is about individual points... and care for the web from a technical guidance point of view - and so most of my opinions today are going to be personal and I will make sure to color when I'm speaking on behalf of the company.
Rick Byers: ...maybe it's worth also saying (explicitly), you know, of course my opinions also are my own and don'trepresent those of Google. But I think it's worth acknowledging that this is... kind of an emotionally charged topic for a lot of folks, and, so it kind of feels a little risky to talk about... But I think... You know, Rossen, from the conversations we've had, I think you'd probably agree that this is too important of the topic for us for those of us who are kind of deeply involved to just be afraid to talk about it... And so, I just want to apologize if I anything that anyone finds insulting... You know, please let me know. My intention is.. is... well, obviously rational people might disagree on some of these topics, but I think it behooves us all to kind of talk openly and with humility and try to understand each other.
Brian Kardel: I think that's well said. So, the topic, just to introduce it really... I wrote this post that was talking about how we frequently talk about browser diversity - really rendering engine diversity - and the importance of it... and... it's usually in the context of when something has changed in that area. What I argue is that: That is a useful thing to some extent but it's also, like, an incomplete picture. And, it's actually potentially actively misleading if it's the only thing that you're looking at and thinking about. That there's a lot of things that go into what makes for a healthy web and a healthy ecosystem. And that really the second half of the web became a lot more open and a lot more diversely invested in, and that that increase is actually really healthy for the commons. Both of you, I know, have listened to the last one so I would like to give both of you the opportunity to say anything you would like to say about any of that.
Rick Byers: Sure, so maybe... I mean, there's all sorts of areas we could dive into here but maybe I'll just start with my guiding philosophy, you know, for this and in other areas. I believe that the most good in the world tends to come from capitalizing on win-win situations. We have a natural human tendency to look at trade-offs we're kind of hardwired for us versus them thinking and the tendency to let it kind of mask the opportunities from win-win situations, when in reality a lot of progress, and a lot of things are not a zero-sum game. But, it's easy to get caught up in the emotion of feeling like, you know, if something is good for someone else, you know, that for a different group maybe then it's bad for my group. And so, I spent a lot of my career trying to find places where people might think that oh you know we're competitors or, you know, you know our where our interests are at odds and trying to look for the overlap where there's common interests. I think that this is one of the beautiful things about the web, for me, is that there's a heck of a lot of, as you say, Commons - a heck of a lot of common interest from the entire industry.... And just because something is good for Google doesn't mean it's bad for Microsoft or bad for Mozilla or something like that. And so, I spend my time trying to find the things that are good for the industry as a whole, good for society as a whole, and also good for Google's business.
Rossen Atanassov: I'm somewhat like-minded with Rick here. I definitely sympathize with the win/win situation and philosophy... You know, one of the things that often time goes unsaid especially, you know, in a group of folks like us who have been working for the last... I don't know... what a decade? Maybe more together sort of pushing the web forward - caring about the web... One of the things that that goes often and said is that there's a lot of collaboration that goes behind the scenes and into into forging what the web is today. There's a lot of work that goes in standard bodies, around the industry, regardless if it's w3c or tc39 or what-have-you, and there are a lot of different opinions, there are a lot of different interests on the table -- but at the end of the day what we care about the most is the better outcome for the web and ultimately for everybody's users, and the users of the web. So when we often talk about engine diversity, I want to also separate a little bit the difference between engine diversity and browser diversity. I think there's a very healthy diversity of browsers, even if the diversity of engines is not as richest as it used to be. I think you've mentioned already some of the past sort of popular engines that were out there including Presto and Trident and EdgeHTML, which is now being replaced by Chromium and blink, but the browser's are a lot more than that and so I want to make sure if we're talking about browser diversity or engine diversity in this case?
Brian Kardel: Yeah, well, this this is sort of the point of my article: that there are lots of of layers of to this problem and rendering engines is only one of them. So, for example, Brave is Chromium based but it is quite different in a lot of ways that's a particular kind of interest that is at the browser level not at the rendering engine level.
Rick Byers: First of all, Ireally appreciated there's a lot of nuance here and I love that your article and the talk that you last had went into some of that nuance because I'm often discouraged by the simplicity of some of the discussions., you know, - I mean... It's not it's not black and white I think Brave is a good example and it's not even necessarily browser versus engine, right? If you go and you look at the patches that Brave keeps they have patches to blink, right? They have made engine changes. And so, they are able to express their opinion that they and they choose to do this in their own fork right there. I've talked with Brave engineers and we've talked about to what extent might make sense for them to contribute some of their work upstream to Chromium because Chromium is a substrate that multiple browser opinions can be built on top of. So, you can see this, for example, when Microsoft was interested in submitting code to Chromium for the storage access API. Right? There was some thought that "oh this is going to be controversial because Chrome doesn't believe in ITP as has the right solution to the privacy problem" and... and we were able to have kind of a public nuanced discussion about that and say like "yeah we have different opinions on how best to maximize privacy well supporting the economics of the open web but we can agree on a lot of the substrate, and, I think we can agree that this API is being becoming part of the web and so there's no reason why it shouldn't be in Chromium, you know, even though we don't know exactly how we're going to leverage that API in Chrome just yet". But Brave is another really great example where there's a different strategy where they didn't have to ask any permission from google Chrome was built the open source on the Chromium project from the beginning. And if you read the Chrome comic book back from when it came out it was precisely with the idea that we want to enable a diversity of opinions we want to enable competition. In fact, Chrome started to try to create more competition in the browser space. We never expected that Chrome was gonna be, you know, as popular as it is - but we thought that by having a great browser that had the JavaScript engine that was faster than the rest we could kind of r aise the bar for the entire industry and that's totally what happened. Competition is great and if people have different... different thoughts of how they can build a better browser, that's why Chrome is open source - we want to enable that.
Rossen Atanassov: Plus one. You know, being on on the other side of Chrome in terms of competition for many years I have to say that we do push each other quite a bit -- through various various approaches that are being taken. Whether it's performance, whether it's standards compliance, security, etc. I vividly recall when when v8 was started and the Chrome folks started pushing perf really, really hard. At the time we were implementing a new layout engine that was essentially built for future proofing our investments into a lot of areas that we felt the existing engine was lacking. And, and... We wanted to push the the web forward so that we can have a platform that is a lot more friendly to sort of the heavier demands of the richer digital publishing such as really rich, adaptable magazine like layouts or newspaper like layout with built-in capabilities like fragmentation... Or, in other words of breaking content apart between different pieces... And, we ended up, as a sort of consequence of this, influencing the rest of the industry too. So that today blink is undergoing more or less the same exercise and the new layout engine in LayoutNG is now heavily influenced by our engine. And, you know, we are now contributing to that engine oddly enough. But, it's fun and and at the end of the day I believe that this is going to benefit everyone. Everyone who is using the web through the... through the... through this rendering engine. That's a great/good example.
Rick Byers: Awesome, thanks. I remember some of those CSS working group meetings where people were proposing kind of, you know, new additions to Houdini and whatnot... And you would say "oh yeah that's easy for us, we could implement that easily": and our layout engineers would say "oh it's gonna be years of work to implement this and we were so jealous" and this is the kind of like... This is a diversity of architectures that I think is one of the elements of diversity that's worth talking about. Because it's one of the things we risk losing with a common code base even if we have different browsers on top I've heard people talk about the the risk of all if all browsers or if there's only a couple different ways of building engines. You know... if we make the barrier to having a different architecture of engine higher than it might impede the ability to kind of innovate and explore different solution spaces there. So... I don't know how do you think about that do you feel? Like... Like... imagine that Edge and Chrome were both on Chromium and and one of us wanted to undertake a radical rearchitecture of layout and the other one didn't. You know... How do you imagine that working? Do you think that would be a barrier to innovation perhaps?
Rossen Atanassov: Where I would essentially take this is to try and reflect on what that means for the end web developer who is going to essentially take advantage of... of the platform. Because, look, at the end of the day, the platform that we build is nothing without the innovation that happens on the web itself through, you know, the the skillful minds and hands of web designers and developers. So... To the extent which we enable creativity and ingenuity for the web, I think that that is essentially the important pedestal we should definitely keep with efforts such as Houdini which which you mentioned the CSS Houdini effort, where we've been slowly marching down the path of enabling more and more capabilities in the hands of web developers through javascript and CSS... So that they can go and extend the engine on their own... And here I'm going back to you infamous Web Manifesto that many of us were part of... Brian one of the founding people there... To... you know, if one of us wanted to take the engine and, and say "hey you know we're gonna rewrite it in a way that is going to enable web developers to express themselves and build new types of layout new types of experiences" without having to come and beg us for for hooks and api's in the engine itself... Then, I would say that if the others didn't follow, then then they're probably missing out. So, but on the flipside, I can also argue the point that I believe you're trying to make that, you know, if we were disagreeing say on v8 and... and something that has to go in there for the purposes of WASM -- at any given point, as long as we have an architecture that is built around extensibility and a layering and component model which allows companies to further tailor the overall final product: I think we're in a good spot. I think we're in a spot where the innovation is still enabled and there's enough affordances for everyone to go and build whatever they believe is best for their partners and customers and products and services and everything else that they want to make successful on the web.
Rick Byers: I think it's also worth noting that that this question of how do you enable innovation and exploration it's so simple to think of it as, you know, while Google has a set of ideas and Microsoft has another set. But I'm sure it's probably the same for your team as it is for mine in that we don't always know among ourselves. It's not like, you know, it's not like I is the director of blink have the answers of what the code architecture should be. And so, some of this kind of competition and enabling innovation is something that is important to us even within our own team. And sometimes it's it's tough to figure out how to handle. One... one example that I really like is when years ago there was a group of folks in the Chromium project there was a interest to introduce garbage collection to the C++ code base to solve some of the problems of having a garbage collected JavaScript heap where you've got manually managed memory for Dom objects. And there was a prototype built. And, you know, we couldn't agree. And I was one of the people that said, you know, "I think this isn't gonna be worth it." It sounds cool. I hate manually managed languages I think it's ridiculous that Security's critical software is being written in languages that can have dangling pointers. But nonetheless the cost-benefit trade-off to me - it seemed risky. It seemed hard to do. So, I probably was opposed to the oil pan project. But there was a group of folks who were passionate about it and they went out and they worked on a branch and they built a prototype, and they measured, and they got feedback, and they listened to what were people's concerns. And, I think it took, you know, we could go back and find the docs - it was probably a like... 6 to 12 month process or something of iterating and working on the prototype on a branch before finally they had the data that people like me could say "Oh. You're right. I was wrong. This looks real and it looks worth it. And, in particular the performance hit is not anywhere near as bad as we thought" and it was going to be - in fact it's a win in many situations. "Your judgment was right. Ours was wrong. Let's now make that the main line" And I can totally see, you know, that was within a single company. And, I've... Well, I would imagine I'd see that kind of pattern repeat with our list of what company the people with different opinions work for.
Brian Kardel: So... Part of my premise in this has been that: Once upon a time when we had Internet Explorer and Netscape - those were sort of evolutionary dead ends because there was no option but those architectures. So, if you wanted an architecture somebody need to create it from the ground up. But really, since then, every successful engine has been gained through evolution. And it's interesting when you talk about the Chrome split because that is a really interesting precedent in history that I think is relevant to another thing that I wanted to talk about which hasn't gotten talked about a lot which is... If you recall that time in history the web was the w3c was sort of going in another direction. HTML was sort of done. When the WHATWG was created, a lot of us, including myself, saw that and thought "Well, yeah... but look at who's supporting is like Apple and Google and like... these companies don't have a web browsers. So... that's going to be really hard. But then Apple got together and created WebKit. There was a lot of interest in WebKit at the time and that was really, really powerful: Many people contributing. Many organizations contributing for various reasons. I know that like, Adobe contributed a lot to WebKit. Google contributed to WebKit. Igalia contributes to WebKit. We had like 11% of all the commits last year. Sony contributes to WebKit. And so... That's really, really healthy. Also, it it demonstrates that coordination between many organizations can be a really powerful tool, and that...so... when there become disagreements about where we want to take things, or if we feel that we can add to the diversity the architecture and it doesn't match where we want to take the web: We can fork it. And that also plays into Rick's comments earlier about downstream. Like, there are a lot ...of downstream forks, of Chromium and WebKit. Some of those wind up coming back but we enable all these downstream things as well. But... One of the questions that I have here that I think is really interesting to think about is like: How could we get another engine? We have a lot of "others" out there. They're not a browser rendering engine but they are rendering engines of some kind that are used for e-books or print or something for your tablet... And some of those are maintained by really powerful companies with money even. So... I think it is very possible that we could see another confluence of companies that could come in and bring us more diversity through either contributing to existing engine or forking and creating their own. What do you all think the most likely way that we're going to have another engine?
Rick Byers: In my opinion it is if the current maintainers of Chromium do a poor job of being good open source stewards and the other contributors to Chromium decide that they could do better on their own and, you know, forl Chromium. You know, you could imagine a soft fork that stays upstream that maintains some patches - or you could imagine a hard fork where maybe if there's enough interest from enough different companies... And that this is... this is ultimately what keeps people in an open source project honest in terms of... You know, if... There's a lot of reasons why it's in Google's of business interest to be sharing the development costs in Chromium, right? I mean, first of all it's it's better for web developers. Google benefits when web developers have lower costs to build great experiences on the web and it's... the more interoperability there is between engines the lower the cost of development for the web, and the better it is for Google's overall business. And so, Google has this business incentive. And so it's all these trade offs that would determine what kind of happens to the future of engines and these are business questions, right? Like, you know, it's kind of naive or silly to think that these are going to be determined by some kind of religious ideal, you know? It's gonna be determined on, you know, what's best for different business models. We should recognize that and try to understand what those business drivers are. You don't need some artificial incentive. Rossen and I have talked openly about this. Like, that at some point, it might make business sense for Google and Microsoft to go their separate ways, right? And I don't think that's something that needs to be a taboo topic or, you know, "oh we hate you now" kind of thing.
Rossen Atanassov: Oh, absolutely. I mean forking is always an option for anyone, right? I can... I can see Google going into a non-compete and, you know, essentially saying, you know, from from tomorrow we're gonna stop contributing to Chromium upstream, and essentially we have our own private Fork. Now, we can do the same thing. Igalia can do the same thing. You guys can fork Chromium tomorrow and, as far as I understand you have enough engineering systems and infrastructure to support your own builds and testing for structure and everything that takes to you, you know, make engineering of such a product reality. But, I wanted to unpack a couple of things here, because I really like this topic of "Hey what about", you know, "writing a new engine and starting from scratch". And, you know, redoing everything from the get-go. I've been part of essentially two rewrites of core parts of the engine from from scratch. We wrote a layout engine for IE8, and then we did it again with IE 9. And the new, what we called the layout builder engine... What I would say about rewrites and starting from scratch is that it is very, very difficult to write something from scratch if you come to it without any prior knowledge. Without any prior experience. For example building the the first engine took us almost three times longer. Then we rewrote the engine for the second time, and the second rewrite was completely definitely was completely different architecture. It was built in a different language with completely different constraints, with different memory model - it was... everything was completely different... and it took us a third, maybe even a quarter of the time to do it, because we were already warmed up to to everything in the web... and and what the expectations are from such a layout engine starting from scratch. Even if you have solid, capable engineers: Building that muscle, building that knowledge and sort of expectation of what the web needs in order to continue functioning, is very difficult. And Brian pointed out, you know, some proprietary engines with some specific intent and purpose such as epub readers or engines that are used for print. And, a lot of times these engines, I would argue that they don't need the full capability of the web. They are not as dynamic. They don't.... they don't require the performance characteristics that, for example, you know, a heavy web app such as let's say Facebook or Twitter or something that is reallym really rich requires today. Their models are a lot more about the web of what it used to be, which was a lot more static. It has to be beautiful, so it has to have enough constructs to to make the designs and the ideas of designers possible, but they are less demanding. For those specific engines, I would... I would argue that, you know, evolving... evolving their market, and their needs as a separate engine is certainly possible without without having to keep up with everything new and latest that we are adding into into the web platform today... I was gonna say a couple of things about forking... Like I said in the beginning: It's always an option. It's not necessarily the best one. A lot of forking can be avoided, or in some cases aided, through careful layering and componentization and abstractions. I think the Chromium project is fairly advanced in the way that is being structured and different components are isolated. Having worked on it for almost two years now I have to say that the engineers who have contributed to this project have done a great job of enabling this. And then there's the other part which is governance. Currently Chromium is still a single governance project, governed by Google, and I'm curious to hear from Rick... To put you on the spot a little bit on whether or not this is something that you consider important? And, if so, is this something that you are considering to open up a little more and add more governance or more structured governance into this project?
Rick Byers: So.... That's definitely good topic. You know, obviously it is a controversial one and not one that I am in a position to speak on behalf of Google around. I will say from my personal perspective one thing that... This is what I was alluding to before, that I think governance some sense is secondary to the "to what extent are people's business goals being met in collaboration?" And so, one of those things is: To what extent is Google getting value out of the contributions of others? And, I know when when we left WebKit we were the majority contributor to Web Core but definitely we were in a minority position in terms of the agency we had. And so, you know, at the moment Google is still by far the majority investor in Chromium. But, I personally would love to see that change. I would love to see you know Microsoft, you know, Microsoft is definitely doing more and more... and Igalia is doing more and more. You know, I'd love to see more and more companies hiring Iglia and helping share the load of the maintenance burden of keeping... keeping things running, and dealing with the bugs and all that sort of thing. And I think, you know, my personal opinion is that agency should follow investment level. And, at the moment, given I get something like 90% of the commits in Chromium are from Google I don't think the current model is necessarily wrong or broken. It's not quite fair to say that it is governed entirely by Google, right? It's a complicated model. There are owners files and owners can approve a set of changes on their own. And there's quite a large number of non-Google owners across the product, including in the rendering engine - with folks from Igalia and Microsoft able to make decisions about landing patches without anyone from Google having to weigh in. We also have the API owners model for deciding what API is are shipped in Chromium, and at the moment there are two non Google API owners: There's someone formerly from Opera and someone from Igalia... and that's also something I would imagine - the owners model is intended both code owners in the platform pieces of Chromium and the API owners models - are intended to be meritocracies, right? As people demonstrate they can uphold the values of the project, there's a process for adding people that is independent of what company they're from. We have examples of people who were owners in the codebase, and then moved companies, and they're still owners. And so, it is true that at the end of the day, the escalation process in the Chromium project - it does eventually escalate up to the end review owners if decisions can't be agreed at lower levels and the end review owners, today, are all Googlers but... as far as I know that escalation process has never been used. You know... Might be a fun test to try someday but, generally we found the owners in an area are able to come to consensus among themselves
Brian Kardel: ... or maybe not a fun thing.
Everyone: [chuckles]
Rick Byers: Yeah.. You know, every time we see each other at TPAC or a blinkon or something, you know, I'm always asking Igalia folks, and Microsoft folks how they feel working on Chromium is going. You know, or in other channels, of course too... You know, are there places - sources of tension? Are there... In my experience good governance isn't a solution for bad coordination and miscommunication. And, so like... I think all options for the future are on the table but, you know, I can't say... I think it's more nuanced than what you're implying Rossen. What do you think?
Rossen Atanassov: It sounds reasonable. I can hardly argue with anything that you've said. I too feel like the meritocracy that is around owners and API owners is really well put. I think there's definitely parts of the Chromium project that are really, really well positioned for multi governance - and there are parts of the project that are less so. Especially when it gets closer and closer to the UI layers and the .. the things that make the browser a browser - which is something that we talked about earlier. You know, we... I would say that we tend to agree and collaborate and work really, really, really well on the web platform - and less so in the parts of the product that become differentiators to different companies. Early on when I was part of the team that essentially bootstrapped and and started the transition from Edge HTML to Chromium here at Microsoft I had a guiding principle which is that, you know, we want you we want to collaborate horizontally and compete vertically. Meaning that we want to contribute everywhere there is a horizontal avenue for improving the web, improving the infrastructure, improving the actual services - and then compete on the verticals of what makes a browser. On all of the user experiences. On all of the proprietary or product specific decisions that are being made for the purposes of both differentiation, and also further improvements on behalf of users. Whether it is tracking protection, or changes to the UI layer that require deeper investment.
Brian Kardel: So... Much of the discussion so far before this show has been about diversity of opinion really which is like "How much is it possible to influence things?" Which is... I suppose, ties in actually with your governance question as well Rossen... And I know on Twitter and on social media, this is portrayed very frequently as very one-dimensional and they aren't like that. There's a lot of speculation about what goes into the politics and business of things that is not always, like... grounded in reality. Like... A lot of things are not as controversial as you imagine that they are. They are more very practical business reasons frequently. Like.. "we can't do X because we're already doing Y, and that's necessary to do that first" or "we just can't spare the cycles" or whatever. So I'm just wondering... Like... Do you have any thoughts on that, I guess? For me really this feels like diversity of opinion - which I was unable to bring out in the last show.. I made a comment about it, but it wasn't easily understood, and so we just moved on... But, like... there are places where Apple does disagree - for business reasons, or just for, you know, architectural reasons or whatever.... Like... they disagree on how something should be on the web, because of privacy or whatever... That's a good thing... Right?
Rick Byers: Yeah, absolutely. I think diversity of opinion is something we need to be encouraging. You know, regardless... and again, this is kind of independent from the companies that are contributing, right? The story I told earlier about oil pan, I think, is a good example where Google employees disagreed and it was useful to have a mechanism to enable that disagreement to gather data and, you know, ideally get to the point where, you know, the market can decide... or some other, more objective way right we and I think tech is generally like this: We try to not make decisions based on politics. All right... We try to keep the politics to a minimum... and try to really focus on the merits and the data and be scientific. And so, I think you're right that what people assume people often assume there's like these master plans and that, you know, companies have these ,you know, very top-down structured master plan. And, you know, all the secret negotiation and stuff like that... The reality is much more banal than all than that. Right? We're a collection of individuals we all have our own opinions. We have some kind of loose organization to help us, you know, get some alignment and focus. And then we just iterate and iterate and iterate. Yeah, we might have different principles - and this is what I think it can be useful to to discuss these principles that guide our decision may be. For example, on the privacy front, right... I think we all share the principle that we want to reduce tracking online. Google has an additional principle of wanting to support commerce online. We want the web to be a great place to make money. And, you know, we know...We've seen it in the data. We've talked, we've shared publicly the data that shows the publishers lose half of their revenue when you take away third party cookies... And we think that's bad for the health of the open web. And so we have a different opinion on that from Apple, and that influences how we're approaching and trying to solve the privacy problem. But I think it's great that there are these.. That there's an outlet for these diversity of opinions and, you know, in some sense it's that eye of the free market and the value of a democracy to let people vote with their feet, let them choose what browser they want to use. I think that's a powerful choice, right? If you are not happy with the choices that Chrome is made on Android you're free to install Brave, right? You're free to install Firefox. Completely different engine.
Brian Kardel: Rossen, did you have any thoughts?
Rossen Atanassov: I do, yes. So diversity is arguably one of the things that is keeping the web healthy and continuing to keep the web healthy. But there are a number of examples that, like running examples, that I can use to sort of illustrate how diverse opinions continued to work today if there's a little bit of loss, again, when people talk about diversity, they very quickly and, you know, run to the conclusion oh, you know, "we don't have X number of engines that are written from scratch and that's why there's no diversity". Well, reality is quite a bit more nuanced than this. And that's to say that regardless of how, you know, different companies are organizationally structured and how decision making happens, and... and that varies vastly between companies. When we go and... and, at the end of the day, try to move the web forward - kind of like Rick mentioned, we get together in various formats - whether this is through standard groups or online forums or sometimes, you know, on on face to face meetings: The lack of diversity in these venues is anything but. There is a lot of worka, nd a lot of hard discussions that go behind features of the web. I'll give you one quick running example, which is five, six, maybe seven years at this point... We, as part of rewriting our layout engine, we wanted to bring more and more fundamentals to layout to the web. And one of the features that we brought up was CSS grid. And, at the time, we were quick to implement it. It was rather straightforward in our engine and when we when we brought it to to the web there was a lot of excitement... But also there was a lot of pushback on various technical aspect aspects. And I'm not gonna go into the details of what followed next, but there were lot of back and forth between all of the different stakeholders... And, at the end of the day, again, it took someone like Rachel Andrews to go and continue advocating for grid and for the richness that it brings the web. Then joined by Jenn Simmons, and more advocates from the design community. And last, but not least... certainly not least, Igalia stepping in and and driving implementation into WebKit and blink, fast followed by gecko. And, talk about diversity - right? Talk about diversity of opinions... Like we have argued endlessly in the CSS working group of how grid should work. And after that we continue to argue as various people were landing their work in different engines. And it wasn't the engines and the fact that they were different that made this particular feature as successful as it as it is/it was those conversations. It was those people who are truly passionate about moving the web forward. And, yes, they represent different companies. These different companies have business goals. And, a lot of times people will channel and have to channel business goals in conversations -- but it was this community. It was this first set of people and opinions and desires and passions for the web that... that are bringing these these types of features to the way...
Rick Byers: I think... I think that's a really good point, and this is something I was a little disappointed that you didn't touch on more in your last talk Brian, is... there was some conversation - I forget who said it, but ,you know, this question of "oh, well, what can we do about this?" you know, "How can we support diversity?", you know? And, you know, there's a few obvious examples that are answers that weren't touched on. I think which is first of all people can get involved in the standards process. People can get involved in these debates. We need.. Increasingly, I think all the engines are doing a better job of listening to developers. We've got the MDN needs assessment survey that we're using to try to help prioritize things within the Chrome team, but there's also room for other people to get directly involved either in standards debates or open source projects... Or the one that I was who's most surprised you didn't mention is: a lot of businesses depend on the web maybe they don't have the skills or the context to know how to to actually be productive indirect being directly involved but they could hire Igalia, right? They could say "oh my business would be served by this", you know, maybe there's... probably thirty different businesses out there that would be in their interest to get together pool their money, right? This question of the war chests that you talked about last time.. Yeah okay, you know, Google has a bunch of cash in the bank -- but our resources for investing in the web are not at all limitless, right? It's actually fairly finite, where the resources between all of the different companies in the world that benefit from the web are massively greater. And, if even a fraction of that was going to words to pay for things that benefit the Commons, right... If, you know, the way Grid was developed or, you know, whether it's [hiring] Iglia or other companies like Igalia, I think that would greatly increase the diversity... Increase the diversity of investment is maybe another way of looking at this. You know, to me it's a shame that the diversity of investment the number of companies who are willing to actually put their money into making the web a better platform for everyone who benefits from it is quite small. And I think that's just an artifact - the barrier to entry used to be so high that only the biggest companies could be involved in the browser market. Now... I don't know if any of you have read The Master Switch by Tim Wu Tim Wu coined the term Net Neutrality, and his book the Master Switch is a phenomenal history of all the different communication technologies and kind of... the trade-off between openness and closed. And he makes the point that the definition of openness it's not about some of the things we've talked about here. It's about "How high is the barrier to entry in the market?" Snd open source, and frankly Brian earlier you mentioned the whole WHATWG/W3C history... something I think it's lost on a lot of people's at the time W3C specs were copyright W3C which meant you couldn't legally fork them. what WHATWG folks had to go and reinvent basically write HTML from scratch. That was a huge barrier to entry, and a huge barrier to diversity and innovation. You know, luckily now most specs we work on permit forking. I think we've learned from that. And similarly most code bases we work on now for engines permit forking. And so, I think that's dramatically lowered the barrier to entry to anyone that has different ideas and wants to contribute or wants to try to be part of the market themself. And I think that's the thing we should be most focused on. Like, diversity is valuable but we should fix the structural things that prevent there being a high barrier to entry a high barrier to actually applying diversity in practice.
Rossen Atanassov: The readiness and the openness to diversity today is actually amazing. I think the the barrier to entry and motivating and and shaping the web and influencing the shape of the web is has never been lower. Anyone with a github account can go an open issue against any spec that they don't they don't like. Or, they find bugs: Testing is another huge part that has to be that a lot of times goes understated like completely understated but, you know, if you find issues if you find problems on the web nothing stops you from going and if you're a web developer or designer to craft the test submitted to you web platform tests and and now, you know, with that new test you will force people who are failing it to go and fix their engines. I think that is a huge part again of diversity, of diverse... Fiversity of opinions, diversity of experiences that people have - and collectively the sort of power and reach that people can have today through those open forums to and influence so I think again today we're way better positioned than even just like some 2-3 years ago.
Brian Kardel: Yeah... I mean when this came up in the previous chat I mentioned that this might require context that I hadn't realized of some my other blog posts. But this is the argument that I started making sort of late last year, which is that this openness really matters, and that a lot of these things that we think about as being these hardline opinions that are like "non-productive sorts of diversity that just prevent us from getting things done" there are not. That while there are definitely... each of these organizations has some... they have hard held opinions. But most things are not this, and what it comes down to is like you said these mundane, banal things that are more about business, which is... obviously from am Igalia standpoint I'm very keen to talk about because I think that what we do is really, really healthy for the ecosystem and that it's only possible because of this increased openness. Because we have made things more accessible to anybody who wants to contribute and that what we are building here is a Commons . And... we're currently a little bit suffering from a tragedy of the Commons... Maybe for not the greatest reasons. Like, the investment is incredibly geared toward a very few companies, and the rest of us have the economic power to do way more than those couple of companies even could. So we should exercise that power.
Rick Byers: You're right here... There's definitely a tragedy of the Commons in terms of, like, how we're advancing the web platform. You know, it's something... it is this Commons that benefits a lot of businesses but the... the investment is very lopsided relative to the return on investment that society and businesses get.
Rossen Atanassov: Agreed, +1.
Rick Byers: Yeah I should also add, you know, we might come off as a little bit whiny here... Like, "oh poor Google, poor Microsoft" you know that, you know? "They want other people to help foot the bill". I say this more like: I think it's important to Google obviously has a responsibility here, and [we're] not looking at all to shirk that responsibility. It's more just: I think it's in the interest of society if the investment was... was more balanced.
Brian Kardel: it should be diversified, right?
Rick Byers: Absolutely
Brian Kardel: Yeah... Like, you know... Ya know, that that's my point. I mean if my point is, you know... I'm not I'm not crying a river for any of you. Especially Google. I mean Google spends a, you know, near infinite amount of money on... on investing, and I'm so happy that they do. Like, I'm... but I think the world would be better if we diversify that because, you know, there's there's only so much at the agreement level of words that can be done. At the end of the day there's... like, real work that needs to be done. And... If you leave that into the hands of a very few companies to prioritize the work, that will impact what we can get and when we can get it, and what we can get done in ways that are unnecessary.
Rick Byers: Going back to this question... I think we didn't get into it in detail, about what happens if somebody wants to contribute something to Chromium that Google isn't interested in I think that's a really good question and, you know, back to my point earlier: No one should expect Google to operate as a charity, or as some kind of like... You know, a nonprofit. Google operates in its business interest, as a business. And, you know, you should just understand what those interests are... But there are plenty of examples where our priorities differ, right? Where... So... I think a great example for us to bring up is MathML, and maybe you did mention this Brian, in your last chat... But to me what happened with MathML was igalia, and some other groups, cared a lot about MathML. And the Chrome team, mostly as a whole, felt like the value of maMahtML, and the complexity it would bring to the code base wasn't worth it". And so, we weren't willing to make that investment. But rather than say, you know, "No we don't think it's a good idea" we were careful to craft a like "...yes if" message. To say, you know, as the as the owners and the code base we supported contributions that met the following criteria and one of them was like, the code base's code has got to be maintainable. It's got to be, you know, we have the spaghetti code of a layout system and so we're doing this massive investment to rearchitect the layout system... And so, if MathML can be built in a way that's modular, then that dramatically reduces the call and the concerns around maintenance burden. And then, secondly there was the question of "Can we actually make something that's interoperable here?" At the time the MathML spec was very hand wavy, you know, the test suite was not very rigorous. And so we just pointed at the guidelines we already had for what bar do we apply when deciding whether something was mature enough to ship. And, frankly, we were worried that Igalia was under estimating how much work it was going to take to get some subset of MathML to that bar, and we we were worried that people would have, you know, some different expectations that, you know... Maybe if they could do a little bit of work, they could get to that bar... and that they would be disappointed when it came to an intent to ship. And so, we tried to spell it very clearly where we saw the risks with trying to meet that high bar that we have for interoperability. And now, the consensus is pretty clear that Igalia really stepped up, right? We were clear on what it would take to ship MathML, Igalia did the hard thankless work... With Google employees reviewing many of things the patches - but Igalia did a lot of work to meet that bar... and I think, you know, I think the jury is still out on, well.. I don't know what the current frames are looking like, but I fully expect MathML to ship at some point and it'll ship in Chrome at the same time... Even though from Google's business perspective, it probably wouldn't have been a good return on investment for us to do it... But I'm thrilled that Igalia was able to do it, even though our judgment would have been not worth it.
Brian Kardel: Yeah, I'm thrilled too. So, a couple of quick notes on that... It is shaping up really nice, I'll share some of that stuff pretty soon. And, also worth noting our TAG review completed today, which is great.
Rossen Atanassov: I'm looking forward to it. Look, I... I'm a huge supporter of having a native math into into the engines, MathML... And having the ability to, at the end of the day, increase the edu market, which will benefit the most out of it. Especially, you know, having been through one full semester of having a middle school student at home, and having her do all of her work through online tools... Having better edu support will go a long way. So, thank you on behalf all of the students, future students that will benefit
Brian Kardel: In our explainer and our opening for TAG [review], we argued that this is really toward the TAG's Ethical Web Principles ... That this is a good for society. It will help in precisely the things that the web really originally wanted to help with. So I... I think it's invaluable to be able to share math for education or... Say, corona virus research, right? These things are really good for society but not necessarily in anybody's first business interest.
Rick Byers: I think this is exactly where the diversity of ideas and priorities comes in, right? it may just be that we were wrong at Google to say that it wasn't worth the investment. And so it's great that there can be these different opinions and we don't have to try to all agree, you know, there's some places where at some point there are aspects of Chrome the product the product we do have to agree but then there's a separate question of what do we need to agree about in the codebase and and so I think this is a great example where, you know, it'll probably remains to be seen I'm optimistic. I'm excited about what you guys are talking about that sounds great. I'm looking forward to seeing seeing that value materialize. And, it's great that we didn't have to try to get agreement on that point that priority
Brian Kardel: Yeah, I'm really happy about it. Does anybody else have any other things? I feel there's more you could say on web platform tests and like, even that it's only possible to have this level of interoperability and everything that it also like really raises the barrier toward the likelihood of getting a new engine... That... like... it is very interoperable now, and there is so much of it now...
Rick Byers: Sure. I liked in your last chat you were talking about this idea of raising the level of collaboration: at what level are we collaborating? And the framework around that. And I think it's absolutely true we've gone through this massive transformation. I think probably most people who use the web don't realize it. It used to be that the test suite for every engine was completely separate... and yes there was some effort to have some shared tests, but it wasn't really real. It wasn't used in the engine development process in a serious way. And now, I would say we've really crossed the threshold where the majority of browser engine work happening today is happening with a completely shared test suite, or a very much shared test suite. Certainly anything that's exposed to developers is. And, it's just part of our culture: When you do web platform work, you do test work, and that test work is shared between the engines. And this was kind of a slow transition behind the scenes but it was very much an intentional transition to raise that level of collaboration that you were talking about. Because it's in none of our interests to have there be diversity of behavior of api's, right? I mean there's special cases where you might want to apply that you might want to say, you know, maybe exactly how request storage access behaves. Maybe we do have differences of opinion of how that behaves but the default should be that behavior is consistent and we should have to make an active choice to have difference behavior, instead of the fact of what we had before, which was the default was you had very different behavior and you had to exercise this kind of superhuman diligence to transcribing the spec into code and comparing precise behavior details of browsers, and in practice we were just terrible at it.
Brian Kardel: Yeah, it's a it's a little bit of a catch-22 anyway, if you don't specify it... Because you wind up with similarities and they wind up being de facto similarities that are unwritten down which is worse.
Rick Byers: You don't hear people lamenting the loss of diversity there. You know, or that used to be this wonderful diversity of implementation behavior
Rossen Atanassov: I couldn't, I couldn't agree more on this one. I mean having having gone, again, through a number of rewrites and... if we had the amount of tests public that were contributed and are available today... My goodness it would have been so easy to stand up a new engine and and validate that chances are when you release it you're not going to break a whole bunch of things. And having that test suite having people being able to contribute to it freely is absolutely one of the major reasons why the web is as interoperable that it is today. And to Rick's point: No one is, you know, arguing about oh my goodness there was you know this browser used to render borders that way in that browser that way and you know I liked one border versus the other border more and I miss that. Like, no one is saying that. I remember more often than not looking at four different implement when I was trying to stand up something and trying to pick which behavior to switch because none of them were following the the spec and sometimes specs are not very clear and so oh my goodness yeah having having the the public test suite and having having so many tests contributed is absolutely a must.
Brian Kardel: I know Jeremy had mentioned this thing about, like monoculture , with regard to like crops... and that just having diversity just because there is diversity is good because you don't know what you don't know and I wonder... if even in terms of this are there any examples where maybe we have benefited from something like that? Like wasn't border-box kind of that Rossen? Having an implementation that worked differently than other implementations? didn't didn't border-box come from, like IE? The way that IE did it?
Rossen Atanassov: Yeah... And, it was argued by most developers and designers that setting, for example, the constraints on the border box - which is what you see, makes the most sense. Yet, the standard model was the opposite, which was setting the constraint on the insides of the... of the ... of the box. And so, as a result of this the box sizing property was was brought on to the standards so that we can we can have the switch between the two.
Brian Kardel: But didn't IE actually implement differently to begin with?
Rossen Atanassov: yes
Brian Kardel: And then... And then everybody was like "yeah I like the way IE did it." That's my recollection but it could be wrong..
Rossen Atanassov: Yeah, I think.. If I'm not... if I'm remembering correctly, I think you're right. It was, like I said, it was a quirk that was carried forward all the way through probably IE7 and then in IE8 we adopted the standard behavior and we also implemented the switch between the two so that for people who like that. And still this is one of the quite used properties out there today, oddly enough. It simply makes sense visually. Some people prefer it. There are a number of examples where there were differences of implementations and over time those that are so much remarkably better than the others prevail, and.. and.. and others tend to... tend to follow with their implementation.
Brian Kardel: Anyway... I think we just tighten the loop today, the feedback loop. Like, I don't think it... Like, unless somehow we wouldn't discover that benefit because it was like some weird vestigial appendage that was waiting for somebody to find a way to capitalize on it, I think we just find it really quickly today, right? Like ResizeObserver is an example of something that we came up with really, really quickly. We implemented, speced it, we tested it and like... It was actually shipping. And then, as somebody else came along to implement it they asked different questions. And then, as we got to use it - like real users started to use it because it was becoming, like... it was gaining critical mass... Maybe now is the time to start paying attention to it... We found other problems ,and then we said "oh well, you know, the way that... the way this browser does it makes more sense than the way that that browser does". But we did it very, very quickly. Like, it was very expedited. And I think that that is like, the right balance of those things. Like, we get the diversity, but we were able to also then sift it down very quickly and come to agreements and gain standards level interoperability.
Rick Byers: Yeah, definitely.
Rossen Atanassov: Agree.
Rick Byers: I was gonna mention the example of pointer events... That when Apple first added touch support to a browser they had this model where the API could cause scrolling to block. And when Microsoft introduced pointer events into... IE 10, I think it was, they rejected that model and had a different design philosophy of saying whether or not something scroll should be declarative not an imperative thing that you block on script on. And I think that was absolutely the right design choice and it's interesting to imagine what would have happened in an alternate world. You know, a world where maybe we were using the same engine. It was a multi-year journey to get to the point where now we have a pointer event support in all browsers and critically we have this touch action CSS property that lets you specify the scrolling behavior declarative really, and you know... It's complicated. I don't think it's... There are cases where I think the ... there's gonna be a trade-off involved. And it's not always gonna be, you know... I would hate for anyone to come out of this thinking that I'm arguing that there should just be one engine. It's complicated and nuanced and, you know, it's not even as simple as counting like that as we mentioned example of Brave.. But I am confident that this isn't a decision that one of us should be making this is an ecosystem and I really like the analogy to crop biodiversity there is something about resilience comes from diversity... And so we want to create an ecosystem that is both highly diverse but also, you know, adaptable and effective at solving the problem. You know we don't want diversity there's good diversity bad diversity right diversity that just decreases the effectiveness of the solution whether it's organisms, right? Having a whole lot of organisms that are not as effective at survival it's not something that you would be selected for in a in crops. So we so, you know, it's called it's a complex dynamic system and I think the best we can do is make sure that we're setting up the conditions such that it can evolve and the system can adapt and best, you know, be best suited to meet the needs of its constituents.
Brian Kardel: Yeah, absolutely. Rossen, any closing thoughts?
Rossen Atanassov: Yeah, I would also agree that engine diversity doesn't necessarily equate into diversity of opinions, or diversity of what is best for the web, nd what is worse for the web. The ability to continue evolving the web through open forums, standards, open discussions - agreements and disagreements is in my opinion what continues and should continue to push the web forward. I valued that type of diversity a lot. We touched upon a little bit earlier in our discussion about the part of forking, and multiple, multiple examples of forking. Forking is always on the table for any company and if there are times where that makes the most sense from either business or other points of view, I can see any company walking away with their fork in continuing to invest in to to that particular branch... And would that be better for the web or not is to be seen. There have been forks that have been very, very, very ineffective. Just the fact that they are yet another engine doesn't mean that they're bringing anything better to the web. At the same time I would strongly encourage and hope that people will go and try new engines and try to bring completely new points of view to the web. That would be fantastic to see.
Rick Byers: That's well said Rossen.
Brian Kardel: All right... I guess we're about out of time, so I just wanted to thank both of you for joining me... And, if you have any final thoughts...
Rick Byers: I just wanted to say that... One thing I'd encourage people to take away from this is this is an important conversation, and we can do better than just having flame wars on Twitter, you know? I think I encourage folks to get to know the people you're talking with as people. Try to be respectful and constructive and assume good intent. I know this is hard to do we're hardwired for all sorts of things that work against this goal and so maybe you know.. Maybe Twitter isn't always the best forum for some of these discussions so thank you Brian for for having that... For supporting this additional forum. I think we're gonna need a lot of additional forums, you know? We need to remember that we have a lot more in common and a lot more common interests then we have differences for all of us that benefit from the web and contribute to the web... And so, I just want to encourage folks to try to put the majority of energy into capitalizing on those common interests that we share and then, you know, as that is what helps build trust and a spirit of collaboration and respect for each other... And and then on top of that gives us a good great foundation to debate openly and honestly about the places where we disagree and do that in a way that it's, you know, it can ultimately help us all get better and correct our mistakes our mistakes and our biases over time rather than just dividing us and pitting us against each other.
Rossen Atanassov: Yeah I also wanted to thank you Brian for allowing this additional forum getting into the echo chambers of Twitter and just repeating the same over and over is not going to probably help things in the long run. Repeating what you believe is wrongm what you believe is wrong and just continuing to echo your frustration is always going to be less effective then if you go and try to do something about it. As we've already talked about there are many, many, many different ways of being part of the solution rather than just if you believe there is a problem of course to being part of the solution rather than just continuing to point fingers and and getting to flame wars at your opinion to specifications at your opinion to bugs at your opinion to various places where technical or strategic discussions take place at tests if your engineer patches land work fix things be part of the solution be part of what continues to propel us forward. You know, we... Incase this is not clear, coming clearly I'm gonna spell it and say that we love the web. Like, I love the web. I want the web to win. I am I've been pulling for it for this platform for most of my professional career and I love it when I see people who are part of the solution I love when people point what is wrong and and try to help us get to a better place for all of us so I would strongly encourage you to please please be part of the solution and help us get to a better place
Brian Kardell
Rick Byers
Rossen Atanassov