Eric Meyer: Hello and welcome to another episode of Igalia Chats. I'm Eric Meyer. I'm a Developer advocate here at Igalia.
Brian Kardell: I'm Brian Kardell. I'm also a developer advocate at Igalia. And today we have a guest. Guest. Do you want to say hi and introduce yourself?
Liam Quin: Yeah. Hello, my name is Liam Quin. What do you want to know about me? I'm here.
Brian Kardell: So Liam used to work for W3C. Yeah.
Liam Quin: Yes. For 17 years.
Brian Kardell: Has quite a bit of history and experience that go around XML and XML related things. And I've bumped into Liam at TPAC a number of times over the years and always thought I had just nice conversations and something happened that we're going to get into. And I saw that he commented on this and I thought, well, this would be a good opportunity to invite Liam on the show. So anyway, recently there was an issue filed in HTML specification in WHATWG that said, 'Should we remove XSLT?' And on this show we've talked a bunch of times about how things are funded and prioritized and how they work and how we feel about things shipping and prematurely, how we feel about things unshipping and the complexities around that. So in May this year, we did a show with Rick Byers, who's the director at Google for Chromium, and talked about their feelings around how and when to break features and why they have developed processes for it and things like that. We also covered some of this in the Interop project in 2024. We did a show, we talked about how tricky it is to prioritize resources and all that stuff. So anyway, this was phrased as a a question and given some past experiences where it's too late and then a bunch of people chime in and they're really angry, I thought maybe it's better to be angry now. I posted on social media, not really to direct anger, but to ... Sincerely, not to direct anger, but to say, 'Hey, if you're going to object when I remove this, I would like to know that before I go ahead and remove it because I'm basing this on my best understanding of the situation, which is as presented, not very much use at all.' Very, very tiny amounts of use showing in Chrome's current tracking for this. It did direct quite a lot of anger. And Liam, you did weigh in on this, but just in a small way to correct a little bit of history, somebody commented, I vaguely remember the mood 20-something years ago, among several browser vendors and WebXML nerds that XSLT should not be used or even available on the client side even in the first place. Somebody said the same about SVG back then too though. And probably MathML as well, I would imagine.
Liam Quin: Most likely.
Brian Kardell: You commented some ...
Liam Quin: Yeah, so I commented to say it's somewhat revisionist, only somewhat because I can't say that no one had that opinion obviously. Microsoft included XSLT in Internet Explorer early on and early on Google Maps relied on XSLT for a while. We can actually come back and talk about why it relied on Google Maps. It's quite interesting because people are probably still using that technique. The arguments about not having XSLT that I've heard a lot of them also apply to not having JavaScript, not all of them, except that XSLT is at least declarative, which gives some advantages, but it's not JavaScript or XSLT. That's not really the conversation.
Brian Kardell: Before we even start on this, is it likely that the three of us know what XSLT is, but probably a whole bunch of people listening might not actually know what it is?
Liam Quin: I think that's very likely. There was some misinformation put out about what it is as well that they may have encountered.
Brian Kardell: So do you want to maybe explain what it is?
Liam Quin: Yeah. Sure. The short answer is that it's a declarative way of transforming trees and collections of trees. And declarative means you don't say how to do it. You say, 'This is what I want.' It's a templating engine by some views. So you could say it's a bit like React or one of these other templating engines. So there's embedded expressions. And typically what you do with it is you tell it to walk the document tree and either copy the document changing some items or just pick some things out. When you get to something you want to change, you've got a very powerful expression language that can look at the whole document. It can do joins, it can look at content. In some ways it's more powerful than CSS because you could say things like, whenever a table cell has a negative number in it, add this class attribute. And we can't do that in CSS. Whether we should be able to or not. It's a separate conversation, but you can't. As to the misinformation years ago in the 1990s before even access, before even CSS was invented, need Bert and Håkon and others working on it, there was a thing called DSSSL, which was for formatting SGML documents. And there was a meeting actually at an SGML conference to try and come up with a subset of DSSSL that could be used on the web. I was involved in that because I worked for an SGML company that had produced an SGML plugin for good old Netscape that showed SGML documents. And the style sheet language was different from the other plugin that could show SGML documents. And of course the customers wanted interoperability. So we looked at DSSSL and we came up with a subset. The eventual result of that meeting was XSL, and the misinformation I mentioned before comes because XSL itself was never in the browser. I'm only aware of one mainstream browser that ever had XSL the whole thing inside it. And that was an experimental version of the AOL browser. So we are not talking that. XSL is in two parts. There's a formatting part which is really optimized for print because it's old and it does have interactivity, but it's optimized for print and it can do a lot more than CSS for print can do. If you look at any of the commercial implementations of it, you'll find Antenna House, for example, has a formatter that can do both XSL-FO the formatting object part and CSS. It has about 300 CSS extensions to bring CSS up to the level of XSL-FO. So it's much more powerful, but it's not for browsers and it's not in browsers. So you see people talk about how formatting objects don't belong in browsers and are really complex, and both those things are true, but it doesn't matter. The other half of XSL is the transformation. And the reason it exists is because very often you want to format something, but you say, 'I wish these elements were in a different order. I wish this input was slightly different or dramatically different.' It would be much easier to format. And so XSLT lets you do that transformation originally with the purpose that you'd then go on and format it. It turns out there's so many more uses for transforming documents than just formatting them that XSLT is the side that took off and is massively more widely used. But that's the part that's in the browser. This declarative transformation that was defined in the late-1990s for transforming groups of trees.
Eric Meyer: Yeah. I actually, in the very beginning of this millennium, before I was using CMS's meyerweb.com, my personal website, I wrote my posts in my own made up XML-ish language and I used XSLT to turn it into static HTML pages. I did that on the server side, not the browser side at the time. But that was one of those instances of XSLT being really useful. It's used these days as I understand it, to transform RSS feeds or even atom feeds into things that browsers can display that aren't just raw RSS.
Liam Quin: Yes. There's a processing instruction, looks like a PHP instruction, but it isn't, less than question mark, that you can put in your HTML that says less than question mark XSL style sheet I think it is, and HREF equals and it points to your XSLT style sheet. And if you do that, when the browser loads the document, either XML or HTML, it will go off and it will load depending on the MIME type of the input it's triggered by, I think. In most browsers there's some interoperability issues around that. But it'll go off and fetch the XSLT style sheet transformation and apply it before displaying anything. And depending on the browser, if you do view source, you may see the output of the transformation or you may see the input to the transformation. Different browsers have historically done different things there.
Eric Meyer: Oh, that's really interesting.
Brian Kardell: Yeah. I don't know what year this was maybe 2000, 2002, something like that I worked for ... They had this database of people who could prescribe prescriptions and they wanted to do something and we used XML and the whole interface was built with XSLT in the browser and did some really interesting clever things with it. And then the guy who is the chief architect of that left that and went to work as the head of consulting for JBoss North America. I don't know if you remember Jboss. They were a Java server company. But they were in competition with IBM and a couple other ... WebLogic, things like that. Java had a lot of archives and all these archives had descriptors that were standard and then a way to extend the standard. And every one of them extended the standard in their own way, but they all agreed on what you were setting they just didn't do it the same way. And rather than try to get people to standardize it, they actually like this because it was a little bit of a lock in. So you build your whole enterprise with this, you wind up with all these custom XML files, it's really difficult for you to move and change vendors. So he hired me to write a converter not in the browser. XML converter that would go and scan all of your directories and find all these files and just translate from know WebLogic to JBoss versions of everything. It was not perfect. There were some things that couldn't do, but it was pretty good. It was presented at JBoss World in Barcelona. I wasn't there. But years later I worked at a different company and somebody said, 'Oh, I have assigned this thing where we have ...' I don't know. 75 of these apps and they want to convert them to use JBoss. So it's just this really boring manual task of going and looking up and converting them. And I said, 'Well, hold on, I have this tool.' And two weeks later, they were like, 'I'm done with a whole year task.' So that was nice. It's a handy technology, but it really is super handy when you have XML as a data source. It's not so handy If you have JSON as a data source.
Liam Quin: XLST-4 will be great for JSON.
Brian Kardell: What's that? XLST-4?
Liam Quin: Yeah. And one of the problems here is that the XSLT in the browser ... Imagine if HTML2 was just being developed at the IETF. I was on that working group. HTML2 was just being developed and someone came up with tables and there was strong opposition from some of the browsers as there was to HTML tables because they would slow down page rendering because you can't do incremental rendering of a table. You have to receive the whole table to work out the column widths. And so there was really strong pushback. So some of the browsers implemented HTML2 without tables. And imagine if that's where HTML had stopped. Well at around that time out came XSL-1, but the language hasn't stopped because people are still using it. So XPath which is the expression language of XSLT and used elsewhere as well. XPath And XSLT continue to evolve. They've really continued to evolve. And people are currently working on an XSLT-4. XSLT-3 though came out in 2017 and it has JSON support natively and it's being improved right now. So it's not the case that XSLT can't do JSON. It's the case that XSLT-1 from 1997 can't do JSON.
Brian Kardell: That's actually where we are in this. So basically it got, I would say hot. I do want to say I didn't like it just to be totally fair on both sides of this. I didn't miss it when it was gone. I found it a little bit obtuse in my mind. I accomplished a lot with it, but it was not as simple for me to grok in some ways as most templating languages. Because you're operating on trees, it's a little bit more complex than you're operating on a string. I don't know. But computer languages are super ... We've been doing string munging for forever and it's easy to think about, but maybe it's just training. But anyway, yeah. So basically browsers had this and it was when we were also going to be like the future was going to be XHTML. It didn't go that way. So the question now is there is no investment in this. None. And there hasn't been for a really long time from the browser's perspectives.
Eric Meyer: We could probably say at least a decade, probably longer.
Brian Kardell: Yeah. And when we do have ways of measuring, use ... A little caveat on that, I'll come back to that. But we have ways of measuring use. And it is a true statement that things that basically we introduced a month ago have more usage than XSLT that has been around for the longest time. So there's this, well, why should we invest in it? Nobody's really banging down our door asking for it. It didn't survive. It's not a judgment of the goodness or the badness or whatever. So what I can tell you that part of the reason that I wanted to get into this a little bit is because Mason is very reasonable pragmatic guy.
Liam Quin: Mason being?
Brian Kardell: Mason Freed who opened this issue. He cares about the web really a lot. I am watching this play out on this GitHub issue and I'm thinking about what was it like being on the outside looking in versus what it's like on the inside looking out and it's pretty different. I don't know, Eric. Maybe you can speak to that a little bit because you were part of the web standards project. Do you see a parallel here?
Eric Meyer: Sorry, a parallel in what way?
Brian Kardell: I also really interpreted everything that browsers did through a very specific lens. You're trying to make sense of the world with the data that you have. People say things that sound very reasonable but involve criminology. A lot of times it's simpler than that. And so I thought of Microsoft as big evil corporation with very complex mechanisms and plans. I think in a lot of cases it wasn't quite like that in practice. We know a lot of those people very well now.
Eric Meyer: Yeah. Any large organization is not the monolith that it appears to be from the outside. Google makes more money than most of us can conceive of, but it's not all going to the browser project. Hardly any of it, comparatively speaking is going to the browser project.
Brian Kardell: But a lot nonetheless. Billions.
Eric Meyer: Objectively A lot of money goes to the browser project, but as a percentage of the money that Google has at its command. It's almost rounding error to zero would be my guess. And we saw the same thing in the '90s and back in the 1900s as I like to put it, when we were dealing with ... Well, mostly with Microsoft. So at the web standards project, the browsers that were big at the time, which was Netscape, Internet Explorer and Opera, we would test them out and write things about what they did or didn't do well. So the CSS working ... Well, sorry, the CSS action group at the web standards project would publish things like top 10 things that Opera really needs to fix in its CSS implementation or top five things that Internet Explorer got right in its latest release. Things like that. And there was a fun moment many will not have known about this and probably at least some will have forgotten it, but in 1997, I believe it was, Microsoft was granted a patent on the concept of applying style sheets to documents. They had applied for the patent and the US Patent Office apparently did not find enough prior art of the idea of applying style directives to a document to turn them down so they got this patent. And there was quite the uproar. And Microsoft's position was, look, this is not something we're going to enforce. We're not going to charge anybody. It's a thing that we do in Word, like in Microsoft Word so we got a patent on it so we couldn't be sued by somebody else getting the patent. This is known as defensive patenting. And so the web standard project itself actually was revealed not to be a monolith, at least internally because the steering committee or whatever ... I've forgotten what they were called now, wrote a press release and then ran it past the CSS action committee for our comment and we were like, 'Whoa. Slow down. This is way too much flameidge. We need to moderate things.' But that sometimes went both ways and got flipped. There was a point where, again, in the late 1900s, I was still working at Case Western Reserve University as their webmaster because that's how we rolled in those days. And I was maintaining the CSS compatibility tables, like this huge compatibility table of all the CSS one properties and values and whether they were supported, not supported or badly supported in various browsers and various browser versions because there were a few enough that you could do that. And I was also writing articles about CSS stuff. And I get an email from someone who shall remain nameless at a company that shall similarly remain nameless, but it rhymes with Microsoft and said, 'Hey, I'd like to just have a call with you to talk about your support information stuff.' Like, 'Oh, okay.' So we arrange the time, I get the call and they said, 'Hey, yeah, you know how that you have all our support information and sometimes you have to make a call on whether or not to indicate something is partially supported or buggy supported or whatever. And when you write about it, you have to choose how you're going to characterize our support. I would like you to be more brutal and mean because when you do that, I can then take that to people higher up in the bureaucracy of Microsoft and say, 'We look bad. If you give me X resources, I could fix this.'' Oh, interesting. So there were parts of Microsoft at this point that wanted to do to push more on making CSS more interoperable or adding features or fixing bugs, whatever. And then there were many, many, many, many other parts that couldn't have cared less because that's not what they were there for. The office team did not really care about the CSS support in Internet Explorer except to the extent that it could help render stuff that Microsoft Office had output in some way. And it's going to be the same at Google today. The server infrastructure team does not really care about the funding level or the work of the browser team, except in so far as it touches on what they do. If the browser can be changed in a way that makes their job easier, then they're all for it. Otherwise, why would they care? Professionally anyway. People only really care about the browser and what the browser does in the sense of can I make our job easier? And they might push for things. I think that's where some Google proposals, probably a lot of Google proposals come from where you might see a proposal from Google and you're just like, 'Why would you put this in the browser in the first place?' And it could easily be that, well, there's another team in Google that said it would be really great if you could do this and the browser team agreed. So yeah, we don't have monoliths. And I saw some of that in the discussion about whether to remove XSLT. People from within Google saying, 'Given our limited resources or given the limits of our resources, this is not something that we're going to put resources towards. We're not developing XSLT. We're not expanding it. We're not doing anything with it.' And responses to that were things like Google ... It's like it doesn't make sense for Google to plead limited resources. You have more money than God. But no, the browser team doesn't. The browser has this many resources. They have this many people that they employ. They can't just willy-nilly hire other people. I formulated a-
Brian Kardell: They wish they could, right?
Eric Meyer: Sure. I bet they do. I formulated a version of Hanlon's Razor back again in the late 1900s, I think partly as a response to the phone call that I was talking about, which was never attribute to malice that which can be more adequately explained by resource constraints.
Brian Kardell: This is I feel like the thread that I have gone back to 10,000 times since I've come to Igalia and I see we work with all of the browser projects. I see how the sausage is made and I'm like, 'Boy, I wish that somebody was explaining how the sausage is made because it's really potentially useful for people to actually understand this.' I want to go back to the caveat real quick that I laid out about the, we have data. So that data is largely to either public sites or things that are not behind corporate firewalls and things like that. It's biased.
Eric Meyer: So when you say we have data on the usage of given technologies, it's all public facing stuff.
Brian Kardell: Yeah. It's not only public facing necessarily, but it's very incomplete. If your corporation is doing a bunch of stuff on the Internet, it's not going to pick that up probably.
Eric Meyer: Yeah. Unless the browser has some internal phone back home thing.
Brian Kardell: It does, but that's what I'm saying about corporate firewalls and things like that. So a lot of that stuff is blocked in corporations. There's a lot that we can't see in terms of that instrumentation. At least in general and then they can enable more specific ... Counters and things.
Liam Quin: I think one of the wealthiest people I ever met ... And this goes back to Eric's point. One of the wealthiest people I ever met, the knowingly, I visited his house. I remember in his laundry room there were 50 washing machines because it was one of these stately homes and he had a staff of 200 people in England. I won't say which one. He was an Earl or a Duke or a Marquis or something. And he gave my brother and I a lift back to his house because we were walking so that we could talk. So he stopped his car quarter of a mile or maybe more than half a kilometer away from his house. He turned the engine off and he said, 'I've discovered I can coast all the way from here and save the petrol.' Now he didn't need to save the petrol. But what it told 14-year-old me was something about his worldview. And it's very interesting because if you spend time around people with a lot of money, you'll find they often ... If they're nouveau riche, they will have a spend spend mindset. But if they had large companies with responsibilities or if it's old money, then no. Because money isn't central to them in the same way. It's a tool they use. It's a different way of looking at it. And it's not good or bad, it's just different. And I see that resources, by the way, because I'm an independent consultant and although I do things like XSLT and XSLT training, I also do spec writing and standards and editing. And one of my clients is Google Fonts when they can afford me. And again, they don't always have the budget.
Brian Kardell: No .that's a true statement. We know other consultants like that who have worked with Google. We work with Google. It's not an unlimited budget. I mean the fact that they're even hiring consultants means that they're not pulling somebody in full time. I think a lot of people don't realize this, but the CSS working group, probably like the most prolific spec producers and Google Funds just an immense amount of that. And do you know how many spec writers they have? One. One in-house Tab. Tab is the only spec writer that they employ full-time to write specs. Not that nobody else works on them, just like as far as somebody who professionally writes specifications, they have one.
Liam Quin: Hey, I'd be happy to help.
Brian Kardell: Yeah. Well we have people who listen, so maybe they'll take you up on that. Yeah. And I think that also if you said, 'Here are a whole bunch of problems and here is $1 million. Go solve them.', we would probably all spend it in different ways. And that's what happens in all these engines. They spend way more than a million dollars. They spend hundreds of millions or even billions a year on the engines, which is amazing to think about.
Liam Quin: And it gets back to your stats question too, doesn't it? Because it's the iceberg. And not only is it that there's tons of web pages that we can't get at because they're behind firewalls and there's a lot. But also when you say this is how many pages for example, use CSS, use jQuery, use web fonts, use any technology, whether it's XSLT or another one, it's unweighted. You can say how many web pages, you can say how many page views might there have been? How many impressions for pages with this technology and weight it. And if you do that, you get very different priorities. Or you can say, 'How much do people care that I don't know the US Congress website no longer renders because they took XSLT out of the web browser?' That's an example website that uses XSLT. It serves XML with XSLT to format it.
Brian Kardell: Is it so, really?
Liam Quin: Yep. I'm looking at a statement for congress.gov right now on the 117th session. 117th Congress, first session.
Brian Kardell: That's very interesting.
Liam Quin: Sorry. Yeah.
Brian Kardell: That's very interesting and would be an interesting thing to put on the issue.
Liam Quin: I think the issue's closed, unfortunately, I don't think I can.
Brian Kardell: We can pass it along to Mason if you want to share a link. I do also want to say that I invited Mason to be here. He was unfortunately on vacation on Friday when all of this was blowing up and he is trying to catch up with all of it now. And so I only managed to get a hold of him an hour and a half ago and he was like, 'I would love to come on, but I can't today.' So yeah, he's not intentionally stepping out on this or anything. I told him I feel like we can represent him fairly well. So what I wanted to say though, that is part of the behind the scenes thing that nobody sees is the issue itself is a question. We are looking for discussion and then there is a working group. There's calls for WHATWG, and this was discussed last week. And all of the vendors said, 'Look, nobody is really investing in it. We only support up to one. So if you're really interested in XSL, you're probably doing something else anyway.' We don't have any data to show, but we do have lots of bugs and we've seen security problems and things. Because if nobody's investing in it, you wind up with problems with bit rot. We discover problems because the libraries we have are written in C. So there's a spectrum of possible answers here to what should we do about it? They were all discussed. And it doesn't surprise me that the one that they're most interested in trying is could we just get rid of it? Because I have technology like that in my own house where I'm like, could I actually just get rid of it? It would make my life simpler. Maybe I can't, so maybe I have to deal with it, but maybe I could just get rid of it. But it's not the only possible answer. And I do want to say that it's not that they asked a question and that there is a foregone conclusion that they're just going to do it. They're definitely listening. What they've moved forward with is let's figure out how we would adapt the spec. Let's create a thing. We're going to add some more instrumentation. When they do a roll-out like this, they will ... You can listen to the show that we did with Rick Byers a few months ago.
Eric Meyer: I don't know if it's a rollout. It's really more of a rollback. When they do-
Brian Kardell: No, no, no. They'll do a rollout of ... So first they are putting all this implementation behind a runtime flag. And then what they'll do is just random shuffle. They'll enable 1% of Chrome browsers and then they'll see what the feedback looks like. They don't want to break everybody all at once and they'll ramp it up. And so anyway, there's definitely a process to this that they expect is not short. And I don't expect other browsers to be in a rush to be the ones to take the phone calls on that one. So Safari has expressed, we're cautiously supportive of that idea. If we could indeed get rid of it, we would support that idea. And Firefox basically same thing. But there's other feedback in here that's like, ... Well, one of the really most common use cases of it is podcasts. So podcast RSS often has an XSLT associated with it. And this is built into lots of podcast hosting platforms and stuff like that where you give somebody a link to the RSS and then that loads with a transform. And so instead of the normies clicking on it and getting this XML and going, oh my god, I saw this on CSI, this is a computer virus right, and just panicking because they don't know what to do. They get just some nicely formatted thing. So in the call last week, we said in the very least, one of the things that we probably should do is protect the normies for the podcast. So if we decide to disable this, one of the nice things about podcasts is that it is a standard format. If you have a podcast player, they just make that look nice. We could also make that look nice by default. Maybe it won't follow your transform, but we can make that look nice. Then there was discussion about even beyond that maybe should we have an internal polyfill. PDF.js does this basically. There's one HTML CSS JS solution to displaying PDFs in the browser. It's just an open source project, PDF.js and browsers can embed it. It's implemented in the same core technology, so it has the same privacy, security, sandbox issues as anything else. It makes it a little bit easier for them to reason about and for them to deploy their existing resources toward. So anyway, there's a large variety of ways that this could go.
Liam Quin: Yeah. I think there's some others too that you've not mentioned and that I'd like to mention.
Brian Kardell: Please share that. Yes.
Liam Quin: So because one consequence of course is just taking XSLT away yes. Will break probably the majority of RSS feeds that people see in the browser today. And a lot of those will be automated and there isn't someone there to fix them. Some of them are government. It will break some US government sites and big ones like Congress, maybe White House. I'm not sure. The House of Representatives, for example. I'm looking at a bill online that's XML with XSLT. So there's two examples. And there's also a trick I promised to come back to, which is what Google Maps used early on. And Eric probably remembers Håkon saying Opera would get XSLT over his dead body. And the day after he stopped watching and it went. Why? Because Google Maps relied on it. Why did they rely on it? Because they were serving up type with one MIME type and needed to convert it to another. So they were serving up XML and converting it to HTML. And at the time you couldn't use JavaScript because JavaScript wasn't run on XML files. So just like if you receive a JPEG image, you don't want JavaScript inside the JPEG image to be executed. That would be a really serious bug. So what they did is they put this process instruction in and then they could serve up XML in Google Maps and have it converted to their HTML pages, but have it work cross browser. That's a very high level explanation. I'm not going to go into the details because it's not relevant to what we're talking about today, but that's how XSLT first got into Opera. So it has these other uses that are not obvious, and I just thought I'd point that out. Google Maps is tiny and hardly anyone uses it but nonetheless, it's a thing. I don't think they use XSLT anymore.
Brian Kardell: Yeah. I'm pretty sure that they don't use XSLT anymore If they did, this would end the discussion really quick.
Liam Quin: Right. But it's interesting because it's not ... Because it's a dynamic application. If you did a static crawl, you might not realize, okay, so it's the secondary data that's being sent. When we made XML and I was on the working group that made XML from STML, we never meant it to replace HTML. XHTML was a great surprise to all of us or almost all of us. And we did not mean XML to replace HTML. And the fact that there were people going around saying that I didn't hear about until years afterwards because it makes no sense to us either. But I think there's two aspects today for XSLT in the browser, two aspects. And one of them is, can we replace the technology and keep it there? For example, there are two Rust implementations of XSLT that I know of. I don't know if they're built in the necessary way to make them embeddable in a web browser usefully, but that's a possibility.
Brian Kardell: Yeah. This is along the spectrum of the options that I was discussing, right?
Liam Quin: Yep. And when newer versions of XSLT were written, careful thought was given to the question, what happens if an XSLT-2, for example, implementation receives an XSLT-1 file, but it's not labeled XSLT-1, what's the backward compatibility story? It's actually very, very good. And if it is labeled XSLT-1, that's a different matter. It can run perfectly. That's up to the implementation. So that information is in the specs. An XSLT requires a version attribute on the top level style sheet element. You have to say version equals one. So the only time this is a problem is if someone has put XSL version equals three into a style sheet that they run on the browser and expect to work and it's been accepted and been working and now it's interpreted as XSLT-3. But that's a pretty obscure case. And that's comparable to the case where your CSS is not in UTF-8 and you serve it up as UTF-8. And it happens that in this character set, an É is represented as a closed curly brace and it happens that the error correction means your page looks as you want it to. This thing really does happen, but we're talking 10 to the minus 6%. But the other side of this question, replacing the technology is one question, but the other side of it is, if you were to put XSLT into the browser today, how would you do it? What would you do differently? Would it be useful? And if it was useful, what use would you use it for? Well, we know there are users because people write custom elements in HTML and there's a big overlap between what you with custom elements and what you do with XSLT. And in both cases you have the difficulty, for example, that Google's search engine doesn't know how to render snippets if they rely on formatting of custom elements. Because there's no a priori styling. Should this element start a new paragraph or is it in line? And if it's in line, should it have a font difference or not when we do the Google snippet? And Google does the best it can based on heuristics. You have the same problem sending arbitrary XML to the browser. Google doesn't know how to make snippets because it's just a bunch of codes. But somewhere in between lies this sweet spot. And if you have something declarative where you can do joins with XPath and they're efficient then and they are. XPath engines typically do optimization and that's going on in the browser. I'm not hearing calls to remove XPath, which is more heavily used as a JavaScript API.
Brian Kardell: That will be interesting though, because there are a trail of technologies here and it's interesting to ask these questions about them because it's more widely used because it has more uses. XSLT has one job. And it's very specific, but XPath you could use for several things. But also the XPath engine in browsers is old and also really basic and also not good. And so there have been discussions about let's upgrade it. Basically it's the similar conversation. It's like well keep it, but ... Nobody's proposing that currently. What this gets at though is the open source for the browser is a commons. And we have this idea that we should collectively own the commons, but we also have this collective idea that Google should pay for the commons. Apple is paying from the money they're getting from Google, and so is Firefox. This is the source currently of all the funding. Basically we show up at standards organizations and if you don't work for a vendor, you are effectively begging for people to understand your priorities, agree with them and spend their budget on this. And they're a small part of giant company.
Liam Quin: I think it goes back to the guy with his car turning off his engine illegally, by the way and an idling home to save fuel. It's a way of looking at things. The way that you get someone with money, whether it's a CEO or CTO or Lord of the Manor, the way you get someone to do something is you demonstrate to that person that it's in their interest. And the only way protests work is if the protests is so inconvenient that it's in your interest to do the other thing. It's not because you've suddenly changed, you've become really left-wing and you agree with the protests. It's because the protests are in the way. And if the protests don't work, the only way it happens is the protests get more serious. The First Nations people here were being ignored. Where I live, there's a reservation a few miles away. They were being ignored and they had a land treaty that was not progressing in the courts and it had stopped and issues. You get things like boil water advisories and the government doesn't really care. And so then they say, 'Well, okay, the main line between Montreal and Toronto runs through our reservation. All trains to stop as of today.' And that gets covered in every national newspaper. It gets covered on every website, huge coverage. These evil, nasty people are stopping the trains. And the government people go there and say, 'Why are you doing this? You've no reason to do this.' And they say, 'Well, we're protesting this and we're going to keep doing this until you solve this. And no, you can't send the military or the police onto our land because we're a separate country.' And the government says, 'Okay, okay. We'll talk about the land treaty.' And it worked. So protesting in a GitHub issue, it doesn't work to say you are evil. I completely agree. But what might work is to say, what benefits could you get by reinvigorating XSLT? Is it worth having a workshop to talk about what would happen if you put XSLT-3 or four into the browser? What would be the pluses and minuses and other things that the XSLT people could do to change XSLT because it's not set in stone. It's a spec like everything else. Other things that could be done to change it, that would make it really exciting for browser people. Bring in more revenue.
Brian Kardell: A statement that Mason made in this is like, it's not to disparage the language or to discourage its use. It seems like it still has quite a lot of use. It's just that it seems not much of it is in the browser beyond podcasting, but beyond RSS.
Liam Quin: The most popular ... I'm going to interrupt you for a sec, I'm sorry. The most popular XSLT I see being put into the browser today is injected with JavaScript and your web crawl won't find it. And the most common implementation is SaxonJS from Saxonica and it runs in the browser. It supports interactivity. You can say things like, when this event happens, do this. So people are writing interactive applications with it, universities in government all around the world, but it doesn't show up-
Brian Kardell: But it's not native.
Liam Quin: It's not using the XSLT that's in the browser.
Brian Kardell: And the browser vendors are fine with that. That's good.
Eric Meyer: Yeah. I think that's part of their argument that they could take XSLT out because the XSLT that's actually being used according to this argument is through things like SaxonJS.
Brian Kardell: Right. But then they would say, 'Show us the data that it is getting lots of adoption.' And then like you say, we've made the case that we should a new version of it natively. So does the current version that's in browsers service anyone in a really real way that we couldn't move the needle? So some of these things, like even the podcasting services, there's a limited number of podcasting services and Google can pay to work with them over the course of the next five years to change their approach and knock the number way, way down. But if there is real use, if it is gaining adoption through including a JavaScript library or somebody who's taking this Rust one and transpiling it to WebAssembly, whatever, I think that's fine. Great. Actually, I would love to see something take off and gain enough traction that browsers were more or less forced to sit up and go. No. that's a good idea. I mean, I feel like that is a problem of web standards in general that we can't predict adoption. And I think the adoption part is in the end almost more critical than the goodness part. HTML is not especially good. Tim didn't even design it to be especially good. It was just like was the least common thing. He even imagined that it would not be most of what you would ...It wouldn't be video and interactivity. It would just be this simple-
Liam Quin: Anders Berglund ... Tim walked across the hallway at CERN and talked with Anders Berglund who was working with SGML and Anders showed Tim the SGML starter set of tags, and that is what became HTML.
Brian Kardell: Yeah.
Liam Quin: So there's possible futures. The worst one I see is simply taking XSLT away without supporting the existing XSLT processing instruction. The next one is supplying a JavaScript polyfill with the browser that when the processing instruction is seen, that would've run the in-browser XSLT engine it now runs a polyfill in JavaScript. That polyfill should be done well enough to expose XPath functions that people have added through JavaScript but that should be quite doable because they're in JavaScript and not all browsers supported that anyway, because an external XSLT engine couldn't. So what I'm basically saying is that's a typical edge case to test for feature parity. And if they get rough feature parity with the XSLT-1 ... And the XSLT-1 is a really simple language, especially if you've already got XPath. So as Mason pointed out in the comment, he says he's got a polyfill. So step one would seem to me to be remove the C implementation and instead use a JavaScript implementation. I personally think that would be a step forward. I think it's not a bad thing at all. It might not be as performant, it might be slower, but computers have got a lot faster. It probably won't be an issue. If it is an issue than the answers to fix it. Start with the polyfill and say it's too slow, how do we fix it? And the second question is it an opportunity to add an API in some way to run a newer version of ... Or simply to be able to run newer versions of XPath, newer versions of XSLT? And for that, the Rust implementations seem to me to be most promising. There's one that's being sponsored by Paligo that's got a little bit further than the other one that was being done by volunteers, but they both have gone far enough that with a little injection ... Certainly the one with Paligo is in a Apache or Mozilla style license, that means it's a candidate for being included in a browser. That's not GPL and it's not under a proprietary license. So I can see it could potentially happen. And then the final question is, can we find business case level benefits for putting a newer XSLT in the browser given that it's a new thing to support? Is it worth it? It would be nice to have that conversation in a non-hostile environment to say, let's get together and ask, are the benefits to moving forward that are not just for the people who really love XSLT, but are the benefits to the browser vendors as well? And are the vendors, in other words, are the benefits to the web as a whole.
Brian Kardell: Is there anybody using this to transform JSON.
Liam Quin: Yes. They're using X and JS, for example, with JSON? Yes, that's quite common.
Brian Kardell: And in the browser. Yeah, I would just be curious to see that. If you can share a link, we'll include something in the show notes so that people can have a look at it. I do think that there's something interesting about XSLT in that it is the only templating language that ever made it in the browser natively. Like I said, I was not really a fan of it.
Eric Meyer: The syntax hurt my head.
Brian Kardell: I don't mean that to be hurtful to the people who are listening. You can like what you like, that's fine. Just for me, I was not a fan of it. But again, going back to the one thing that was good about it is that it was standard. You could use it in a lot of places, and that's worth more in a lot of cases than lots of other things.
Liam Quin: When I teach XSLT, one of the things I do is I have to explain that it is a functional language like ML or Haskell for example. It's a functional declarative language. So for example, when it talks about a variable, it means it in the math sense, you can't update a variable. You can't increment a variable. Just like in maths, you can't say X equals X plus one that will get your maths homework torn up by the teacher and fail. You can't do that. It's declarative and it's functional. And that becomes more explicit in XSLT-2 where you can explicitly define things called functions. It's more obvious. And actually XSLT-2 is easier to teach than XSLT-1 because of this. Because it's nature, it's more visible When people don't get it ... Like if you go to W3 schools for example, or certainly years ago, and look at the XSLT stuff, it's very procedural because the person writing the tutorials didn't get it at the time. They may have updated it. But it would say first it does this, then it does this. XSLT does not have loops, for example. It has declarative functions that say when you get this value, you have this result. And the fact that it calls it XSLT for each is misleading. It's not a for each loop, like in Prologue. It's an extensional mapping like you might find in Haskell. If you start out by learning it's a functional language and the right way of thinking, it's quite easy. But if you start out thinking it's this procedural thing for doing transformations, you're fighting it all the way and you'll hate it. And I'm not saying that that happened to you, but I am saying it's very likely because of the resources that were around at the time.
Brian Kardell: Yeah. No, I think that probably has a lot to do with it. And also my background at the time was pretty specific. Anyway, I would be super curious to see what people are doing with XSLT today. I know that the what working group people would be super keen to hear this information. If you want to provide me with any information, I would be happy to bring it up in the next meeting. I believe it's on Thursday.
Liam Quin: If I can be useful, I will happily do that. And certainly I will try and get you some ... I don't have to hand an XSLT in the browser showcase. I don't have to hand a circuit breaker panel in your basement showcase either. But I don't want my circuit breaker panel in my basement to go away, even though I spend less than an hour a year in front of the circuit breaker panel.
Brian Kardell: Fair enough. Sure.
Liam Quin: Rely on that. Note also, that XSLT can run on ... In the browser it can run on any DOM. It doesn't only run on XML. So it's not an XML-only technology. Obviously it can run on XHTML, but once you've paused your HTML, it can run on the resulting HTML DOM as well.
Brian Kardell: Yeah. I'm super curious to see. I know that there is a person who's in the web components community group who's really keen on using XSL in this respect. I don't see it as probable because I don't see the adoption, but maybe I'm just looking in the wrong places. Anyway, I would be keen to see. It will be interesting if the usage is much higher and more outside of those areas, then ... Google is not going to ... None of the browsers are going to willfully break Congress. I can promise you that. I can promise. So this is about people trying to run an open source project and direct efforts the best way that they can.
Liam Quin: Yep. No. I understand completely. It's fine. Yeah. All right.
Eric Meyer: Liam, thank you very much for joining us. We really appreciate it. Anyway. Yeah.
Eric Meyer
Brian Kardell
Liam Quin