Eric and Brian discuss the announcement of Interop 2025
0:00
Transcription
Brian Kardell: Okay. Hi, I am Brian Kardell. I'm a developer advocate at Igalia.
Eric Meyer: And I'm Eric Meyer. I'm the same.
Brian Kardell: And today we're going to talk about, I don't know, what did we call it? About Interop 2.25K. I just wanted to do the Madden 2K. Remember 2K? When 2K was coming around, everybody was like 2K, and for a little while, that was really cool?
Eric Meyer: Yeah, Madden was like 2K3 or whatever.
Brian Kardell: Yeah, right. They did that for a long time. Right.
Eric Meyer: So I guess this is Interop 2K25.
Brian Kardell: Yeah, okay. Yeah, so we're announcing the Interop project for 2025. We have gone through the long and arduous process of getting the call for proposals and then discussing them and running them through our engineering teams and discussing them some more, and ranking them and then trying to figure out the economies of how all this fits together. Which things can we choose? What tests specifically go with them? Because that's what it ultimately is about, and yeah, and we're announcing what's in, and I guess not what's out, but what's in.
Eric Meyer: Yeah, and we've talked about that process in a previous Igalia chat, that some things don't get picked because the specification isn't done, and some things don't get picked because the specification is basically done but there are no tests, and some things don't get picked because it's such a huge thing that not everyone can commit the resources. There are a lot of reasons why things don't get picked, so today is all about the things that got picked.
Brian Kardell: Yeah. Do you have any order that you want to-
Eric Meyer: Anchor positioning is one of the big things.
Brian Kardell: I think the best one. Yeah, it's the most exciting one of all of them.
Eric Meyer: Yeah, anchor positioning and layout. There's also a focus on layout, which is really layout Interoperability, to go back to the name of the whole project. It's a carryover from last year, and it's basically where there are inconsistencies in Flexbox or Grid or I guess any layout between browsers, this is still a focus area to fix those, to clear those up. But anchor positioning is new, and ideally by the end of the year, we'll have very widespread, very Interoperable implementations of stuff that lets you do anchored side notes and little pop-ups and all kinds of linking things, one thing to another thing, either visually or... Well, I mean it's all visually because it's CSS, but there have been demos people have done where there are arrows that connect one element to another element, and no matter where you move the second element, dragging it, the arrow just stays pinned and it's all using anchor positioning. You can do that kind of stuff. You can do all kinds of really cool stuff with it. I've done some experiments with it in the past and really looking forward to that being widespread.
Brian Kardell: Definitely. Definitely. Then there's also the view transition API is huge. That's for same doc transitions, so that's like your single page app, you're mutating the page, but that's interesting. I think a lot of people will be excited about that.
Eric Meyer: I hope that that carries through, not just for single page stuff but also that the work that's done towards view transitions in Interop will have secondary effects of improving multi-page view transitions, because you have to do a lot of the same things between single page view transitions and multi-page view transitions.
Brian Kardell: Yeah, I think it's only Firefox isn't supporting the view transition at all yet.
Eric Meyer: You think that's correct?
Brian Kardell: Seems to be.
Eric Meyer: That is correct.
Brian Kardell: Yeah.
Eric Meyer: Well, Firefox and Samsung Internet, I look forward to what people do with view transitions, and honestly, connecting view transitions and anchor positioning, you could do some really cool stuff. Honestly, view transitions is one of those things, I want to see what people are doing with it about six months after it hits effectively baseline, newly established. Because I think for the first six months, it'll be really garish, over the top, crazy view transitions that we've never been able to do before, and then it'll settle down into people actually doing view transitions that are nice and useful and helpful to the user. No shade on the first six months of garishness. It's just, I'm more interested in what we settle into after that initial explosion of experimentation that lots of CSS technologies go through when they first become widely supported.
Brian Kardell: Yep. Import attributes is in there.
Eric Meyer: Import attributes. Wait, is this called something else?
Brian Kardell: No.
Eric Meyer: Oh, is this modules?
Brian Kardell: Yep.
Eric Meyer: Okay. Sorry.
Brian Kardell: It's for modules, so that if you're in JavaScript and you want to import, but this is kind of funny because this goes back to... It seems like such a small thing, but it's been, I think 2017 or 18, something like that when this started, and it seemed like, sure, just you always in Node could say, 'Require this thing,' and it's just JSON, so JSON is JavaScript so you just get it and you have the thing. But it seemed like you should be able to just say, 'Import it as JSON,' just like as JSON. We could just add the words, 'As JSON.'
Eric Meyer: Right.
Brian Kardell: And it turned out that had security concerns and web problems, and then there were bigger issues where people were like, 'Well, but we also would like to maybe import CSS.' So it went back and forth a bunch of times, but we're now in the stage where it's like, okay, we have actually agreed and we have some implementation experience and we're pretty positive with this, so now we just put it in Interrupt 2025, and by the end of 2025, it's going to work everywhere. That's great.
Eric Meyer: That's the plan. There's a number of JavaScript style things in Interop. It's not all CSS or CSS adjacent. The navigation API got picked this year, which I was excited to see.
Brian Kardell: The one that surprised me was Core Web Vitals. So I always think of this as exclusively mainly a Google thing, but there are some specs that have been developed and APIs that are like Largest Contentful Paint and interaction connect paint metrics. These are Largest Contentful Paint and performance event timing APIs.
Eric Meyer: Yeah. Core Web Vitals, it's basically Lighthouse but for everybody, in my perception of it anyway. Google is pushing this, and the idea is for the quality signals that Google Lighthouse has talked about in the past to be used basically to be tracked and communicated by the browser. So within the browser itself, it will tell you Largest Contentful Paint, and there's a specification for determining how you calculate Largest Contentful Paint, so yeah, that'll be interesting. It'll definitely be interesting to see where that goes in terms of how much it exposes to authors and developers and stuff like that.
Brian Kardell: Yeah. It's just an API that lets you measure some timings and then you can collect those on your website and see how you did, and probably, yeah, there will probably be built in things in the tools as well that let you do that. What else is there? There is storage access API. Do you know anything about that?
Eric Meyer: I mean, some.
Brian Kardell: Yeah, I know very little, but it's very confusing because it's another one that has this history that goes back and back and back, so it's like they're were for third party cookies and then Apple got rid of them, but kind of.
Eric Meyer: Right.
Brian Kardell: And then Firefox also started doing some things, and Google was the only one that was left that wasn't doing anything. But then Apple had to make some adjustments, Google had to make some adjustments, so back in I guess 2017 I'm going to say, Apple had this intelligent tracking protection thing and they helped come up with this. I think this has been shipped for a long time now in some form in WebKit. And basically, what it is it's a way to say, 'Hey, look, there are use cases that really need some of the workings that used to be just third party cookies, but we need a way to lock it down.' So it has to do with, you can put an iframe in your page and you can put a new... Well, you can put a sandbox attribute on it, and then through some... It has to be at least some minor interaction. It doesn't currently prompt the user, I think, but it will allow you to maintain a cookie to the same site. So where this matters is let's say you're logged in on YouTube and somebody embeds YouTube in their page and there's a little thumbs up button or something like that. What happens when you click it? Are you you or do you have to log in again? And so there's things like that where they're not getting any real information about you, you're not really getting any information about them. It's not leaking. Your cookies are your cookies, they're in their own cookie jar, but when they load their site in your frame, there's a way with this to say, 'Hey, this thing is okay.' So it's a way to request that you have access to storage in the same site. So basically, YouTube can stay logged in even though it's in an iframe, which would normally be its own... Does that make sense?
Eric Meyer: Yeah, some. What it feels like is it's another attempt to make interacting with web services seamless, even when you leave those services. As long as that can be done in a privacy and security respecting manner, I'm generally for it.
Brian Kardell: I think that's what it's really trying to do, is work out the privacy and security story. So you find this kind of tension back and forth all the time I think where there's like, 'But these things are useful.' And it's like, 'Yeah, but they're not safe,' and so it's this back and forth. Anyway, it should be good.
Eric Meyer: Yeah, and in the JavaScript plan, there are some events things that are happening, like pointer and mouse events is an area that's going to get worked on, and the scroll end event I guess has some interoperability problems, so that's going to hopefully get worked on. But what I found the most interesting was one of the interoperability focus areas is to remove events from browsers.
Brian Kardell: Oh, yeah. The old mutation events.
Eric Meyer: Yep. The old mutation events like DOM subtree modified and DOM node inserted and stuff like that. Those have all been deprecated. The mutation observer API is what you should be using, and so the goal this year is to just take all of those old mutation events, the ones from before, to the mutation observer API, just rip them out of browsers, like they won't be there anymore, which is unusual. I got to say, it's not very common on the web for existing features to be removed. I'm not entirely certain how I feel about it. To be honest, that has the potential to break old pages, and sometimes this sort of thing has to happen. Sometimes you got to take stuff out. CSS removed a whole bunch of visited styling support because of the privacy and security concerns. I don't know that that's what the concerns are here, but just to remove events, to me, the promise of the web is that it works both forwards and backwards in time. I'm always hesitant when there's a thing about, 'We're just going to tear these out. We're not even going to legacy support them anymore.' I don't know, what do you think?
Brian Kardell: I was surprised honestly that they still exist in browsers, because they weren't even uniformly implemented in browsers. And I feel like I remember, I wrote a library back in 2010 or something like that and maybe 2012, somewhere in there, and it monitored the DOM, and everybody wanted to use this new mutation observer thing, and IE didn't have it, so it was very uneven at the time. But even all the way back then, everybody was like, 'This has to go,' so it was deprecated for 12, 13 years at least. And when I look at it on Can I Use Now, it's mostly deprecated. There's lots of stuff that doesn't work, so actually, I'm pretty okay with this. I think it's pretty safe. It'll be interesting to see what happens.
Eric Meyer: Yeah. I am sure it's safe. This would not have been considered at this level without a whole lot of investigation of how often do we see these things being run in our browsers? Certainly, no browser at this point removes stuff just for the hell of it or because it's like, 'Oh, I really hate that.' Yeah, there's a lot of stuff that I think browser maintainers really hate but that they still support.
Brian Kardell: Well, like vendor prefixes.
Eric Meyer: As an example.
Brian Kardell: As an example which is relevant for Interop 2025, because there also is one for text decoration, to remove the need for vendor prefixes when using text decoration CSS property, and to make it interoperable across browsers. So that's cool, right? Because we said also around that same time, maybe 2009, 2010, something like that, we decided this whole vendor prefix thing is a nightmare. We need to stop this. And everybody agreed, but we still use them too much.
Eric Meyer: Yeah.
Brian Kardell: What else do we have in Interop 2025?
Eric Meyer: CSS @scope, which is pretty new.
Brian Kardell: Currently not implemented in Firefox, so we'll get that in Firefox this year.
Eric Meyer: That's the intent.
Brian Kardell: Yeah.
Eric Meyer: Also backdrop filter as a CSS property.
Brian Kardell: Yeah. Somehow, I missed that discussion and I don't know about backdrop filter. Tell me about backdrop filter.
Eric Meyer: Yeah. So backdrop filter is if you have a dialogue or something that's sitting on top of other things, if you want to be able to, let's say, blur out the background, so the stuff that's behind the thing that you're styling, that's what backdrop filter is for. You would be able to essentially say, 'Don't apply any filter effects to this thing that I've placed in the middle of the screen, but within that area, I want you to apply these filters to the stuff that's behind this element.' So you could massively blur out whatever is behind or desaturated or whatever.
Brian Kardell: Isn't the definition of behind to the block? Because we have this concept of top layer that is above all the Z indexes that are in normal page, and then I guess when you have a dialogue, there is a backdrop. Is that what we call it? I can't remember.
Eric Meyer: Yeah. It's the stuff that's behind the thing that you're styling, like visually behind. Or maybe another way to put it is it's the stuff that the thing that you're styling overlaps and is below it or behind it.
Brian Kardell: So it's like the whole page though?
Eric Meyer: Not the whole page. Just the part of the page that the thing that you're styling is in front of or on top of.
Brian Kardell: So can you only see it if there's transparency on your thing?
Eric Meyer: Correct. Yeah. Your background needs to either be transparent or partially so in order to see whatever effect you have applied.
Brian Kardell: Interesting.
Eric Meyer: The MDN page for backdrop filter has some examples, like backdrop filter blur 10 pixels is one of their examples, but you could do all kinds of other stuff. You could use any of the filter properties. I think 90 plus percent of the use of this property is going to be to blur the backdrop, in all honesty. Maybe a few other things like also desaturated at the same time, but that would be my guess. This is just going to be, 'Let's make it frosted glass blurry looking.' I don't know, maybe some SVG filters you could use.
Brian Kardell: Oh, you can use SVG filters too?
Eric Meyer: Yes, you can. So you could do backdrop filter, URL, blah, and point an SVG filter. So that's probably most of the other 10% would be my guess of what this is used for, but we'll see. Designers constantly surprise me with what they come up with. There was also writing modes. We were talking about text decoration before. One of the things that we wanted was support for the sideways LR and sideways RL values, and they're not widely supported, so that's part of it. But there's also overflow, inline and overflow block properties.
Brian Kardell: That makes a lot of sense, right?
Eric Meyer: Yeah, totally does.
Brian Kardell: Yeah. Because we have all the other things that are overflow, which way they're inline and block. Why not add them for overflow?
Eric Meyer: Yeah, I think-
Brian Kardell: I like consistency. I like consistency, so good job, us.
Eric Meyer: Yeah, I think these are also only supported by Gecko at the moment.
Brian Kardell: We'll get there.
Eric Meyer: Yeah, yeah, yeah.
Brian Kardell: It made it in to Interop, so.
Eric Meyer: Yep. Yeah, other stuff. Something about the details element. Did you-
Brian Kardell: Yeah. Yeah. So there's been all kinds of improvements to the details element. So you have the hidden until found, which allows you to do in-page search that will open up the summary details to show texts in there if you set that attribute.
Eric Meyer: Okay.
Brian Kardell: There never was any parts really exposed correctly, uniformly, about how to style the parts of a summary detail. So what if you just wanted to style the content? Because it uses this, they call it Scooby Doo algorithm to like, how do you make sense of this element? I think if a lot of people were designing it, you would have two child elements. So you'd have, I don't know, container element and then a summary and then the details, or maybe it would be two elements that follow one another. But the way that it's designed, the details element is around the summary, and then everything that isn't the summary is the details. So what if you want to style the content of the details? Or if you wanted to style the little turny thing, how do you do it? So they're exposing some pseudo elements, detailed content and marker, and allowing you to display them or to style them better and more uniformly. And also, the possibility to toggle the content using content visibility instead of display. So there's a bunch of interoperability things there. I'm not sure if we are actually interoperable on the accordion treatment of details yet, but if not, I can't remember if those would be in this as well. But I think the point is that details is about to get a lot better things a lot more uniformly, which is great.
Eric Meyer: Yeah. A thing of relevance to Igalia is WebRTC. We do a fair amount of RTC work.
Brian Kardell: I think an important thing in there is there's a thing to make the RTC data channels transferable to workers so that they don't have to run processing of data on the main thread. I think that seems like a really good deal. And RTC, RTP script transform, which this I'm just going to read because I literally don't know. It allows scripts to modify the media stream, which is commonly used to implement end-to-end encryption in WebRTC applications. So I'm sure that people on our team will be happy about whatever they have to do on that. Those things will be available in uniform.
Eric Meyer: I suppose we should have said WebRTC stands for web real-time communication.
Brian Kardell: Also, there are some things with WebAssembly. So resizable buffers integration to integrate WebAssembly into JS code, and JS string built-ins. So this is when... It's going to sound like I don't know Wasm, and the reason is because I don't know Wasm.
Eric Meyer: All right.
Brian Kardell: But from my limited understanding, basically when you compile your thing from C or whatever you're using Wasm, and Wasm is very low level and as such, they didn't define any kind of built-ins like you have in JavaScript. Instead, you import those with some glue code, and the trouble is that that glue code, because these are primitives that you use all the time, the glue code is kind of expensive. It's not overwhelmingly expensive, but it would just get a lot more performant if you could just use them without this glue code built-in. So they're introducing these basically parallels to things that are in JavaScript so that you can use them directly, so you can do things like concatenate strings, and basically most of the things that you do with a string API in JavaScript, you just do them directly in Wasm.
Eric Meyer: Yeah. Okay, cool. Oh, we forgot about the URL pattern API.
Brian Kardell: Is it in there? I don't remember it being in there.
Eric Meyer: It is, yeah.
Brian Kardell: Okay.
Eric Meyer: It's on the list.
Brian Kardell: Do you want to talk about that?
Eric Meyer: No. I think you should.
Brian Kardell: Yeah. The URL pattern, it's useful for matching URL patterns. Lots of people... Not lots of people. I don't think that many people write things that will use URL pattern, but if you use or you write a router for your client side single page application or something, or maybe if this is interoperable across even Node and everything, if you're making a thing like express, a web server, those would be really interesting and useful. Or if like Eric and I, you write a bunch of stuff that goes and scrapes websites and does interesting things, then it could be useful to you.
Eric Meyer: And then there's a catch all, which is web compatibility, which you would think is not the whole point. But this is where small web compatibility problems got dumped into a bucket. So some of it's CSS, some of it's JavaScript, and so it-
Brian Kardell: It's like there are three failing tests in this browser for-
Eric Meyer: Right. Where there was a proposal like that where it was, 'Hey, this is 99% in all browsers except this browser, which is 94%.'
Brian Kardell: Right.
Eric Meyer: Those kinds of things where making it an entire focus area didn't really make sense, so there are a number of those that are lumped in here, which is cool. And then there's the investigation efforts, looking ahead. Some of those things are infrastructural when it comes to web platform tests. An example is that it's really hard to test some mobile support for things. It's very hard to test support for touch events, like correct support for touch events. It's easy for a browser to tell you if it recognizes touch events at a code level, but is it doing it correctly and how are you supposed to test that? So one of the investigation areas is mobile testing. Another one is accessibility testing. How do we not just test for a browser recognizing a piece of code, but actually supporting it correctly and interoperably? And those are two of the investigation areas, which they don't have the same promise of, 'We'll have things fixed by the end of the year.' It's more, 'Let's figure out if we can get things to a point where in a future Interop, we can make that kind of a promise.'
Brian Kardell: And we do these because there's a lot of things that we can't really test super well even, like even accessibility is really hard to test in this scenario. So you have to dedicate some time and effort and money in the end, because somebody has to pay people to do it, toward figuring that stuff out. So if we don't put it somewhere that we're going to do it, if we don't commit to doing it, then it's just never going to get done.
Eric Meyer: Right. Yeah, and a similar area is there are some gaming related APIs, like there's one for game pads, there's a pointer lock API and a screen orientation API. Again, the Interop team felt, 'We need to figure out how those could be reliably tested for interoperability.' More and more gaming is web-based, and these APIs are meant to make it more and more possible to do basically native browser game development and deployment, sort of native JavaScript support for game pads. That way, the developer can just use that API to say, 'Okay, well, when this kind of an action happens, when a primary trigger is pulled, then fire the missiles,' and you don't have to know the specifics of every single game pad. And then the privacy, trying to figure out what kind of tests could be written to test privacy related features. So I think it's going to be an interesting year for Interop, and I don't know how you feel about it, but I think it's a nice mix of new stuff that has just reached the point of we can interop this, we can make this interoperable because the various questions have been answered and the debates have been resolved and there's a specification and there are tests and we can go with this. And also, 'Yeah, that stuff has existed for a while and we're close on being interoperable for the thing, but we're not there yet quite, and this is the year that we want to get there.'
Brian Kardell: I'm really pleased with this effort. I know I've said this a few times, but one of the things that has been lacking, and people imagine somehow that there is this coordination. The coordination is on what we agree in words in a way. It's not in terms of prioritization and commitment and focus, and there's just too much stuff. And so the thing that I like about this is it is an effort to say in a way that, like we used to do with, 'Well, this is HTML 3.2, this is four, this is five.' It's a way to draw a box around something and say we could do other stuff too, but we got to focus on this stuff. Can we all agree to focus on this stuff? And I am pleased, especially last year, because I think it was last year we introduced the Interop score, which is unintuitive, but I think it was a miss the first few years that we didn't have that, a big miss for users. So just to remind people, the Interop score is like, let's say that there's 10 tests and Safari passes five of them, and IE... Safari passes five of them, Google passes five of them, and Firefox passes five of them. They're all passing 50%, but it's possible that you can have literally not a single test that passes in all three. So with a small number like that, it's kind of easy to imagine it, visualize it and realize that, oh, well, what have we accomplished here? Even if we get our score from zero to 50%, the answer is nothing. You have accomplished literally nothing for users.
Eric Meyer: Yeah. You have not accomplished anything interoperability-wise if the 50% that you implement is a 50% that either nobody else implements or that only one of the other two implement. Developers are still stuck with, 'Well, this doesn't work for all my users, so how am I supposed to use it?'
Brian Kardell: Somebody, I want to say it was Jen Simmons, wrote a nice piece that was on the WebKit blog that was talking about this year's, the success of this year's. And I think it talked about some of this and what a real success this year was compared to previous years.
Eric Meyer: 2024, what a success 2024 is. What it has been as compared to the earlier Interops.
Brian Kardell: So I think we're getting better at it, but yeah, it is a really big deal to get this quality, delivering new specs, the APIs that we focused on together, anger positioning, popovers, nesting, scope. All of these things that we're getting, we're also focusing on them together and really trying to deliver something that is really quality. And yeah, I feel like that's been missing for a long time and I'm glad that we're doing it. I wish we could do even more of it, but I think as that [inaudible 00:34:27] we're doing now.
Eric Meyer: What I am heartened by, I think like you, is that it continues. Year over year, it's kept going. Like you say, all of these stakeholders, all these teams coming together and saying, 'Okay, what can we agree on that we will all devote resources to?' Whereas without that conversation, it would-
Brian Kardell: Right. Then you're diverging.
Eric Meyer: Yeah, probably diverging. And also, one of the important aspects of it is that it is a place where these teams come together, coming together to say, 'This is what's important to us,' and the other teams then learn that. They learn, 'Oh, anchor positioning is really important to them. We were kind of interested in it, but now that we know that other teams want to devote resources to this, that causes us to reconsider.' Or for that matter, for teams to say, 'That is not a thing we can do this year.' That happened in Interop. I'm not going to say which teams said for what things, but if I remember correctly, pretty much every browser team for something said, 'That's not something that we have the resources to tackle this year.' And that lets other teams say, 'Oh, if they're not going to tackle it,' in some senses, they could say, 'Okay, well, then we are going to tackle it so that we look better,' or they could say, 'If that's not a priority this year, we could take whatever resources we would've devoted to that and place it elsewhere,' where we can be interoperable, and maybe this thing will be next year, whatever it is. Just that kind of coordination, that communication between teams I think is a real benefit and has the long-term effect of greater interoperability. Just knowing where the other teams are on these sorts of topics I actually think gets us to interoperability sooner in the long term. Because if the flash bulb API, I'm just making a thing up here, if a flash bulb API can't be worked on by one of the teams this year and the other teams say, 'Okay, we're going to put that on the back burner for now,' then maybe next year, everyone says, 'Okay, we put that on the back burner. Users and developers really want it. Can we tackle it this year, please?' And then ideally, you actually get there sooner, rather than the uncoordinated divergence that you were talking about where one team does the flash bulb API and then it takes other teams years before they get there because they weren't really thinking about it.
Brian Kardell: I think if there's one thing that I would change, it's the thing that we talk about all the time, and it's funding. I think Igalia would love to participate in a bigger way. We would like to be able to say in some of those conversations where a team says, 'We just don't have the resources to work on this,' we'd love to have the resources to say, 'Well, but what if you did?' Because maybe we have the resources to do that. So maybe a thing that we can think about in future years if we keep doing this is creating some kind of Interop fund. If somebody out there listening has an idea and wants to start a fund, work for companies that have a treasure chest or whatever hidden somewhere, yeah, that would be great. And also, if your thing didn't get picked I guess, don't forget, you can always fund some work in almost all these cases.
Eric Meyer: Very true.
Brian Kardell: So yeah, I think that's it. Interop 2025.
