Brian Kardell: Okay. So I am Brian Kardell. This is part three of a series that we've been recording with different guests talking about web ecosystem health. Effectively, this is just a place for us to come and have long-form conversations on topics that we historically don't talk about for some reason. We talk a lot about how many rendering engines we have and a lot of concern around that, but we don't talk about how we got those rendering engines.Or are they healthy? Are we going to be able to keep them? Why does it look that way? What can we do to make it better? Is it more or less healthy than it was in the past? Are we going in a good direction or are things getting worse? So carry on this conversation today. I have three ex-Opera fellows here. One of them also is involved with another rendering engine, Prince XML. We'll talk about that too. So if you could just introduce yourselves briefly.
Håkon Wium Lie: So my name is Håkon Wium Lie and I have been on the web for a very long time. I proposed CSS in 1994. I joined Opera software in 1999 and I became the chairman of Prince, which you mentioned briefly, in the 2000s. So the web rendering engines and standards and such have been very near and dear to me. I'm doing many other things too these days but I still have a passionate belief in the web that we need to do to take care of it and hold it to high standards.
Vadim Makeev: All right. I'm Vadim Makeev. I'm from St. Petersburg, Russia. I used to work at Opera in Opera DevRoll team together with Bruce and basically, promoting or representing Opera browser in Russia and Russian-speaking countries. I'm not a browser engine developer.I'm just a frontend developer, but that's the reason why all the web standards and the health of our industry or diversity of web engines is very important to me. So that's why I'm a good friend of web standards and yeah, I'm here to discuss what's going to happen next with the browser engines and such.
Bruce Lawson: Hi, I'm Bruce Lawson. I used to work with Vadim in Opera software in developer relations and for the last 18 months of Opera, as we knew it, I was deputy CTO. So I was the Robin to Holcomb's Batman. I've long been interested in the web since I first discovered it in '99 when I was living in Thailand and it's changed my life. And I got into it and published the first book on web accessibility. So like Vadim, I'm not a browser engine developer.I'm not going to say I'm just a frontend developer because front end developers are not a secondary occupation. But I do some frontend development, mostly I'm accessibility in web standards, but like Vadim, I keep a close eye on what's going on because I believe that the more diversity we have, the healthier the ecosystem is, and I want the web to win.
Brian Kardell: So since neither of you mentioned it, I will mention that Vadim and Bruce have started a new podcast of their own called the F Word Podcast. It's been very good and interesting for me to listen to. So you should check that out. I was recently a guest on there. I think I was their first guest actually.
Vadim Makeev: Oh, yeah. First and only.
Brian Kardell: Yeah. Okay. So I guess let's talk about what everybody agrees to about rendering engines is that having more than one seems like a good idea and that having more than one means that we have some degree of inefficiency. I posit that standards always also requires some competition and some failure. I feel like we've made some mistakes in the past trying to skip that step, but I don't know.What do you think? I think, how do we get the engines that we have today? You can track really two main. There's the Gecko, Servo engine and the WebKit-oriented lineage. There used to be another one that was Opera's Presto, right? There's an interesting story. Who wants to tell it?
Håkon Wium Lie: Well, I can tell it. Presto was Opera's rendering engine indeed. It was our proprietary code that we rewrote and launched in 2003, I believe. And the roots of that engine, of course, came from our headquarters in Oslo, which was in Volderma Franas Gata. And in that very same building was also TrollTech. It was a hub for internet startups at the time.And one of the employees of TrollTech was Las Kinol, who was, if not the person, at least one of the very key persons in taking KHTML and building it out as a code base that Apple and Google and Microsoft even now build their browser on and even Opera. So although there's some discussion on how much work did Las do on KHTML in that very building but I think we can say it's a cradle of two web rendering engines in one place.And actually, last year, we were very happy when the Historical Society of Oslo agreed to put on a plaque, one of these historical plaques that you find that often they go back to the 16th century telling us what happened. Then this plaque that we put up on this building tells the story of two rendering engines and how those two engines really changed the world in the sense that they allowed us to surf the web on mobile phones.
Brian Kardell: It's amazing.
Håkon Wium Lie: It's amazing. I can read the pockets. It's very short. In this building, the Opera web browser and the QT toolkit was developed in 1998, till 2012. The rendering engines, Presto and WebKit, made internet on mobile phones possible.
Bruce Lawson: What I like about this story is that usually, these historical plaques, or certainly in the UK, are put on beautiful old buildings. The first half of my career at Opera was spent in '98 Volderma Franas Gata. And I believe I'm not doing it too much of a disservice, Håkon, by saying that it was many things, but that building is not noted for its beauty.
Håkon Wium Lie: That's indeed correct. That's not why we love it.
Vadim Makeev: Yeah. It was not only ugly from outside, I would say, but it was really hard to navigate from inside.
Brian Kardell: It was also great because all the programmers and others who have worked on these rendering engines came together and we had a rendering engine meetup, a giant one. And this is, I think, maybe the first and probably the only time the word rendering engine will end up on a historical plaque.
Bruce Lawson: I suspect you're right. But it's interesting because I'm not Norwegian, Håkon. I hadn't really understood what the plaque said, but it's interesting. It says, "Made the web possible on mobile phones," because one of the great things about Presto from … I mean, I wasn't there when it was developed initially, but one of the great things about it is because it was designed to go underpowered devices and mobile phones from its very inception.It was incredibly lightweight. I recall that when we experimented putting blink on the Opera mini servers, which are proxy servers for underpowered browsers in India, Bangladesh, et cetera, we needed something like eight times the number of servers to run Blink for the same number of users as we did Presto.
Håkon Wium Lie: Yeah. No, that's true. Presto was indeed resource-effective. And there were several reasons for that. First, we didn't have all the programmers that Opera … we didn't have access to all the funding that Netscape, for example, had in Silicon Valley. We had to hire all those programmers. We had to rely on only a few and they couldn't write that much code, so it tended to be very compact.And also, we were very conscious that we wanted Opera to run on first low-end PCs, for example, a 386 that your uncle had and wanted to put him on the web. He had maybe a modem in 1999. And in order to run on that computer, you had to be very small. So for a long time, Opera's code fit on a floppy.This was up until we added CSS, then we got past that 1.44 megabyte mark. So we couldn't use the slogan fits on the floppy any longer. We had to change it to almost fits on the floppy, which doesn't quite have the same ring to it.
Brian Kardell: I wanted to ask, my article that launched this conversation a little bit, I talk about the fact that you can divide the web up into a few different eras and say these broad statements about it. And one thing that you can notice today is that all of the engines that we have are open source for browser. The three browser rendering engines that remain are open source.And we used to have more, but the more we're proprietary, that's interesting because it opens up a lot of interesting discussions. In some ways, I posit that the open source nature of KHTML and WebKit and Gecko as well have been a boon because should accompany ever … as they tend to do as we know … change or disappear, we don't just lose that investment. So I think that part of it is actually really healthy.But there's another part of this, which is who funds the development of these? And that has changed because the proprietary ones maybe had some business models behind them in some cases. I think Opera, that might be the case. So can you talk about any of that?
Håkon Wium Lie: Certainly. Opera was founded as a commercial company. There was a market for better browsers. People actually bought browsers. They bought licenses of Opera in enough numbers that it helped pay for the programmers.This was before search engine, so there wasn't an option of getting a cut from search engines. We had to actually … Opera had to sell licenses in order to survive. Now, a lot of Americans paid for that license, not so many Russians. But we became very popular in Russia still because they didn't-
Vadim Makeev: Oh, yeah. I can confirm I bought my license.
Håkon Wium Lie: You paid for it. You were the one-
Vadim Makeev: Before, yeah. One and only. Before joining Opera. But because it was a gesture of appreciation rather than a need because the first result you would see in Yandex by searching for Opera serial would be a serial number. And Opera wouldn't even check if it's unique or if it's used before.It wasn't like a license in Microsoft Word or something, no. It was just a serial number and I guess, Opera trusted and never tried to prosecute this illegal usage of serial numbers, I guess.
Håkon Wium Lie: Yeah. We never went after anyone for doing that. And then Opera went into a model where we had advertisements in a little window or banner area in the right-hand corner. That didn't work so well either. We had some income, but it was mostly to force people to buy a license. I think if there's one key mistake we did at Opera, it was to not open source the code.Firefox on the other hand, they started out being an open source browser and they got a lot of attention from American journalists because they were seen as the new thing. Open source was very politically correct. And the fact that they didn't have ads was also good. Journalists were hesitant to recommend Opera to their readers because you would get to ads as a result of that. So from that perspective, Firefox was more compelling.And for a while, even though I think Opera was a better and faster browser, Firefox got much higher growth rates than Opera. I think we could have changed that. If we had been open source at the time, we would have taken more of that growth to Opera and the world would have been different.
Vadim Makeev: After Opera Mini became a thing, became quite popular in the world, I think it was too late to open source because it was a pretty unique product. It was one of the biggest streams of income.
Bruce Lawson: Although I do think that we could have opened sourced it and continued with making money from Opera Mini because open sourcing the code is one thing, but having massive glacier code server firms is what actually drove Opera Mini. And that takes an investment. Whether or not we should have opened sourced Presto, I don't know.And the thing is once we had retired Presto from the main mobile browser and the desktop browser and adopted Blink, Presto was still running Opera Mini and still is in Opera Mini extreme mode. And people used to ask me all the time, "Why don't you open source it?" And the answer was basically for expedience. You don't want to open source a product just by stuffing it all on the internet with an Apache license.If you're open sourcing a project, you need to curate that to document it and to have somebody taking pool requests, et cetera. And I just don't think there was the appetite in the company to spend lots of time and energy curating something, which we had made a business decision to move away from. Presto remained pretty static after we went to Blink.
Brian Kardell: Well, I'd like to pick up on something you said there, Bruce. You called it a business decision to move to Blink.
Bruce Lawson: That is true. This is true.
Håkon Wium Lie: And it's more complex than that. From my perspective, at least I think the decision was not made by the accountants at Opera. The decision was actually made by the programmers. They saw that they were spending a lot of time keeping up with the bugs of other browsers.They were always a little bit behind and if they could instead join forces with those other browsers in an open source project, their code, first it would reach more users, which is always a good feeling for a programmer. And you would also feel part of a community, something that was moving forward. You were looking at the future rather than look back. So I remember … this is 2013, right? So it's a long time ago.But still, I remember it as being the technical decision that was made and the accountants were probably happy that they didn't have to employ those 100 people playing catch-up. We could use those people for other things or for contributing to an open source project, which felt good.
Brian Kardell: I think that not a lot of people have a good grasp on what it takes to make and maintain a browser. There was a long history early on of browsers being interoperable enough to get something done, but very painful. And the interoperability bar on the web just keeps going up and we keep getting more features. So it keeps growing. And I think there's actually interplays with market share.At some point, it appears to hit somewhat of a tipping point where enough of your users use that that people begin only testing on that. Some fraction of properties begin suggesting that you should just get that browser. You wind up with lots of bugs because somebody has to implement first and the one that has the largest market share also winds up having largest budgets.So it winds up being something of a feedback loop. There are still, even to this day, lots of things that we discover, "Oh, that is not actually written down anyway."
Håkon Wium Lie: That was a long and tedious battle for Opera to make sure that all the banks in America worked in the Opera browser and we couldn't really open bank accounts all over. It's hard to test. It's hard to verify. It's something we put a lot of resources into, but it was never very fancy or entertaining work.
Vadim Makeev: So I used to work with big Russian companies and small ones as well to make sure that the code they shape is compatible with Opera and also Opera engineers know what their needs are … I mean developers' needs. And the same was the case for Latin America, US, China, India and many other countries in the world. And that was our attempt rather to keep up with this thing.But I remembered this line, this graph at our Jira incoming box, the red line, it was always going up, incoming compatibility bucks. And then there was a line, a green line of a number of bugs that we fixed. And they would never meet even with 100 people working on it every day. So we were just falling down.
Bruce Lawson: Yeah. And those bugs were reported to us. They weren't bugs that we'd found. Yes, it was a Sisyphean task of doing the web stuff. And one thing I remember though did get better because at the beginning of my tenure, 2008, and we would write to people and say, "Hey, do you know your website doesn't work in Opera Mini?" And they go, "Yeah, whatevs," if they ever got back to us at all.But towards the end of my tenure at Opera, big companies would approach me at conferences and say, "We really need to be on Opera Mini. How do we go about it?"And I think that was a lot to do with the realization that Silicon Valley companies were saturating their own markets and the realization had come to them that not only was there a world outside Europe and America, but actually, that world would be the demographic growth for the next few decades. And if you aren't in there now, your competitors will be.
Brian Kardell: Even as a consumer in America, I just lived in rural places with very terrible internet and as such, I chose to only invest in a low-end device. So I used as my primary device, very cheap phones. Aand those things sell a lot. And if you recall, when we went from … everybody had desktop browsers and that was it. And you imagine, what is the total possible market of desktop browsers? Well, it is limited like this.And then suddenly, mobile phones came along and suddenly, it's at least that times two, but it's even higher because you can buy these cheap mobile devices that plenty of people have them that don't have a desktop computer even, right? That is their computer. And then tablets came along and it's like, "Oh, well now there's a whole nother thing." What's interesting here is that in Igalia, we do a lot with embedded.That market is like that. There billions of new devices coming online all over the world and they actually share something because the embedded devices tend to be very underpowered.
Bruce Lawson: All browsers that are not the default ones on the device have the problem with, "Well, the default one is good enough." Chrome on an Android phone is good enough. Safari on an iOS device is good enough. And even if it isn't, bad luck. So a non-default device has to really work hard to be not only better, but demonstratively better and be demonstratively better to somebody who doesn't really understand what a browser is either.
Brian Kardell: Yeah, this is actually a really tricky thing on the topic of ecosystem health. It has been difficult to find the right way to bring it up or the right context to bring it up in. I feel like there are several things that we've shown if you look at the history that play into this. So one is when IE began being pushed with the operating system, that had a very clear effect because most people are learning about it for the first time.Their only experience with the web was Internet Explorer. And so it just had to be good enough, right? It just had to be good enough. And it kept getting better and it was able to maintain its market share and dominance. Now, that's pretty standard. There's no operating system that doesn't ship a browser with it. And generally, they're pretty good, so this isn't a problem.But then there's a challenge to that, which is that it's not uncommon to have an iPhone, a Windows, desktop and some Linux embedded system in your house. And the integrations then are more difficult unless you then also control a services tier.And when you get on those services tiers, you can also push your browser. I feel like it's really difficult for browsers to compete on quality these days. Or what do you think is a way that somebody … other than implosion of the dominant player, how do you change things?
Håkon Wium Lie: It's very hard to market a browser these days. When people had to download their own browser, then they read articles and they listen to their friends and they had to make a conscious decision. But like you're saying, now, it's just there and you don't really care so much. People aren't that passionate about them anymore. So I don't know how to … I mean, I think Opera is still doing a pretty good job of this in the emerging markets.They have more users now than they had when the Chinese bought the browser and tapped into a few years ago. So they're still doing growth by being very conscious of they should use their energy. In my days, it was easier for me to convince 100 students in Indonesia to download a new Opera than to convince my neighbor in Oslo to do the same thing. So you had to focus.
Brian Kardell: Yeah. It's definitely an interesting ecosystem that we've created perhaps inadvertently. It seems like there's a lot of discussions, especially recently, about existential threats to the web and people don't agree what the existential threats to the web even are. I think that's part of why this is a really good thing to have a big, large discussion about the broader health of the ecosystem and what things matter and what things matter to us.
Vadim Makeev: The company who believes in web, it's not the biggest threat to it. The companies who think web is just one of many platforms, I think probably it's a threat or at least closer to it. I don't think there is a single biggest threat to the web as a platform. I think it's just way too important to us.So we always see everything that happens here and there as a threat because we know how fragile it is and that feeling that it does not belong to any company or it's basically a self-sustained thing, it makes us fear for its future. And that's why we always see that there is a threat and there is a problem.And if you live long enough, you see that threats may come and go and the platform is still alive. And I'm not pessimistic about it.
Brian Kardell: The thing that worries me here is that the cost of maintaining an engine keeps going up and up and up. And it is now complex enough that I believe that really, only an economic powerhouse could even consider really making a modern web rendering engine. Currently, Chrome is a little over 10 years old. It's, I think, 12 at this point.But it has something 84,000 person years of development into the code and that's not even to mention standards work went into it and testing work and all that stuff. That's just the code estimate. That's a lot of money.
Brian Kardell: So actually in my article, I did talk about this, that we say that there are three engines, but what we're talking about is modern browser engines that do everything that the web does. But really, like you say, I mentioned there are several. There's Prince that you make. You have a competitor antenna house that also has a render engine, I believe.And Amazon also … Actually, Amazon has multiple rendering engines, but in terms of a Prince-related thing that's similar, there's also one of those. They do something different. And they're a market that we don't talk about a lot, but part of me thinks it is actually a really important market. It's interesting that there's basically the same number, right? There's really three big competitors there.Likewise, they have different investment ideas and different priority ideas and stuff like that. But I wonder, is it possible that we could get some other reader mode or EPUB reader or something like that where … none of those are open source? Do you think that there's maybe some opportunity there for together?
Håkon Wium Lie: I certainly think browsers should be better at doing reader mode and to do EPUB. I think EPUB should be … I mean, EPUB is basically just HTML anyway, right? We want there to be a very simple core format for books, for magazines that any browser can handle. It's really weird that those worlds have been so separate. And I believe printed books too will be around.We don't want to print everything we read obviously. We will see most things on our screens. And most things that we read will be rendered by a modern browser engine. But there are cases when you do really want to have a physical book in your hands and you want to give the gift or you want to put it on your bookshelf, which is probably shrinking, but still, you're going to have them.And then for that moment, you want to be able to convert just about any web content into PDF file, which you can print out on your book producing printer.
Brian Kardell: There is a five-year plan to implement the fundamental ideas that would be necessary to make that story a lot better in browsers. I'm wondering, what does this look like for the Princes and stuff like that, these other rendering engines? And what does their future look like?I can see many possibilities, but one that I speculated about is it must be difficult to make something really competitive with a small team. And are there opportunities for those companies to somehow work together to reduce that burden? I don't know. What do you think about that?
Håkon Wium Lie: I can only speak on behalf of Prince. And the Prince developers are quite unhappy. They feel a little bit isolated at home these days, but that's because of the pandemic, not because of the competition. Prince is a profitable company that has a good number of customers who use web standards to create invoices, to create medical records, to create university textbooks, et cetera.And HTML is increasingly becoming the master format for all human knowledge and therefore, you need the tools to convert them. And when customers come to us and say, "Can you turn my webpage into a book?" Then we look at the code and say, "Well, probably yes, but you will have to make some changes."I mean, all the frameworks that often use very dynamic HTML features that use the DOM extensively, it's hard to render those into PDF. So we have to tell people to get back to the basics, start out with HTML anew and then add your CSS style sheet for print, which isn't that different from the CSS, but you had to add things like footnotes and running headers and footers, page numbers and such.Things that you want to appear in your printed publications that you haven't thought about much in the onscreen use. So the tools are the same, but the style sheets will be different.
Brian Kardell: But they know that the very reason why a Prince XML exists is because other browser engines are not interested in printing.
Håkon Wium Lie: Yeah. I think that's a good point. I try to have Opera do printing really well. I thought that was an area where we could distinguish ourselves, but nobody really cared. None of our customers cared. And as the web moved to mobile phones, even fewer people cared about printing.So that was a nonstarter. It's true that the market has been a little left to those who can't provide solutions. The web has focused more on the 50 frames per second market.
Bruce Lawson: Well, let me attest to that because I'm in the curious position where my degree is English Literature and Drama. And I'm an old fellow, so I'm a bibliophile. And it wasn't until I started doing some consultancy work for Håkon … And yeah, disclosure, I do occasional consultancy for Prince.It wasn't until I did that that I realized just how rudimentary the printing abilities of CSS as it is standardized actually are, things that are on every book, footnotes, floats that protrude into columns of text, balancing things up so they're pleasing to the eye.All of these things are absolutely central to every book you've ever read. It's just impossible with the current standards. And I think that's what Prince and Antenna House have-
Håkon Wium Lie: I'm very happy to have Bruce and other bibliophiles along here because printing books is 100 of years of tradition, Gutenberg. There were people before Gutenberg as well, but Gutenberg is 500 years back in time. And he established some of these aesthetical techniques that we are still using. He laid things out. He did the letting, he did the hyphenation. He invented fantastic oils for printing.Many of the things that we associate with books today come from that age. And I will work very hard to make sure we can replicate all of this in CSS. We're not quite there yet. For example, we can't do baseline alignments. If you have text in two columns, you can't enforce that all the baselines of adjacent columns are the same. So there are things lacking in standards as well.So there is a lack of focus on printing, but I'm happy to hear Brian say that things will get better. I'm not sure about the five-year plan thing.
Brian Kardell: So what I mean here is that web browsers were built not for books basically. They were a new medium and they had to work on different screens. And they had to work with ASCII text reading and all different kinds of constraints. And as a result, we built what is effectively tech debt. And we've, to some extent, painted ourselves in a corner with this focus on very particular things that made other things considerably harder and more expensive to balance at the same time. But there have been a lot of talks about this and other ideas that are very difficult to consider with where we print parcels into.And so all of the browser rendering engines have determined, how do we get there so that we can consider all of these other really interesting things that we have thus far been mostly unable to consider? Things like regions and exclusions and pagination and things like that. So they're all doing this multi-year, basically five-ish year investment to rewrite their engines to support an architecture that allows them to do those things.And one of the pressing reasons that is in here is that as the market has grown, as the web has expanded into all of these things, like there's the web in your refrigerator, digital signage, the PlayStation, your TV, your cars, everything is built with what technology now. People are imagining all different sorts of things and building all different sorts of things.And whereas yesterday, it might not have been super important for anybody to have print, it is actually getting increasingly more important because, for example, Microsoft Office 365, Google Docs are aimed at basically enterprises. And enterprises have products that do very good prints. So they have real needs and business drivers helping them forward on this. And I think that's really good.Maybe there is an opportunity to collaborate to make the actual web engines better. But I think another interesting possibility that I'm trying to ask about is maybe there's a different engine that is not the web engine, that is … I don't know what its constraints are.Maybe it's like a reader mode engine or just a print engine or a print and reader mode and EPUB engine, something that would do less basically, but would still be a very good experience for a whole lot of really important things and would allow really good print. I wonder, is there a possibility for these engines to somehow help one of those two paths forward?
Håkon Wium Lie: Yeah. I'm a minimalist at heart, so everything you've said there appeals to me. If we can get back to the basic reading experience … I'm not optimistic though because I think there will always be those asking for more.Like the office documents, that example that you gave, people, once they have a browser up, they will want to do Google Docs editing and they will want to have footnotes and edit those footnotes. I think you gain something by cutting code, but I'm not sure you gain enough to compete.
Vadim Makeev: I don't know. I think reader mode is a nice example of an innovation that I really appreciate, but it's not standardized. It's not described in anyway. So a big company that does it, does it its own way by trying to detect all the possible class names, semantical tags and micro-formats and things like that. And it's a mess, to be honest, at the moment.
Håkon Wium Lie: It's very interesting messed up. I remember when we did the small screen rendering mode in Opera, that was basically Opera Mini, where you basically wanted to take out everything that wasn't necessary. And you wanted to do that in the server because you didn't want to spend bandwidth transferring those. And then you look for a class then, right?You look for class equal ad then you have a good guest that this is not something you want to spend the time and money transmitting. And then you can look at, if a GIF image had a certain size, like 180 times 80 or some of these common banner sizes, then you also drop those. So you use a bunch of heuristics.Of course, once you set up using those rules, the advertisers will see what you're doing, so they will change. So it's a cat and mouse … very messy. You're right, Vadim, but also very entertaining.
Bruce Lawson: The problem with the reader mode, it only exists because so much of the web is absolute crap.
Håkon Wium Lie: Yeah, exactly.
Bruce Lawson: You realize how much of the web is absolute crap. It's the business model of appetite.
Vadim Makeev: Well, it's not the only use case because people have different preferences. I mean, some people prefer to read text to a certain size or a certain background or with certain font applied to it. And this famous example, Daring Fireball website, it's dark gray and light gray. It's impossible to read. I would never read it myself. So every time I'm there, I'm enabling reader mode.It's just a choice of a designer, choice of a developer. And we should be able to, to handle it somehow, but we don't have a standard for that. We have just … I don't know. I think developers and browsers should all agree that we need some standard for this.So some developers should … Again, maybe we already have it, put everything important on your page into a main tag and leave the rest to out of it so it will not interfere with the reader mode. Maybe we already have, we should just enforce it somehow.
Håkon Wium Lie: I think we have some of the ingredients. And also with regard to advertisement, I don't think reader modes means no advertising at all. I think one of the joys actually of opening a paper magazine is seeing who's advertising here. I think the Chanel advertising, I remember they put in real perfume once. I don't think you can do that on screens.
Vadim Makeev: Yet. Yet.
Håkon Wium Lie: But that's all so good. But yeah, advertising can also be a feature if it's static. You don't want the noisy, very dynamic ones when you're in that reader mode yourself. I tried to push for this. We tried to do this in Opera with the Opera reader, which we were going to introduce a page-based mode on a dynamic screen.So you took a tablet and you went into the reader mode and there, you went from one page to the other. So it was a pagination issue rather than a scroll bar issue. I'm not so fond of scroll bars. But we can really make that work at the time. What do you think of the pages, Brian? You like the or..?
Brian Kardell: Yeah, no, not always.. I do I think that is the really interesting thing that I was trying to get at, which is that the web has so many uses that it can wind up being not especially good at doing any of them because you think that they all should be the same. But we make so many choices with regard to design, thinking that it's your website that … I don't know. I feel like we get away from what makes it really pleasurable to read sometimes.We think, "Well, my head or menu always has to be at the top. It just has to. It needs to make the logo bigger. And this should have a sidebar and it needs to have this thing." And I feel like very frequently, for many reasons, I want to take that and say … I wish I had a book of this basically, right? Something where I have that experience, but not a PDF.PDF, I think is actually terrible. It's great for print because it describes exactly what you're going to print, but the user experience of PDF is not great in my opinion.
Bruce Lawson: Well, it's funny you say that because as I said, I'm a bibliophile and I still buy physical books, but I also have a Kindle and I really enjoy reading on the Kindle. And I notice this is not groundbreaking, but it occurred to me that the Kindle is a page-based mechanism. I click something or I touch something on the modern Kindle and it moves me a forward a page.It's not that infinite scroll that I somehow find terribly demoralizing. And I've been known to print out websites using prints to PDF and then converting them and sending it to my Kindle so I can read them page by page in a nice-to-hold device. So there is merit to page-based layout.
Brian Kardell: Yeah. I think it would be fantastic even for my own blog, right, for me to be able to say … Some of my blog posts are rather long. You may have noticed.
Bruce Lawson: Yes.
Brian Kardell: Yes. But I don't want to overwhelm anybody. I would like to show somebody nice content, determine where page breaks are and just give them the opportunity to say, "I'm looking at this in the web and that's how I prefer to look at it." But I would like to make sure that they have a nice reader mode experience that includes the ability to swipe pages. Let me.
Vadim Makeev: I'm reading a lot of books in EPUB format on my iPads, sometimes on my iPhone and I have a problem with EPUB or auto-generated format. So PDF is fixed format, EPUB is flexible. So it regenerates the medium every time you rotate a screen. So it tries to fit your content. And every time I read a book with some pictures in it, it fails miserably.I have half a page on the left side and then half a page is empty and then the next page is empty and the picture goes on the third page, which I need to go through. And it's really hard to understand if it's the end of a chapter or it's just … yeah, something's wrong with my book.So I think where I'm going to, I think web is not ready to adapt to such format because when it's a book, it's laid out in a fixed medium or more or less. But when it needs to adapt to pages, we have a lot of problems there.
Bruce Lawson: The thing is, Vadim, in a few years' time, you'll be reading books without pictures, so it will be a problem solved.
Vadim Makeev: This really interesting topic is this stuff that is currently on the fringe of the web and what does the future look like for that? I think it is messy now. And I think it's partially okay that it's messy. I think I would rather have a place where there is mess and experimentation before we go to try to write down the thing that we know is the right answer because it's frequently judged by criteria that we don't even know exist.The technically best answers frequently don't win. And there's no end to inventions that were created, that wound up actually not winning at the thing that they were invented for, but being fantastically useful for something else.
Bruce Lawson: Yeah, yeah. Though I mean, most of the web is like the history of post-it notes, which were invented accidentally and almost thrown away because they didn't actually stick properly until somebody at 3:00 am thought, "Well, actually this ability to stick something down then take it off without leaving a residue might be a good idea."There's so much on the web things not doing what they were originally supposed to do or the least good solution actually being the one that got adopted and also-
Brian Kardell: Including the web itself.
Bruce Lawson: Including the web itself. And also, it's great because every week, somebody blows my mind with a blog post saying that I did this and this and CSS and I made that. And I'm not talking about making picture-perfect images of X or Y with only CSS.I'm talking about something I saw Adrian Roselli do where he was making backgrounds on fit positions, sticky table headers using radial gradients. And I just love the fact that people are experimenting all the time and inventing new stuff. And some of it's-
Håkon Wium Lie: I certainly think that the CSS art sites are really great. Nobody planned for it, but it happened and it's beautiful.
Bruce Lawson: Yeah. I bet you never thought that people would be making the Monalisa arts at CSS when you and Bert were wondering how to-
Håkon Wium Lie: That was not what we were aiming for. Correct.
Bruce Lawson: It was not a considered use case.
Håkon Wium Lie: That's right. Exactly.
Brian Kardell: So can I ask, why did you create prints exactly? Because you were at Opera. Opera could have done … you said you were interested in that.
Håkon Wium Lie: Well, actually, I didn't create Prince. Prince was created by Michael Day and his wife. But I saw the need for a print-based solution and it became very important when Bert Boston and myself, we wrote a book on CSS and we wanted to use CSS to format that book. We had used the FrameMaker for the first and second edition, but we thought for the third edition, we should eat our own dog food.The question then became, how can we do so? Can we find a browser? Opera wasn't good enough and none of the other browsers were either. But then Prince came along and they posted to the mailing list that, "Here's our new product. Check it out." And I tried it and it did so many things right. The basic pagination was there.It couldn't do hyphenation at the time, but we solved that by running a pro script over the text and adding soft hyphens all over, so we were able to hyphenate the book as well. And we could do figures, we could do page numbers, we could do running headers and footers. So we were able to create a PDF that was ready to be sent to the printer.This was in 2005, so it's a long time ago, but that was the start of why I got engaged in the Prince product. I found that by joining as chairman of the board, that's a nice way to have some of your favorite bugs fixed.
Brian Kardell: I think that there's a similar history here with something like tech, right? With Knuth.
Håkon Wium Lie: It's an honor to be here compared to Donald Knuth himself. I'm not in that league, but you're right. I think he passed his masterworks on programming because he had to write the typesetting system to do make it beautiful enough. That's true.
Brian Kardell: Yeah. Math is an interesting example. I don't know if you know that Igalia is leading the charge to get a final and actually interoperable MathML. We're closing in on that. Hopefully, by the end of the year, we'll finish MathML core and the web in all the browsers will have finally some pretty beautiful math rendering. How's prints on MathML? Pretty good or?
Brian Kardell: So this actually leads me to a different question, which is a thing that I found a little bit frustrating actually. So I don't know of a company … This is why I think that browsers or another thing that isn't the browser should come along where you could … I don't know. I'm just throwing out wild ideas.But we could create a print protocol and register a protocol handler where you're in the browser, but you launch to your view where you want to actually have good quality printing or pagination, that kind of thing, a different way to consume effectively the same content or something like that. I don't know of a business that doesn't want to print something. Like you said, invoices.I worked for a college and we had to print transcripts. We had actual print needs and very frequently, you could see those things online and we had to build systems that would build and maintain views of those, but then frequently, it was difficult to … you would want to take that content and send it to some system.And if you recall back on the web … I don't know … 20 years ago, it was just, you would have PPK compatibility tables or something like that. And you would have to find the intersection. But it was very difficult to figure out, "What can I use that is actually going to work everywhere?"And I have some similar problems with like print and PDF generation where I couldn't figure out … there was no Can I Use for them. And so I'm wondering, do you have something like web platform tests or Can I Use for printing?
Håkon Wium Lie: We tend to communicate with the potential users through sample documents, "This is how you can do this and this and this. Just use the source code and modify it, which was how websites were set up in the early days." I'm not aware of anyone specializing in the Can I Use thing, although there's a fair amount of testing going on in the print world as well.
Bruce Lawson: I approached Can I Use to ask them if they wanted to include the print engines, but Alex Domariya said quite legitimately, "There's so many web rendering engines or variants thereof because, of course, Chrome isn't chromium.They're variants of chromium all over the place that it was just becoming unwieldy," which is fair enough because the majority of the people that go to Can I Use are interested in web behind the glass moving at 60 FPS.
Brian Kardell: Yeah. But I wasn't really suggesting that it has to be Can I Use. I think that there's a really positive thing about the web commons that we don't have to share everything. We don't have to have all the same goals and everything, but one of the things that drives that is this idea that you can use the same technology everywhere.But it is actually subsets of technology and that can get unwieldy to understand. So we have a lot of clients that ask us about, "What things can you have on here?" So that's an interesting question. I was just wondering if the print community has an answer to that that I just wasn't able to find. I think that would be really possible.
Håkon Wium Lie: Yeah, I don't think it exists yet. I think there's room for somebody to do some work there.
Brian Kardell: I wonder if there is something disruptive here that … I wrote a post on this … I don't know, two weeks ago. I hadn't been writing it for a little while, but when Firefox announced they were laying off a quarter of their staff, I decided I should post it even if it's not ready because there's pertinent thoughts in there.And basically, what it says is that the model of a few, really big companies funding and doing that basically through search, it's not great. And what Igalia does is to help that problem.Instead of saying, "We have to go and ask the browser vendors to give us a slice of the pie that we're asking for," we would like these print features in the web, then they have to make some priority decisions about whether that's the right thing for them to spend their money on. With Igalia, you just bring more pie, right?We have more people bringing pie to the party instead of having to share the pie with everybody. Do you think that there is a way for us to disrupt that? I think of TV and I remember when I was a kid, my grandmother, she thought that cable was just absolutely … Why would somebody pay for television and it comes over the air for free? That was completely unbelievable.But we have so many miles for creating entertainment now and I feel like there's something to that that makes it more robust and more avenues for different kinds of success. Do you think that the web could change like that in some way, or?
Håkon Wium Lie: Well, when internet Explorer had the 90%-plus of the users, we were pretty negative in Opera. I tell you, we were depressed about that situation. Could this ever change? The Microsoft ice age was over us. Would it ever get better? And it turns out things got better and now, we have different problems. We don't have Microsoft as a problem anymore.We have other big companies that are problematic in some ways. Will things change again? I think so. Will it solve all our problems? I don't think so. But I don't think we're stuck in a Facebook or a Google ice age anymore. I think there's room for development here.
Bruce Lawson: And I'm encouraged to buy … I'm not captain open source per se. People used to ask me, "Isn't open source important?" And I said, "Yeah, it's really important. But open standards is actually what makes the world go round." But I do think the advantage with the major rendering engines now being open source is nice. People like yourselves, Brian at Igalia can go in and do work.I know that Bloomberg funded Igalia to implement CSS Grid because they wanted it and they wanted it now. So they hired you lots and you made it thus. and you have the trust of the people who were the gatekeepers in WebKits and Blink and Gecko enough that they would upstream your work. And I don't know, Håkon, if Brian's told you about the open prioritization project they're doing at Igalia.I know this isn't an Igalia podcast, but I'm not being sponsored to say this. I think that this can be a really interesting and encouraging experiment on a future potential other way of getting stuff into the standards. Do you want to give Håkon the 45-second helicopter view as these people say?
Brian Kardell: Yeah. I mean, having more ways to fund the commons is actually really healthy. And so one of the things that we're experimenting with is we partnered with Open Collective. Basically, we took the six features that are uncontroversial. There are different sizes, they cover different areas of the platform, they're in different browsers.But there are things that we could, in theory, help move forward. We provided a fixed price estimate on them and we said, "Go make it so. However you make it so and we'll do it." So it could be 10,000 developers who each give a dollar or two or it could be a combination of companies that think that this is important and they each gave a couple of thousand dollars.So that's the open prioritization. It's an experiment around that. And we would like to expand that a lot actually and get more investment and more voices into the prioritization because they don't always align, right? Google has not really had core philosophical problems with MathML itself, but they have thought, "It's just not a priority for us."
Håkon Wium Lie: Is that how you find the work on MathML? People are crowdfunding. They pay per a formula or something?
Brian Kardell: We did it through a sponsorship model. So we got an initial grant from the Sloan Foundation through the Institute for Standards Organization. And we got some from APS Physics and Pearson Publishers pledged money. We really believe that it's societally important.If you want to be able to have the web reach, its potential, to do the things that it was intended to do, to be able to share research and all that kind of stuff, you can't do that without being able to render math.
Håkon Wium Lie: Absolutely. It's very worthwhile. It improves the semantics of HTML by being able to mix in formulas.
Brian Kardell: All right. So I think that's all the time that we have. I just wanted to say thanks to everybody for coming on. This was fun. I hope that some of the conversation was interesting to people.
Håkon Wium Lie: Well, thanks for inviting us and thanks for putting it on. I think it's so great that somebody is actually interested in both the history of rendering engine because these engines display most of the content that we're reading on screens,, most of the content that humanity is reading on screens. So we should be interested in where they come from and where they're going. So thank you to you.
Bruce Lawson: Thank you, Brian. And thank you, Håkon and Vadim.
Vadim Makeev: And yeah, such discussions make me optimistic about the future of the web. So I think it's good to know that there are people who care. So web is not doomed as other people might think-
Håkon Wium Lie: There's at least four of us.
Brian Kardell: Don't worry. We'll keep it going.
Håkon Wium Lie: Perfect.
Bruce Lawson: Thank you, dear listeners, for tuning into to our support group.