Brian Kardell: All right. So I'm Brian Kardell. I'm developer advocate at Igalia, and this is a kind of special edition of the podcast. My colleague Eric Meyer, who's usually on here with me is away, so he won't be joining us. But this will be, I think, the 23rd episode. It should have been the nice quarter century number, but there were two that we recorded that we didn't ultimately post for a few reasons, but it's also kind of nice because we're circling back to again, the very first one of these that we ever did. And the subject is MathML, but with a different twist, which is that it's just shipped in Chrome 109. So I'm joined here by some people from Chrome and MathML, and I don't know, do you want to introduce yourselves?
Rick Byers: Sure, I'll go first. I'm Rick Byers, I'm a principal engineer on the Chrome team, and I spent a bunch of my career trying to think about how we prioritize stuff on the team and always been a big fan of the work that happens at Igalia on Chromium.
Ian Kilpatrick: Cool. I'll go next. Hi, my name's Ian Kilpatrick. I'm a software engineer on the layout team, specifically within Blink. So I spent a lot of time reviewing code from Igalia regarding MathML, and very excited to see the shipping.
Rick Byers: And just, I should have said, Ian and I are both here kind of in a personal capacity, stands of the web, not really speaking on behalf of Google.
Brian Kardell: Sure. Sure.
Neil Soiffer: And I'm Neil Soiffer. I'm semi-retired now. I do accessibility work with MathML and I, one of the co-chairs along with Brian of the MathML working group. I got started in MathML a quarter century ago, and when I was working with Wolf from research back at the very beginning when Math was just a dream in everyone's eye and a clearly missed opportunity, and I've been pushing forward on it for a very, very long time. So I'm glad to see that I've lived long enough to have it see the light of day.
Brian Kardell: Yeah, it's too bad that this didn't wind up being the nice quarter century 25th episode because it had been nice bookend, it took about 25 years to get it done, but hey, we did it. We shipped the thing in the last browser, but only kind of, actually. I think talk in this about what it is, what we did, what we're kind of celebrating and where things go now. But I think it's a really banner day to talk about what is it, and why did it take so long to get here, and does it even matter? I think that really a lot of people who are listening probably shrug a little bit. I think it's very possible for you to spend an entire career doing things on the web and never think to yourself, 'Boy, I wish we had MathML.' So should they care? Is it even relevant to them? This is all really interesting topics, but maybe, Neil, could you give us a really, as brief as you can, how we got to now?
Neil Soiffer: Well, 25 years, I'll try and condense it into 25 seconds. We'll see. So it was probably back around 1997, talked to the then heads of the W3C, which included Tim Burners-Lee about trying to get a better situation with Math for the web. And we actually had two MathML conferences, where we convened a lot of people together, a lot of excitement. It started to get into some of the browsers. There was a plugin for IE that was done by Design Science back around 2004, which is that time was probably MathML 2. MathML 3 came out in 2010. At that point, Firefox was now supporting it. And then some bad things happened, which I think Brian can talk about, where MathML showed up briefly and then disappeared from Chrome. And so, now we're up to today where MathML-Core is getting supported by all the browsers and things have been great. In the last few years, Math accessibility has been a very bright spot for Math. It used to be everybody used images and now they use MathML, that gives them both speech and braille if you're blind. And then synchronous highlighting of various parts of the Math if you need that for say, dyslexia. So there's some really great bright spots there.
Brian Kardell: Yeah, so HTML plus, even before MathML had a proposal and they had experimental support for a way to render Math in the experimental browser that was built for HTML plus. So it's really, really a long time. But this weird window that entered and made a lot of progress was also when the W3C was very hip on XML, everything was reformulated in terms of XML. XML was going to be the future... We were going to supplant, even HTML would be XML. And that entered this weird time where we had this split with some folks who thought that the regular HTML web should carry forward and that created the [inaudible 00:05:56]. And that's the time when we began to get some implementations in the browser that were done by volunteers and Firefox was the first one. And as that was being done, it was standardized into the brand new specification for the parser. So SVG and MathML got specially integrated, so they're very, very special. And they came in this really weird time where HTML itself wasn't very mature. CSS was still a long way from what it is today and maturing and even JavaScript, the DOM APIs were not really fully cooked. And so, when Blink split from WebKit, it was wonky. The implementation was wonky. I had some problems and Google took it out in 2013 and it never got picked back up with priority because, well, it's complicated. Prioritization is really, really hard and the asks of the web are kind of everything. So I guess this gets into, why would you prioritize it? To the question of why should people care? And part of the reason that I wanted to ask Rick back on was because Rick and Rossen joined me for an earlier episode as well, and it was like during the peak of the pandemic and we were discussing how well, 'Gee, oh, my kids were attending school remotely. This MathML thing could be pretty useful.'And the need to share research and things that would be thought of with MathML. So I don't know, I think it is really societally important in ways that are maybe more subtle than the need for, I don't know, some way to measure the performance of paint or something, but pretty important.
Rick Byers: All right, maybe I'll start. So first of all, I wanted to say congratulations. I think know all three of you here, I have not been really involved in MathML itself other than trying to be a cheerleader and I think in the background a little bit, but I think you've really accomplished something monumental. Yes, I think Math is an important use case, but to me the more meta thing here is, this is the first example I know of that a major, major feature is really coming to the web, despite there not really being a business case for the businesses who normally advance the web. I know I've been impressed before with the Igalia getting Grid off the ground, but Grid was a case where we could at least argue, hey, making sure the web can build powerful apps that are modern. We could make a case for why that made sense in the Chrome team to invest some. And this whole, 'how do we prioritize things in different teams?', it is super hard, like an impossible problem. There's different opinions about what matters, but there's also different opinions about what the cost benefit trade-offs are going to look like. I remember early in MathML, I remember when you know all were proposing doing Igalia and a bunch of us were talking, how can we come up with a path where we can say yes, and we were just worried it was going to be a huge job to do it in a way that lived up to the bar we set for interoperability. And so, I'm just so impressed that y'all managed to actually pull that off because it must have been a... It's a huge investment.
Brian Kardell: It was a huge investment over a lot of years and we did manage to raise funding through many and some unusual means. But also we use it to talk about exactly this problem. So just as an example, you say the business case isn't there, but I mean, sure it is. Online education is lucrative, so some of that money could be spent on getting native MathML support. There are lots and lots of research organizations that spend lots and lots of tech money and need Math. Why not?
Neil Soiffer: I think this is very much a case of the tragedy of the commons economic thing where everybody else feels that somebody else should pay for it. You have publishers that have Math textbooks that wanted to put it online. One case, I know we did a proposal to the NSF to get the NSF to fund it because it's important for scientific research, but wasn't really quite their domain to do it either. So it just kind of gets bounced around from one place to another. But I'm really glad that Igalia stepped up, and some other people stepped up and got the funding going to make this happen because everybody else was waiting for other people to do it.
Rick Byers: I think that's exactly right, Neil. I think we fall into this tragedy of the commons problem a lot. And I know from the outside it's easy to think, 'Oh, Google has infinite money. The Chrome team has infinite resources,' but honestly from the inside, everything we say yes to, it's something that we're going to say no to, right? We got to decide, what's not going to happen in order to make this happen. And some of us talked about how could we make that case for MathML and just looking at the cost of it, we just couldn't put forth a credible argument for what we weren't going to do in order to do MathML. And maybe that was a failure of creativity on our side. Maybe we screwed up to not being able to make that case and find the right partnerships to do it.But this is a constant struggle for us for how to make that kind of case. And so that's what I meant by the business case. We couldn't make the business case within Google or we failed to, but I think it's important that none of us want the web to evolve based on the business model of any one company. I think that's a failure mode for the web. So, having a success story like this where we can expand the power of the web even when none of the browser vendors have a business case for it, I think that's essential.
Ian Kilpatrick: And one thing I want to echo and highlight is that Igalia did, one of the things when we were looking at this is the specification wasn't really in a position where it could be interoperably implemented across browsers. One of the web superpowers is when you can use different technologies together. And MathML wasn't quite in that state yet. And so a lot of the investment that Igalia put in was actually writing down and specifying how to actually rent a MathML, which was something that I initially thought, this is the lion share of the work, to be honest, and ended up in a really, really good situation. One thing I could also potentially mention as well is that the web has lots of different constituencies and different ways that you know, can prioritize features. And so there's always this fundamental tension between, do we work on... It's easily sitting in the US or western country with a bachelor's degree or whatever, wanting better Math support. But then there's also, we've got constituencies in Southeast Asia which may not have great Thai rendering support that we need to weigh against and things like that.
Brian Kardell: Yeah, absolutely.
Ian Kilpatrick: Yeah. And so the history within Chromium with MathML was particularly complex as well. We had just forked from WebKit at that point in time. And so-
Brian Kardell: Yeah, it had just landed very recently. The MathML implementation in WebKit was brand new when Google forked WebKit.
Ian Kilpatrick: Yeah, it-
Brian Kardell: It left much to be desired.
Ian Kilpatrick: Yeah. Yeah, exactly. This wasn't necessarily a top concern back then, but was definitely a concern, is that we have now and we've gotten better over time and incredibly hyper for shipping features that when we're ship a feature, we can stand by it, maintain it, and the quality at that time wasn't there. There was also some fairly big questions about how this integrates the CSS. I know that there was a very big sizing concern back then, as well as there was, this was a time when Google was aggressively creating new fuzzes against the code to close any security gaps. And MathML was a consistent source of fuzzing issues. And it was complex, but ultimately why it was initially removed from Chromium.
Brian Kardell: Yeah. It was a lot of additional code and a lot of it to do with rendering too. If your goal is, in part, to rewrite the whole thing, it makes the most sense to take that new big bundle of stuff off the table initially, at least. So I think it was not a particularly unreasonable decision at the time. I know it upset a lot of people and it did derail MathML because it never managed to get taken back up for these complex reasons that, it's hard to prioritize and you have to make a decision. You have to get it funded. But there are other modes and ways that this could have also gone. I mean, SVG is the other special one. Igalia is also in a multi-year rewrite of the WebKit SVG engine. Because no one has prioritized or done that, it has all the same weird co-evolutionary stuff with its own implementation that should be not its own implementation, it should just be part of the platform. So I think especially these two are special and very deserving of being unweirded and normalized into the platform.
Ian Kilpatrick: There's also a bit of history and how web features were previously being developed, whereas where they are now. So back in the day, this is in the nineties, someone had an idea for a feature, they would implement it, ship it in a browser, and that would be effectively. To a point where, and this is a real issue for browsers and web developers frankly, where even to this day, we just have a spec for how Table [inaudible 00:18:00] is meant to work. For example, it's far from complete, but it's taken 25 years to actually have a foundation for how that aspect of layout works. And this isn't a criticism of MathML back then, but where we moved as a web ecosystem, there's a far higher bar now for shipping these things and making sure that they're interoperable.
Brian Kardell: Yeah, I mean there was no such thing as web platform tests back then.
Ian Kilpatrick: Yeah.
Brian Kardell: But there actually were implementation reports and some things I had tests, and this brings me to an interesting little segue here, which is that I didn't even myself know about this, but in 2010, I suppose, there is actually a W3C recommendation of MathML for CSS, which was an attempt to reconcile these things. And it is interesting that at least some of the choices overlap and there is this test suite from back then when you look at it though, and you look at Safari 5.1 at this point scored an eight out of a hundred. So yeah, it's pretty interesting. Well, all the browsers now are scoring really exceptionally well on the basic stuff. And then there's some of the new ways that CSS explains and integrates with MathML needs to continue to be iterated on in the other browsers. So there's degree of support and now that we have those specifications we have and implementation, we need to continue to iterate on those other ones.
Neil Soiffer: Yeah, I think it is important to say that way back in, what was it, 2012, 2013, and even before in 2010 when that CSS attempt was made, there are some differences between the way Math needs to be rendered, especially with this stretchy characters and the way the rest of the text layout goes. And CSS has made a lot of progress that allows stuff to happen for Math that couldn't happen 10 years ago. So I think the time has gotten better in that sense and there's still some more progress to go. There are a few compromises that are still being made in the code that hopefully, over time, CSS will get better at and those compromises go away.
Brian Kardell: Maybe an example of this is that to really render all the really good Math, you just need a math font, you need one. And now there are things we think about with in terms of securities, we don't want you to know which particular Math font somebody has installed. So all these things come together and over many years then we decide, 'Ah, well we need is font family Math.' So you can just say, 'Well, I don't know which Math-y one you're going to use, but it needs to be Math.' So I hear all kinds of interesting things over the years that come together and make this easier. I mean, even midway through this, we are very dependent on layout NG, all that stuff is very invisible to the outside world and you're like, 'Well why does it take so long?' There's lots of dependency.
Rick Byers: Yeah, I wanted to ask about that when Neil was saying that CSS didn't support this stuff. Ian mentioned earlier that complexity of the code base was a concern as well and Layout NG and the other parts of the rendering engine rewrite that happened in Chromium, did that change the dynamics and the cost benefit trade-off significantly?
Brian Kardell: I'm not a implementer so I couldn't speak to that, but from what I gather, yeah, I think there was a general impression that Layout NG was pleasant to use.
Ian Kilpatrick: I'll take that as a high form of praise. Yeah, no, from reviewing the MathML code going into Chromium, everything is very, very straightforward from a maintenance point of view, and this is one thing that we look at when introducing new features is, are these going to create a massive headache for us that we're going to be fixing issues every other week or crashes or things like that. And the code coming from Igalia was exceptionally high quality. I know that you have plans to continue working on MathML, but for some reason if you didn't, I could feel confident that the team at Chromium could maintain the MathML implementation, relatively straightforwardly. It wouldn't be a huge traditional tax on us.
Neil Soiffer: So I think this is a good time to give a shout out to Frederick Wang who did most of the coding. So I think a big pat on the back or thumbs up to him for all the work that he put in.
Brian Kardell: Yeah, Fred is the hero I think, I don't know, Ian if you want to talk at all about discussions with Fred over the years? Fred has been a huge, huge champion and also necessary person in convincing that this is a achievable thing.
Ian Kilpatrick: Yeah, I think without Fred we likely wouldn't have seen MathML and Chromium as quickly as we have. It would've likely taken a fair bit longer. Fred is very, very quick to pick up on all the minutia in layout, different baselines that you need to deal with, all the different modes that we use for sizing and measuring things and very, very quick to pick up on this. And then also had a knack for, or has a knack for determining which trade-offs to make when there is a trade-off to be made between what the desired outcome for MathML is and what the sort of platform convention is as well. And he navigated that thread very, very well over the past couple of years.
Brian Kardell: I agree. Also, I think deserving of a nice shout-out is Rob Baus who did a big, big chunk of the initial work in our prototype.
Ian Kilpatrick: And I think also in the code as well. I think he contributed a non trivial amount along with Fred, as well.
Brian Kardell: Oh yeah, yeah.
Ian Kilpatrick: So together that did great work.
Rick Byers: So I'm really curious, Brian, if it's okay, I'd love to understand more about how it is that this happened? And in particular I'm always interested to try to understand the macroeconomics of how the web works. So can you share a bit about what do you think it cost Igalia to build MathML? And I guess if you want to talk about across all the different engines, the work you've done and whatnot or Chromium specifically, and where did that money come from and why?
Brian Kardell: I think so it kind of goes circles back to your original question about, is there a business case there or why would somebody do this? Why would you prioritize it, et cetera? So Igalia is for anybody who doesn't know we are a cooperative, everybody receives equal pay, we have equal shares, so we take contracts, money comes in, it gets split equally, but we still have a business and a budget and all that stuff that we collectively maintain. And one of the things that we do when we create our budget is we allow people to submit things that we would like our peers to support from the business standpoint. And that can be everything from reforestation initiatives and NGOs that we believe you should fund. And then, collectively we all agree to take a little less home so that we can fund those things. But we're built on open source and free software and we are very close to that world. We see a lot of the challenges there, missed opportunities and things like that. And so, we have the ability to submit for investments for things that nobody is currently funding but we think deserve funding and deserve to move forward somehow. And the question is will we fund it? So you have to write a proposal. Initially this came up about doing some work on MathML in WebKit. That was years ago. We sponsored all that work, funded all that work, got it done. And then, there was another effort there to try to drive something forward enough to make a proposal and maybe fund it through grants and crowdfunding. So we did an initial thing based on also writing a grant and getting initial money for the project from the National Institute of Standards Organizations and the Alfred P. Sloan Foundation. I think that grant was like a hundred thousand dollars paid for a big, big chunk of the prototype and restarting standards, proposal efforts and all those things. Then we also got small amounts of funding, few thousands from Pearson and APS Physics. And then there was a period where there was no more funding to be had for about a year, year and a half. And so Igalia stepped back in and funded the work. It slowed down slightly toward the end there, but we kept it going the whole time. And then we started Open Collective actually after discussion with Neil who's here with us that, perhaps we could try this. So through there we have collected another 75,000, I think 78, something like that for development on that. Rick actually also put some money into that, sponsored as a person, made a contribution as did I. So yeah, there are a few contributors in there. Two really, really significant ones being Neil Soiffer and Murray Sargent who, between the two of them funded $75,000. So that's pretty huge. But yeah, I mean, think the point here is that we look for ways to diversify and we're completely, constantly looking and trying to raise awareness and make it possible for people to understand and see business cases and the sort of things that we can do if we take some shared interest in something. We also did our Open Collective that funded focus-visible in WebKit the same way.
Neil Soiffer: So this is probably a point in time to point out that, well the work's not done yet. And so, how's the funding going to happen going forward?
Brian Kardell: It is a really good thing to point out in my opinion. Well, I can say that there are a lot of people who are interested who are either interested because they think it's the right thing to do, they wish a thing existed, they think it needs priority and they can go and talk to their organizations and make the case. But also even to small amounts if we just get together and fund things. Small amounts collected together go a long way. I mean, I joke that when I was a much younger person and Google came along and they did their IPO and explained how they were going to make their money, I laughed. I mean it seemed ridiculous. It sounds like the plot to Superman 3 we're just going to collect all the little rounding errors together and then we'll be billionaires. But Google makes a lot of money that way, collecting comparatively small amounts, just lots of them. We can do the same thing through Open Collective. So you could go and throw a dollar a month or $5 a month or $10 a year, it really wouldn't take much for a large group to add up. But also these companies that make education software and of the organizations that need Math on the web, this is small marketing dollars to this would get you there very quickly.
Neil Soiffer: Yeah. So I'm kind of curious to see now that the large base is laid down, whether places say that want to see the textbook publishers maybe that want to see elementary Math supported that the research community doesn't really care about. It's a smaller ask and so maybe, you'll have more of your traditional Igalia funding model where somebody says, 'I want to pay for this feature,' and you guys add it. Do you think that's going to happen?
Brian Kardell: Yeah, I mean it definitely could happen. One thing that you see there sometimes once we have a feature that's in the platform where there's a browser that for whatever reason can't prioritize that. So not to pick on anybody in particular, but let's just say that Firefox has a lot of work to do in some things in MathML and they just can't get it prioritized because there's so many other things and right now they don't have the people to do all the things. So it falls to a lower priority. If that's the thing that's holding you back, then your company says, 'Gee, we would sponsor fixing these three bugs or these five bugs,' or whatever. That definitely happens more with things that are just gaps as opposed to complete missing implementations. Yeah. I think that is definitely a possibility is another way. In that way it's good in that, I don't know if it was Rick that said this before, but your ability to have a say also comes with how much are you bringing to the table. So if you were me, let's say I contribute $5 a month, which is total $80 this year so far to this collective. I don't expect to be able to say what it is that gets implemented in Firefox. You know what I mean? Prioritize, not implemented. But if you say I'm willing to fund specifically the implementation of fixing these six bugs in Firefox, then well you can have a much more specific say that way. So if that's what you really care about, then you should probably either hire somebody which totally could be Igalia, we would love to talk to you, or find a way to make those commits yourself.
Ian Kilpatrick: Well one thing I wanted to say on prioritization quickly is that for people listening, it really does help if you can, in the Chromium bug tracker you can start a particular bug, that really, really helps in terms of prioritization and then actively seeing what issues people are running to, day to day. For example, one relatively large area focused that we're slowly working on is fixing a whole slew of print bugs and also adding some new print features next year as well. And the reason that we are able to prioritize that work is because in the layout bug tracker, these things surface up into our top 10 bugs for example. So please star bugs if they are directly affecting you, it really, really helps.
Rick Byers: Brian, I'm curious to ask more about related to what Ian saying, we have all these different ways of prioritizing and Neil mentioned that this is a tragedy of the commons, and how do we allocate resources in a commons? I'd love to understand more about this, how Igalia kind of chooses the projects that you said you choose to take a little less home in order to invest in some things. Can you tell more of the story of how is it that Igalians got together and said, 'Hey, MathML's is one of the things that we should fund.' Why MathML and not something else? And how do you see this kind of evolving over time? What other sorts of projects might fit that kind of funding model for a Igalia?
Brian Kardell: Well, let me start with something that's almost related to what Ian was saying, which is, it depends what we internally star. So Fred was a very active champion of MathML, what's different and unique about this, and then we discuss and vote. So it's a little bit more, I guess democratic, but the first thing is somebody has to propose something. So it starts with people championing it in the first place and making their proposal. So when we did our open prioritization experiment, I don't know if anybody remembers that, but we took six different features that were what you could call shovel-ready projects. They weren't controversial, they weren't especially involved, they're relatively small projects that were relatively uncontroversial, just for whatever reason you couldn't get implementation priority on them. We chose things at different stages of development. So is this the second implementation or is it the third implementation?Is it the prototype that has been in specs and is uncontroversial, but nobody has implemented? We chose some things in CSS, some things in HTML and then we put it out there, here are six things. But internally there are thousands of things we could have chosen, literally thousands of things that could have been on our list. So how did we wind up with those six? Well we had people internally propose and champion them and then, we chose a group that we could put to the public and then the public helped vote with their wallets and said, 'We think this is the one that you should do and we'll give you $5 or $10 or a hundred dollars.' And then we have some organizations that agreed to match funding and things like that. Everything gets chosen by, in some way, you need people who are championing it and that could be starring a bug or writing about it or tweeting about it or most directly, find the funding for it.
Rick Byers: That's awesome. Thanks.
Brian Kardell: I don't know if I answered your question really or not, but.
Rick Byers: I mean this is same conversation you and I have had for years. It's just trying to imagine, could we imagine a world where the scales, the web developer community for example, is making pitches and voting on them and trying to prioritize the things and somehow fund the things that would actually bring the most value, biggest bang for the buck, for most people.
Brian Kardell: It is really tricky actually because sometimes the most valuable changes maybe don't even have the most obvious way to tie back to that. I think offscreen Canvas is an example that, it's MathML in the sense that how many people are, 'This is the most important thing, give me this, it's a huge deal,' but actually it is a huge deal because there are just not that many ways that people work with the Canvas and so you can sort of centralize how many things need to be updated and then, wow, every single user in real life just gets it. So it's very easy to get those improvements to people on all of their mobile devices and their low end embedded devices and things like that, without making everybody in the universe touch code. They just can easily get this sort of seamless thing that benefits real actual users.So I don't think that there are a lot of developers out there clamoring for that one, but it has an outsize impact for end users, like all of us. Anybody trying to use a nav system in their car or on their mobile phone if it's a little bit laggy or whatever, prioritization is difficult even given all the exact same inputs. You can see from open prioritization that one of them won but it was actually pretty close among the top three, I think. We won't universally agree, figuring that out is challenging, but the one thing that definitely works is if you really think that there is a thing that should exist, finding a way to take the cost of it off the table makes that much easier conversation. You're not asking everybody else to choose A over B, you're saying, what if we could do A and get it paid for?
Ian Kilpatrick: One side note I'd like to bring up in terms of prioritization is even when you have the same signals you can sometimes lead to unexpected results. So one easy example I always bring up in the Chromium bug tracker is, if you've got say a feature and completely new feature that has say, 30 stars, but you have a bug that various people are hitting that has 25 stars, that bug is often more important and should be ranked higher, so to speak, just because of how annoying and frustrating it is to people versus that new feature. So even with the same inputs, it often leads to different prioritization outputs depending on fundamentally what value.
Neil Soiffer: I think I am making a bit of a guess, but I think that's been one of the problems with MathML implementation is that a lot of programmers have shied away from Math. It wasn't one of their top interests. This is just a guess, but Igalia had somebody that was championing it, where it was an interest of theirs. And so, I suspect programmer interest is also one of the things that determines when there's a bunch of options available. If you have some people that are interested in working on it because it's cool and sexy and fun to do, I suspect that makes a difference too.
Brian Kardell: I mean I don't think that this is particularly different even in print. Back in the days when we all went to libraries and bookstores, you could walk into a physical space and just seemingly endless amounts of books and just like the web, it's predominantly not Math but that it contains Math is really, really important. I don't think it's that different here that you shouldn't expect that something needs to be the dominant thing in order for it to be really, really important.
Rick Byers: I think sometimes we fall into a trap using tools like our bug stars or we use other data on the Chrome team to try to figure out priorities and whatnot. And I think it's good because it brings some rigor and scientific discipline to some of our prioritization. But also, it can be a trap to if, what is it? Goodhart's Law? A good metric ceases to be a good metric if you're... I'm going to bungle it, but anyway, if you're over-focused on it. And so I love Neil's example of its easy to say, well Math isn't used that much and actually it's okay because mostly people can use images to get around it.
Brian Kardell: I'm actually, I'm really glad that you mentioned that because it's a bit of a misconception and it is actually a good reason to explain, why care. A lot of people would take the approach of putting their Math in an image that exists on the web today in a bunch of cases, it is not really a good solution. That's because not just accessibility reasons, but the things that make that an accessibility reason also have lots of other knock-on's. So Math is text, part of every writing system and text is sort of the web superpower. Almost everything designed around the web is built around these ideas about building trees of text and content and how we style those and make them interactive and how we deal with things like copy and paste and accessibility. And you can't do any of that with images. Images aren't good to put text in for just so many reasons. They don't take part in styling. So if you happen to be using dark mode, that is going to look real bad. If you have styled your text, it's not going to participate. You want the text to be blue, forget it, it's not going to be. A lot of Math is embedded in text, it's right in the prose. Images are a terrible solution to that. They cause all kinds of reflow. They can be asynchronous, they can just drop off and you don't even know what's supposed to be there if you don't know the aspect ratio that it should be. If you haven't accounted for all the ways that this would rescale, you can create lots of situations where this text is just totally unreadable. So yeah, there's actually a ton of reasons why a way for the platform to deal with Math as text and understand Math as text and participate as a normal participant in all the things that the web does is really important. And that is kind of what MathML does.
Rick Byers: I know MathML is just coming out in Chrome 109, which is in beta right now, but I was just looking at our public use counter stats and for the population on that beta version of Chrome, it looks like it's already one in 300 of all page loads are using MathML if the metric is right. And I'd love to just hear what are the actual applications, deployed applications that you all are most excited about, who do you know that's actually using it excited or excited to use it more? Where is I as a browser user? Am I likely to see this cropping up more over a year or so?
Neil Soiffer: It's hard to say because it's just one of the phrases that I've said over the years to try and get people interested is that, every day in every classroom from K through 12, a kid is sitting down to do Math. And the fact that they couldn't really do anything interesting on the web, just held back a lot of stuff. But if you look now, most of the learning management systems all support Math in some sense. And via MathJax, which has been a great, great feature to get math out there, most of those sites are actually using non images now. It's a big change in the last five years, I'd say. Probably, 80% of the web is now using it and once MathJax switches over to using MathML as underlying rendering, instead of using its current CSS or SVG, it'll be faster and think people will just appreciate it better.
Brian Kardell: Wikipedia has a few million MathML equations, I think. Do people use Wikipedia?
Neil Soiffer: [inaudible 00:49:01] Wikipedia or the Wikimedia people are working on putting out native MathML because it's just a better way and faster way to get the Math out in pages.
Ian Kilpatrick: I suspect for the sort of larger sites, the Wikimedia folks, they will likely sort of have to do QA, so to speak, of MathML, the different browsers to see if they can enable it or whatnot. And so, that's sort of where Igalia's work over the past couple of years. Actually writing down what should happen for all of these edge cases will go a very, very long way in getting all the browsers to behave the same for these different various cases.
Rick Byers: That all makes a lot of sense. The other thing you said that I think is really powerful is mentioning libraries like MathJax just being able to upgrade all of their existing users or all the existing use cases. We worry all the time on the web platform team about, how are we actually going to activate new things at scale? Once something's built and shipped, it's really hard to get anybody. You can scream until you're blue in the face, but how much better it would be if web developers just did something a different way. But at the end of the day, everybody's got to make a cost benefit trade off for their own prioritization, but knowing that MathJax is used all over the place and they can just flip a switch effectively, that's a really powerful and deployment tool.
Neil Soiffer: I think, like Wikipedia, they need to wait to make sure the quality is there in all the browsers, so they probably need to see the test results go up a little bit better. And maybe a few more features, which ones that I've run across having written some poly fils or transforms to fill in the gap between what is in the full MathML spec and what's in the Core implementation is it takes advantage of Core's ability to put CSS on the MathML and that's not yet in all the browser implementation. So, it means the poly fils don't work everywhere. So yes, there's definitely more work to be done to align everything onto the same spec and I think that's the least sexy part of doing anything, is to deal with these last a few meters or whatever of implementation.
Ian Kilpatrick: I think though that the integration with the sort of CSS engine and whatnot, it leads to some really cool use cases. So for example, you can put input elements in various text areas inside of MathML Code. Chrome is currently working on anchor positioning for example, which that's you position an element relative to another element. So if you create something that can point to a specific part of the MathML markup, things like backgrounds working consistently, and so you can highlight or style various parts of the equation. I think that should lead to some pretty interesting use cases if people experiment with that.
Neil Soiffer: Yeah. And I mean just being able to mouse over something and have a tool tip pop up that explains the Math and that has some Math inside of it. So that would be great.
Rick Byers: Neil and Brian, and especially Neil, you've been working on MathML for a long time. I hope you're feeling some sense of satisfaction and accomplishment. Sounds like a long, probably frustrating journey?
Neil Soiffer: And as I said, I'm glad to see that I've lived long enough to see it show up in all the browsers. It was seeming a little bit touch and go whether that would actually be the case. But yeah, I'm greatly relieved. I have to say, having seen MathML show up briefly and then disappear, there's still a little bit of fear that something's going to happen to cause it to go away again. I don't know what would that would be. I certainly hope it's not going to happen and I know the community will greatly benefit from this, but I also realized that as we've discussed, the uptake won't be immediate. People have to get a sense that, it's here for real, that it's interoperable, that it's high quality and that just takes a little bit of time to happen.And I think part of that is it disappeared once, so now they have to make sure that it doesn't disappear a second time before they have that confidence to really go ahead and use it. So, I suspect even though it's coming out now, it may be a year or two before it's really adopted widely, but we'll see. Maybe it'll end up have instant uptake.
Rick Byers: Yeah, that makes sense. Yeah. Congratulations again, it really does feel like, to Neil's point about there's still some risk here, it really does feel to me like you've been pushing this boulder up the hill for 25 years and there's a lot more distance to cover, but now you're covering the distance on the other side of the hill. It does feel like this is now probably, almost certainly, part of the web forever now.
Brian Kardell: I think it's really great to be at this moment where we achieved this thing that seemed unachievable and also to recognize that there's a lot more climbing to do.
Neil Soiffer: So again, I want to thank all the work that you and the rest of Igalia have done because some people have funded a little bit, but Igalia has put in a lot and they've done it with their time and expertise and most of the other people have just sat back and maybe gave a little money and otherwise, cheered you on.
Ian Kilpatrick: Yeah, huge congratulations to Fred and Rob and everyone else who helped make it happen in the end.
Brian Kardell: Yeah. And I think huge thanks to the community group who then became the working group, in getting all that started again because it was not easy work. There's a lot of volunteers who came and gave a lot of time to figure out and debate things.
Ian Kilpatrick: And to be clear, there's some not easy questions as well. It wasn't just, 'Oh, let's just write down whatever Firefox was doing previously or whatever WebKit was doing previously.' There was a lot of nuance and complexity that needed to be sorted. I think one potential example, which springs to mind is, and this isn't throwing Firefox under the bus or anything like that, it's just what was implemented way back when, is that if you added one additional element or didn't have the right number of elements under a certain tag type, for example, it would then just go, whoop! To the whole formula. 'Nope, sorry, we're not rendering this,' huge error type of thing. So there was a lot of complexity to be worked through about what to do for these edged and failure cases and how to fall back basically, for example.
Neil Soiffer: Yeah. I think ultimately we got to a very simple solution and one that's pretty predictable, well, is very predictable and is a good one.
Brian Kardell: Yeah, I just wanted to say thanks again, everybody, for coming on and chatting with me on this episode to celebrate achieving this thing and yeah, thanks so much.
Ian Kilpatrick: Thank you for having us. This was a lot of fun and congratulations again.
Brian Kardell
Rick Byers
Ian Kilpatrick
Neil Soiffer