Eric Meyer: This episode of Igalia Chats is brought to you by WPE WebKit, a port of the WebKit web engine that's optimized for Linux embedded devices with a focus on performance, hardware, acceleration, flexibility, and having a low memory and storage footprint. Visit wpewebkit.org to learn more about it and find out how you can collaborate with the project upstream.
Brian Kardell: Okay. Hi, I'm Brian Kardell. I'm a developer advocate at Igalia.
Eric Meyer: And I'm Eric Meyer, also a developer advocate at Igalia. It's Interop time.
Brian Kardell: Yeah, it's that time again. So yeah, we thought we would talk about Interop, I guess the close of '25 in the beginning of 2026. And maybe just a little bit the project in general.
Eric Meyer: Just as a quick summary for people who maybe haven't paid attention to Interop, the way it generally works is in the late summer to early fall, the Interop group opens up a call for proposals from the community. Anyone can propose, 'Hey, this is a thing that I think should be an Interop.' So it could be MathML or it could be this one specific part of a JavaScript API that nobody has implemented or only one browser has implemented or whatever. And so a bunch of proposals come in and then that period is closed, and then the Interop group works through that list. And so anything that doesn't have tests, that gets dropped. Because Interop is very much about measuring progress and interoperability, and we use web platform tests to sort of gauge that. Like you said, if Chrome is passing a bunch of tests, but nobody else is implemented that, so they're not passing any tests, then that has a very low interoperability score as opposed to maybe everyone has implemented half of a specification, but if they've all implemented the same half, that could actually be a higher interoperability score. Still not a very good one, but it would be higher. Anyway. So things that are speculative tend not to make it into Interop. So someone might say, 'Hey, this new spec is being finished up. You should put that on.' But it's like, 'Right, but the spec's not done.' And without a spec that's in relatively solid shape and without tasks, it's probably not going to go forward. And then it has to get winnowed down even further just based on what the teams are willing to commit to do, because all these companies have browser teams where the browser teams do not get anywhere close to really an even noticeable percentage of the revenue of those companies. And so they have constraints, they have resource limitations. They cannot just say, 'Yeah, we'll just hire enough engineers to do all of this.'
Brian Kardell: And they all have different personnel, which is easy to forget. So it's easy to forget that these three people are out on parental leave and this person is the one person who is our super expert with X, Y, Z, and would be able to do that very efficiently. And they're dealing with-
Eric Meyer: On sabbatical.
Brian Kardell: ... with their partner... Right, exactly. They're on sabbatical, their whatever, or we're in the middle of a major rewrite of our whatever we are currently. There's so many things that go into what is the state of a project that even literally, if they all started from the same... If everything was a fork of the same project 10 years ago, but had different budgets and different going forward, it would slowly drift to where those were completely different propositions.
Eric Meyer: Absolutely. So the list gets narrowed down,
Brian Kardell: Its get winnowed down, not just based on your resources, but based on all the signals that we can find go in as an input to that too. So to an extent, we go in with a sort of like a, 'Hey, this is our sort of wish list of things.' This is what we think from our perspective, all the inputs that we can find, this would be the most valuable stuff to prioritize. Now let's see what we can agree can be prioritized. And to that point, it has to have tests, and we need to be able to find a plausible way to get it done.
Eric Meyer: And it has to be a thing that none of the browser makers have said, 'We are not doing that,' for whatever reason. There are some proposals that get dropped because one or another, the browser makers have said, 'We're not going to do that for security reasons,' for whatever reasons. Anyway, a lot of this is playing catch up with Chromium. It's true. And part of it is that Chrome is the R&D arm of the web to a certain extent, but it's also, I think because of that community input, from the developer point of view, it's like, well, Chromium lets us do all of these things, and other browsers have not necessarily shipped all of those things. And some people would say that's because Google incentivizes their engineers to ship new things. Others would say, well, they just have a much bigger budget, so they are able to try more things out. So there is a fair amount of that.
Brian Kardell: And it's not completely that way. There are things where both Firefox and Safari are getting 66.6% and Chrome and Edge score zero, the media classes, the media pseudo classes that were taken up. So those are playing and those kinds of things. There's the play state and some timing related things, sound state. So for whatever reason, those were prioritized in those other engines, maybe because they were easier to do in their architectures, who knows why?
Eric Meyer: And that actually, one of the things that is where Chrome needs to catch up is JPEG XL, which was selected as an investigation area this year, it's in, for the last few years, people have asked for it, and it's never gotten into Interop, which has made some people very upset. But it's in this year as an investigation area, not as a focus area. The goal of an investigation area is to eventually get something to be a focus area. But the problem is JPEG XL doesn't really have that many web platform tests, and the tests are not as wide-ranging as they should be. So the investigation area actually has a roadmap of tests to create and put into web platform tests. And then ideally, next year it could be a focus area or even more ideally by the end of this year, because the tests are there, there's no need to put it in Interop because it's already Interop. So we'll see how that turns out. But that was how it was included this year. And just as we were getting ready to launch Interop 2026, a Rust implementation actually did land in Chrome behind a flag. So if you enable the flag in Canary, I think, maybe also in this table, I don't remember now, you could actually display JPEG XL in Chrome if you've enabled this flag, but it's not on for everybody, so it's not ready for production. This is what browser makers do when they're trying out new code, is they put it on behind a flag. People who are interested can check it out, hopefully if there are any bugs they're found, et cetera, et cetera, et cetera. And things can stay behind a flag for a while. But anyway, yeah, that was sort of the big shift from previous years. Sort of an example of here's a thing that people kept proposing and it kept not being picked, but this year it's in this investigation way. That's one of the four investigation areas, and at least two of them, I think, is it two of them. Now it's kind of all of them are... We are not sure how to test these things, so we're going to investigate to see if we can figure it out. Mobile testing is one of them. Accessibility testing is another. You can do some mobile and accessibility tests in an automated way, but the really important tests, it's very hard to figure out how to do in an automated way. So yeah, it'll be looked into, but who knows how those will turn out. The JPEG XL is much more sort of defined. Like I said, literally there's already been written a roadmap of these are the tests that need to be created. Someone just needs to create them, and then maybe we'll figure out that we need more. But this is sort of the minimum. When it comes to mobile testing, there's just questions. How are you supposed to do automated testing of orientation landscape versus portrait, or any of the gyroscope APIs or whatever? Those are really hard questions. So yeah, there was also web VTT. Apparently it's inconsistent and it needs better tests. So that's the last of the four investigation areas.
Brian Kardell: Time, text for video and for audio too, I think. Right?
Eric Meyer: I think so. I think it's just media in general. And then there's another sort of bucket, which is called WebCompat, where there are three things that kind of went in there. Module loading in ESM, taking the WebKit prefix off of user select as part of WebCompat. The timing of scroll events relative to animation events, because the exact timing of where scrolling animation events occur in relation to each other can have a very profound effect on how scroll linked animations work and what you can read programmatically through the API. So through that, sorry, through the DOM API. So yeah, those are sort of in there. I think scroll events relative to animation events is one of those. We just really need to get it nailed down that everyone is considering those things in the same way. You could have all three engines fully supporting scroll events and animation events, but if they're figuring them out in different orders, you can get different results. It's just one of those really subtle little behind the scenes thing. But yeah, there's a bunch of other stuff. Most of it's CSS, but I feel like that's because CSS handles the visual presentation of things. So noticing inconsistencies is much easier there than it is with let's say HTML parsing.
Brian Kardell: Yeah. I think that the CSS working group is bigger, gets a lot more funding. It definitely creates a lot more proposals. There are a lot more places for things to plug in. And there are a lot of things in there that are maturing after years or even decades. A few years ago, `:has()` was on there, and that originated in 1999, was the first proposal for that. This year, I think that the CSS attribute function.
Eric Meyer: Yeah, absolutely an example of this.
Brian Kardell: So yeah, I think there's just a lot more raw content there. It's easier to test, and it's gotten a lot of funding over the years for stuff. So we do tend to see, I think every year we tend to see a fair bit of stuff that's CSS, but it's not everything. I think it's maybe about a fourth of the stuff.
Eric Meyer: I would say half. Yeah, it's 11 CSS primarily... 11 primarily CSS areas out of 20. Now, some of those do bleed across between things. So the custom highlights API is one that I would call like CSS custom highlights. That's kind of a CSS thing, but it's also about the API, so you can talk to it through the DOM. So that's kind of both CSS and JavaScript.
Brian Kardell: No, you're right. For whatever reason, we prefix these with some of them with CSS and not others. So you're right. There are some in here that are... I was not immediately visually grouping them, but they definitely are CSS. So yeah, it's still, it's about half.
Eric Meyer: Just a little more than half. The rest is JavaScript. There's one primarily HTML, which is a dialogue and popover, specifically additions to the dialogue element and the popover attribute. So you can do a dialogue closed by any, for example, and there's a popover equals hint that got picked. And this, again, leads a little bit into CSS because there's also the open pseudo class that matches anything that has an open state that could have a closed state. So an open dialogue could be matched using the open CSS selector the pseudo class. But again, that needs Interop work. So even though that's sort of the HTML Interop focus area, it's mostly HTML and a little bit of CSS. And as we were saying, several of the CSS ones are mostly CSS, but a little bit of JavaScript or maybe a lot of JavaScript, depending. And then, yeah, the rest of them are JavaScript, like Fetch. You can do uploads with Fetch and some kind of... There's a range header. I'm not as familiar with this sort of thing, but apparently when you're sending a Fetch request or you can send some kind of a header to say, 'I will only accept bytes in this range.'
Brian Kardell: Yeah, you can do range requests. I think, I mean, not that this is all it's for, but I think if you scrub a video, it can make range requests to say, 'This is where I'm looking for in this particular video.' I don't know how interesting it is to go through all them. Maybe we can just pick a few or just kind of rattle off some things we think are interesting. But I would like to, before we do that, talk about really quickly why I really like this project.
Eric Meyer: Sure.
Brian Kardell: I don't know how many people out there can relate to this, but I know you can relate to this. When Eric and I were getting started in the web, figuring out what actually worked in the intersection of browsers was challenging. But one thing that was really positive is that there was always news and people talking about, well, the next version of HTML, the next version of CSS. We're always looking forward to this thing that was only a year or two on the horizon, and we had these discrete points where... And there was something to that definitely, because since then we've had people like Jen Simmons, maybe also Rachel Andrew propose in CSS, 'Let's do CSS 4, let's do CSS 6. Let's set those sort of labels because they're really kind of useful.' They're useful. So in practice, there's only whatever is deployed, and that's a living truth, but putting some kind of goal that we can commonly shoot for and a timeline and to say that is what we absolutely going to strive for that. We want to surpass that, but at a minimum, we really want to get to that. So I feel like that's really good for the community because we can look to these things and say like, 'Hey, we might get more stuff.' I mean, not might, we will get more stuff in at least some browsers. Every browser is going to do more than this stuff. Maybe we'll even get more interoperable things, but at a minimum, these are the things that we can look forward to next year. These are things that would make sense for you to invest time and learning. These are things that would make sense for you to read about, to blog about, to get experience with, even if it's just playing around with it, because these are things that you will be able to turn to in the very near future. So I really like that. And the other aspect of that is that it plays a role, I think that was similar back in the day in terms of having a common goal that you're shooting for does help you align priorities for implementers. And I think when everything is just modules and everything is moving at its own pace and everything is sort of living standard, I feel like there was a period in there where things just got too ragged, right? Because there was not enough sort of shared vision of priority and aim. And we agree this is where we're spending our time, and I feel like we entered a new kind of period of developer unhappiness. So anyway, I really like that about this project. I don't know if you see those similarities or agree with that framing at all.
Eric Meyer: Yeah, I mean, I do see the similarities. It does definitely... I think at this point, because this is the sixth year of Interop, we have five previous Interops. One was called Compat, but it's five previous Interops. And there's a track record of by the end of each year, the things that the team agreed to work on got worked on and came up to very close to 100% interoperability. I mean, getting to pure 100% is probably an impossible challenge, but getting to 99 and maybe a couple of 9s is very good. And so there is that track record. There's a history of the project each year says it's going to do these things and those things get done. So we are now, yes, I think at a point where you can say, okay, by the end of the year we should see much greater interoperability, much more consistent behavior on anchor positioning, which is one of the ones that got picked or advanced attribute handling, which one or two browsers do already, but not everybody. So yeah, it does have that role of being able to say, oh, this is a thing that I should probably look into this year because by next year it will be useful to know this thing because it's going to be much more interoperable. Or for that matter, it could also serve at the end of each year you look at what was done and say, okay, in the coming year I'm going to learn about this because in my situation, I actually have to wait longer than just immediately. I need to wait a year or so.
Brian Kardell: Yeah, totally.
Eric Meyer: Yeah.
Brian Kardell: I think one of the things that for me that I meant about that is this gets into things that we talked about, we also are involved in the baseline and stuff like that. One of the things that for me as somebody who is always like... I like to see conference talks and read blogs, and I follow lots of people who work for browser vendors and we work with people who have other companies where we're developing proposals, and we have an implementation in one browser. And you can easily forget what is real out there. You can get way ahead of yourself. And I think that one of the things that this really gets for me is if it shows up in this list, that's real. That is absolutely real. There are no questions about whether that's going to happen. So yeah, I like it.
Eric Meyer: And it's a cross vendor realness. It's a promise from everyone involved.
Brian Kardell: Everyone. It's from everyone. So this is not saying if you disagree with Google's not implementing something or Safari not implementing something or Firefox, not that you shouldn't go complain to them and try to get them on board or whatever. Sure, go ahead, go do that. But these one, these are real, you know what I mean? These are coming.
Eric Meyer: Agreed.
Brian Kardell: They're not speculative time investments. It might be speculative in terms of you can't use it in a production project yet. If that's your use case, very possibly you can't. And like Eric said, maybe you want to look at them at the end of the year, but either way, it's like that knowledge isn't going anywhere. These are important standards.
Eric Meyer: Yeah. So what were some that you really liked?
Brian Kardell: Container style queries is, I think, huge, right?
Eric Meyer: Okay.
Brian Kardell: Before we had any of this, I had this library and Francois Remy, do you remember him? This is working group. He and I worked on CSS custom properties. They were originally just variables and we stressed this idea that they were custom properties and that we wanted to get this ability to observe them. And that if we could only do that, then we could do so many things, like maybe everything that you would want to do. It would be, you could use this to achieve so many things. It's 14 years since then or something like that. So seeing it come about in kind of almost exactly the sort of way that we imagined took longer than I had hoped, but I'm excited to see that come about.
Eric Meyer: Yeah, I agree that it'll find it very useful. The example that's shown in one of the blog posts, the one from WebKit actually is exactly my use case, my first use case. I'm sure that there will be other use cases where you can do an ad container style and then in the style (--theme dark.) So if the theme variable has been set to dark, then do these things use the dark mode colors. I ran into this very problem on working on agaia.com where I needed to have the colors be correct, whether you're in light mode or dark mode, whether you are setting your light mode, dark mode based on your operating system preferences or your browser preferences or the little toggle that we have. And I ended up writing some patterns that I didn't really enjoy, but they work. This would've made it much easier. So yeah, looking forward to that. For some of my favorites, I'm going to push outside of my usual zone a little bit.
Brian Kardell: Oh, nice.
Eric Meyer: I am super hyped for the navigation API, not because I'm going to use it necessarily, but because I have done JavaScript trying to figure out history in browsers in the past, and it's just such a nightmare. And the navigation API just makes all of that much cleaner, more reliable. I think for people who do need to, for whatever reason, track state, if you... Sorry, need to track history and the state of the history and maybe modify stuff and just figure out navigation where you are on the site based on whatever, it's just going to be so much nicer.
Brian Kardell: Anchor positioning is really, really high on my list, but it was actually on 2025 and it's also on 2026, so that is a little bit hard to understand and sure if you were an observer.
Eric Meyer: So that can be for a variety of reasons. So an example, and I think this applies somewhat with anchor positioning, is that in the process of becoming more interoperable, it is discovered that maybe parts of the specification aren't as clear as the spec author's thought. And so in trying to figure out, okay, there's no test for this, but here's how different people have interpreted it. Or there is a test for this, but one of the implementers profoundly disagrees that the test is even correct. And sometimes those things have to go back to the working group and the working group will say, 'No, the test is correct for reasons XYZ.' Or, 'Oh no, you're right, actually, here's how it should be different. And so we're going to have to change the test.' It can also be that as the interoperability gets better and the teams are working on making that interoperability better, they find things that the spec just didn't address because nobody thought that any author would ever do such a thing. But authors are endlessly inventive in the ways that they can push various specifications. So sometimes it can be a case of given what we've seen here, given this signal that we're getting from the community, we need to make these changes. And so you get these carryovers, is what we call them in Interop. Anchor positioning is one of five carryovers from 2025 to 2026.
Brian Kardell: View transitions is on here. And I think view transitions are really cool.
Eric Meyer: I don't know if this is technically a carryover, I can't remember now, but for those who have paid relatively close attention to the Interop process, view transitions were in Interop 2025, but it was only for same document view transitions. So it was only moving an element from one place to another and animating that very smoothly. This year, 2026, it will include the cross document view transitions, which I think is probably what you're excited about.
Brian Kardell: I mean, I'm excited about all of them. I think that they're an idea that has been around for a really long time, and they are a thing that native... You could reasonably make the case that everything that we did that gave us so much JavaScript was around the fact that we really did not like the experience of the entire page going away. It felt not all like most native applications. And so we built all these things to make single page apps and things like that and made a lot of complexity. But here with view transitions, we get these nice kind of silky smooth feeling, much more native sorts of things for very, very low, discounted prices. And I think they're nice. They're generally progressive enhancements. Yeah, no, I just think that the design of them and everything, at least all that I've seen so far has been really, really positive.
Eric Meyer: Yeah. A good example of a way to use them. I mean, sometimes yes, you can get this whole silky smooth thing, but they really kind of link pages together conceptually in a way. And I think a good example of this is DaveRupert.com, our good friend Dave from Shop Talk Show. He has on his site, if you go to the homepage, there's his name, there's this huge Dave, but then if you click through to one of his blog posts, it zooms small, it scales down really quickly. The rest of the page just loads in the way that you would normally expect, but there's that link between the two, so it doesn't feel like you've abruptly jumped from one place to another place, even though you have. And so that's I think a really good example of just a light touch, low impact thing that creates this bond, this link between the two visually where you don't have to make the browser load the entire page and animate 600 things at once, which sure people will do. Mean, they already do it in apps, but here I like the way that Dave did it, where it's like, okay, just this one thing, zoom, and it doesn't take a ton of time. And if you're not paying attention to the page, you wouldn't necessarily consciously register it the way that he's done it. But I think subconsciously even it feels more unified. So it's very cool. And yeah, that cross document view transition is in this year's Interop. I don't know, I'm wondering... Because last year, like I said, it was just for same page transitions. And even that, the Interop score went from nearly zero to about 90%. And I think probably some of that was again, due to the target moving a little bit, as there was a switch from single page to multi-page. This year, if you just look at view transitions, it's starting at not quite 80%. I think the Interop score is starting at 75, about 75%. And so hopefully that should be very close to 100% or maybe even 100% by the end of the year.
Brian Kardell: The Interop score is probably the simplest, best thing that's happened in a really long time because it's misleading. If you have say 10 tests and three different engines, and each one passes 50% of the tests, it's possible that no test is interoperable, which you wouldn't think if you just saw, oh, well, they're about halfway implemented. As far as any usefulness goes, they're 0% implemented because nothing works the same on any of them. I love that score. It's the most important score, and it's a very keen measure that's way better than anything else in web platform tests. It's an exceptionally true and fair view of what we're looking at.
Eric Meyer: Yeah. And the Interop score can never be higher than the lowest single implementation score. So if you have two implementations that are just 100% consistent with all the tests and then the third comes along and it's 75%, then the Interop score cannot be any higher than 75%. But it can be a lower, like you said. Yeah, it is really weird until you actually sit down and create a little table for yourself where you're like, okay, how can I make it so that every column has five of the 10 cells filled in, but no row has all three cells filled in?
Brian Kardell: And it's not hard. It's very easy with that.
Eric Meyer: It's not hard at all. So yeah, speaking of things sliding around like we were with view transitions, there's a couple of scrolling things as well. Scroll-driven animations and scroll snap are both in there. They're separate focus areas, but they're scroll-based so I think of them as kind of the same, personally. But yeah, scroll-driven animations are real interesting to get your head around. They seem super simple and I guess conceptually they kind of are, but figuring out exactly what to do at what point is... I've done some testing and there's already a lack of interoperability even when the same things are implemented, because they're slightly different timings or maybe completely different timings. But that'll get better. And then scroll snap, been there for a while, but-
Brian Kardell: Not very interoperable currently.
Eric Meyer: Right. This is one of the ones that they actually call out. It has sort of the Flexbox problem where Flexbox got implemented early by a number of browsers, but at different points, which were deeply interoperable for years. And it's the same kind of thing here with Scroll Snap, where there were a lot of changes, there were a lot of updates, a lot of things that seemed like a good idea at first that eventually got thrown out of the specification entirely or completely rewritten so that the syntax was entirely different. All the things that Grid did not suffer from, but Flexbox did. And Scroll Snap is one of those that has suffered from that a little bit. So there's a lot of work to be done to make that interoperable so that you don't have to just say, 'You know what? I'm only going to support Scroll Snapping in this one browser, or I'm only going to support this limited set of Scroll Snapping that most browsers get mostly right.' It'll be much closer to the ideal of I just rate my one set of Scroll Snap stuff rules and all the browsers do it the way that I wanted it to.
Brian Kardell: Yeah, a few years ago I was... Adam Argyle had made some scrolling tab thing when we were working on tabs and it was kind of a different model, and I built a little prototype of something using the Scroll Snap stuff when it was much, much newer and none of it worked today. So that's terrible because it's linked up on my blog somewhere or something and it's just completely broken now. It's great. It's great to see that all getting lined up and everything,
Eric Meyer: Yeah. Which it touches on when you said earlier, Chrome is sort of the web's R&D department. To a certain extent because they have the resources and because they have the incentives, a lot of the stuff they do implement early, they're willing to put that in. And I was like, hey, here's a working implementation of thing, in this case, Scroll Snap and does it work the way that it's supposed to? And that then sometimes the working group will look at it and say, mostly, but not this part. So let's redo that part. And that doesn't explain every bit of interoperability, but that does sometimes happen. And Chrome can sometimes be first to these things because yeah, they have the resources sometimes to ship an early implementation of a thing. I know there's one on here that I'm pretty sure that you're excited about, which is the scoped custom element registries.
Brian Kardell: We'll see, I guess. But basically what it allows you to do is within this element, register this element so you can have an ex-foo element that contains an ex-foo element that's a different ex-foo element. And I understand why. I'm not going to argue that people don't want to do that. They do. I think that it's interesting. I'm glad that people are going to get what they want. I speculate that in practice, it will be used by very specialized use cases and that most things will be scoped to the document and that most people will find it more useful to follow a pattern where you define the JavaScript interface, the class, and you leave it to the importing document to define what element name to use. That way, it's like ability to namespace. You could have two buttons that are inside of one another. You can't really... Don't do that. Don't put two buttons inside one another. But conceptually, in terms of naming, they could be different things and they would just have different tag names. And I think that makes it easier to read as well, because you don't assume that they're the same thing.
Eric Meyer: Yeah, that makes sense. If anyone listening is hot on WebAssembly, there's the JavaScript Promise integration API that lets WebAssembly work in a JavaScript promise await kind of situation. Agalia has done a fair amount of work with laws and that sort of thing.
Brian Kardell: Yeah, I'm actually more excited about this than I am about the other one. And the reason is just because I'm keen to see what it makes possible. I know that a lot of our teammates, people on compilers are very interested in this. And it's an interesting kind of thing, because as I understand, it basically will make it possible to take things that were written synchronously and make them able to work asynchronously. So nobody writes WASM, right? Nobody writes WASM, they write C or something else and then they transpile it into WASM. And I think a lot of the things that were originally written were assumed that they would be synchronous running a very particular kind of model. And maybe that model isn't ideal or even possible in the web. You don't want to block the only thread. So yeah, I'm keen to see what happens with this. I'm not down with the WASM enough to know how big an impact this will have, but it definitely seems that the people I know who do know are excited by that.
Eric Meyer: Okay. Yeah, there's a get all records for IndexedDB. IndexedDB has been there for a long time, but literally Interopt this year for this is just the get all records method because it's new-ish, and you can do some really cool things with it, like query all of the records and then batch them up or return them in the order you want. And we didn't really talk about custom highlights before, but those are in here. And the custom highlights API so that you can do custom highlighting from the JavaScript side as well as use the highlight pseudo-element on the CSS side. Some pretty cool stuff. One of our colleagues here, Delon, has done custom highlight work.
Brian Kardell: I think Steven also has done custom work.
Eric Meyer: Steven. Yeah, I was going to say Delon's not the only one, but I just remember because Delon is the one who did the bad spple using CSS custom highlights.
Brian Kardell: It was absolutely wild. We're going to link that in the show notes because if you haven't seen it, you have to see it. If you don't know, the bad apple thing is frequently used to do performancey demos in places where you wouldn't expect it, like terminal things, but seeing it done with custom highlights was pretty wild
Eric Meyer: Not always performancy. Sometimes it's the... I mean, it's been said that anything that has a computer processor will eventually be used to run Doom and any display will eventually be used to display bad apple-
Brian Kardell: There you go. There you go.
Eric Meyer: ... is what I've heard people say. And display has a very wide, I literally saw, I think the other day where somebody took a whole bunch of those small plastic red apples, and laid them out in a grid on their floor and just arranged them to shoot every single frame of-
Brian Kardell: That's wild, right? See people who do these things where they're projecting animations in LED lights around their house on Christmas and stuff and playing whole movies with sound effects and stuff, it's amazing. Yeah.
Eric Meyer: Anyway, so that's in. Custom highlights are fairly new. I mean, on the scale of web standards progress, they're pretty new, and implementations have been getting better. Different browsers have been advancing at different rates and this is supposed to bring it all together, so that'll be pretty cool.
Brian Kardell: Yeah, WebTransport is in there.
Eric Meyer: Yep.
Brian Kardell: Basically it's like a HTTP three transport, right? Is it quick?
Eric Meyer: Yeah. I guess you can do... Well, it kind of links together with another one, which was WebRTC in that WebTransport lets you get very sort of high performance, low latency connections. And WebRTC, which is real-time communication depends on that sort of thing for good video conferencing or audio sharing or whatever data for that matter. Just this is a carry over. I think just because it didn't quite reach the threshold that the Interopt team likes to see. They made it to 91.6 in 2025, but really aim for higher than that. So it was a carry over in part I think just because in real time communication settings, there are a lot of failure states and a lot of things to test for.
Brian Kardell: Yeah. So I had said, is it quick? So it is, so WebTransport is the modern update to WebSockets, if you can remember that. But it's backed by HTTP 3, which was originally a Google proposal that they called QUIC, Q-U-I-C and it can be more performant than TCP, in progress in development since 2018. I remember some of this because Mark Nottingham, who was the chair of HTTP, came around 2018 and gave a really nice talk to the local meetup group that I was doing here, and he talked about some of this. So anyway, it's based on QUIC, which is itself, I think based on UDP rather than TCP, which is very interesting. Anyway, you look it up, WebTransport, it's pretty interesting. If you ever play with WebSockets, check out WebTransport.
Eric Meyer: Got it. And I think the last one I want to touch on for the historical note, the historicity of it... Sorry, the last one I want to touch on for historical reasons is the CSS Zoom property, which has been around forever. There was an IE, Internet Explorer hack, I believe it was. Zoom 1 would fix some things. Anyway, it hung around for years and now it's been standardized. So it is different than just scaling things. I don't really want to get into the details of how, but you can scale just an element or you can scale the entire document if you want, using Zoom. So I guess you're not really scaling it. You can Zoom it. So let me start that over. You can Zoom specific elements with just one element, the whole document, whatever. Anyway, it's a focus area.
Brian Kardell: And this actually mostly interoperable at this point, except for there are some bugs associated with it. And in terms of tests, there are a handful that don't pass in Safari. So if you ever were using that and frustrated by that, be prepared to be frustrated no longer. Well, another year, another trip around the sun. It was my birthday this week. Me and Interop both. One more year.
Eric Meyer
Brian Kardell