Browsers Are Finally Catching Up (Interop 2026)

Web browsers JS you know them are about to get a lot better because interop twenty twenty six just dropped. We're gonna have all of the details about what is in interop twenty twenty six and why you should be excited about it in this episode of Syntax. My name is Scott. I'm a developer from Denver. With me, as always, is Wes Bos. What's up, Wes? Hey.

I love interop.

If you don't know what interop is, it's basically the all of the browser vendors come together and and put up a list of, like, features that have to be added to the browser in 2026, meaning and then they put this big shame chart up that that shows what percentage of of passing tests are there. And and, basically, they say, like like, these are the things that we are gonna be focusing on, and by the end of the year, gosh darn it, we better have all of these things implemented in all of the browsers with no bugs so that we can, like, we can say that we can we can continue and start to use these features. Because that's that's always the thing with these these features. Right? It's just you drag they drag their feet or it works 98% in in Safari, but there's, like, some weird bug. You know? Yeah. This is just so nice and clear.

Yeah. It it's so nice and clear. And for those of you who are not going to be watching this on YouTube, we'll have links and everything in the show notes so you can, click around and see some of this cool stuff. There's a lot of great information. The, fpt.fyi/introp2020six.

Again, we'll have that link in the show notes.

That is a really great place to start to understand kind of the main focus areas. So, what's happened is the the browsers have gotten together. They, the folks that are working on these things and they decided and agreed upon this feature set as the one that they want to get into the 100% territory in the following APIs, which is great because it's a clear road map. It's a clear picture. You can check back at this page, and it's going to show you the progress. And as it stands right now, if you look at this, Chrome Canary has an 87 out of a 100 on interop 2026 already. So, people who wonder why I mainline Chrome Canary now, this is why, really. And Edge Edge is 82, where meanwhile Firefox is 64 and Safari is 64 as well. But the good news is is that by the end of the year, these should be at a 100, which is a great thing when you look at the actual API. So what we're gonna be doing is talking about each individual API and what that means for this API to be an interop so that way you know what kind of cool stuff is coming to the browser over the course of the year, and we'll be discussing a little bit about what makes these things interesting. We wanna start at the top, Wes. We wanna we wanna start right at at up the to me, one of the most exciting one of these focus areas is Yeah.

Container style queries.

So we got container queries, which was, like, one of the coolest APIs allowing us to, you know, work with a media query like syntax to style things based on the size of a container.

However, the idea of container style queries has always kind of been there from the start, just not a part of the initial implementation.

Container style queries allow you to really apply a container query or a, like, a media query style wrapper based on CSS properties.

And, man, this to me even though we have the whole CSS if statements API, whatever, This to me is, like, true if statements because, container style queries can be anything from, like, a CSS variable.

Yeah. Background color. You know? Like, basically, when this thing has a background of pink, then go ahead and apply the following CSS to it and and its children.

Yeah. It's really wild. And I and I I do think, again, like, if we're talking, like, true theming support and stuff like that, that makes this a lot cooler. But it does feel like it is almost like a true if statement in that kind of way Wes, again, it's like, if this condition has been met, if this property has this value, then therefore apply these styles. So what a cool API.

Yeah. One of the ones that definitely felt like, wow, it'd be really great if this were to exist when we first heard about it. And to see that it's now landing in interop 2026 is extremely exciting.

This this is just one of many really cool CSS properties

in this. Let's talk about, like like like, Wes would that actually be useful, though? Right? Like, it it is cool that you can target something when it has a a a specific background color or or when it is in a certain display.

Like, the big one for me is and this is in the example as Wes, is just custom themes.

Saying, like, when this container has a theme of and and, like, right now in, in color schemes, we have dark and light. And if you wanna do any more than that, then it gets it gets tricky. It gets hard. Right? Like, Twitter, like, last week, they literally removed Dimpod.

Dude. And I was I was talking with one of the devs on on Twitter about it, and, like like, I'm like, what's, like, what's the possible they said they they moved it because they don't have the overhead to to support it, which seems kinda silly. Like, it's silly. It's a third a third I don't expect that answer. I don't expect that answer. That different than dark mode. So I was, like, trying to, like, poke at like like, what's the actual reason? And and, like, I I could have said, like like, I understand some of the reasons. One of the reasons is that light and dark is very easy. You add a third, then you start getting really, really hairy. Another issue is, server side rendering. Right? Like, if you default it to light mode and then you you load it and then it's it's a it's a different theme, then you'll have, like, a little bit of flicker. Right? And and or, like, caching. We had we had this issue on the Syntax website where Sure. If somebody had a different theme set on one of the pages and they visited that page, it would be cached server side rendered on their theme. So we just had random pages on the the website that were that were being rendered as a different theme. So, like, this type of stuff where it's just like a first class citizen in the very first render, you're not doing some weird JavaScript thing where you update it later. It's fantastic. So I think that's probably a huge use case as well.

Yeah. Totally. I I think there's a lot of cool stuff about this. But, again, I'm back to the Twitter thing. I don't I don't buy that. If you have a a zero zero zero background working and a white background, that is if you have both of those working, then the difference between a zero zero zero background and, like, a two two two or whatever the heck their their gray mode was is nothing. It's one color. I I don't I don't buy any any other description. Yeah.

I don't buy any other description because they don't have to worry about contrast, the the the OLED,

Yarn background. The text is all white on the dang sight anyways. So, like, how much more contrast do you need? I don't I don't understand it. And it's not like like, you have a design system. Like, it's not like you're building a new feature and being like, make sure we set the text correctly on this feature. Like, shouldn't that just inherit?

Yeah.

I don't I don't understand that at all. That was was shocking to me that they would say that that and, also, on the same day, Elon Musk posted that by the end of the year, AI will be writing binaries.

So we had the same day where we had somebody say, a third color scheme is too much overhead to support, and AI will be writing binaries by end of year.

Oh my god. What a yeah. Yeah. I can't even, I can't even with that. Either way, so back to this. So if you if you are on this oh, we'll have a link to this GitHub. There's an interop GitHub too. I'll have a link in the show notes for you. The coolest thing about this GitHub is that they not only link to the proposal for the issue, the docs, if there are MDN docs available, the spec, but they also link to things like the test, the web platform test. So if you're the type of person who wants to really nerd out and see why Chrome has such a better score on this than Firefox or Safari, they have each individual test in here where you can see if there's a bug with the the test, or if there's a bug in the implementation or what it's missing.

So you could even follow feature by feature. It's really, really like, I I nerded out on these tests so hard this morning trying to see what was what and what was missing here and there.

Because some of these, as we'll get into, are nuanced because you'll be like, oh, wait. This API already exists. Right? But there are, like, nuance here, and you can find that nuance inside of the test links inside of all of these. If that's the type of thing you're gonna nerd out on like me Yeah. It's available for you. And and, typically, this is how like, when you find a bug in the platform like, I've done this many times. I've created a an issue in, like, with Chrome or with Firefox and being like, this is broken when you do x, y, and z. And what they will do is they will then go and make a new web web platform test and publish that, and then the all of the browsers will run that, and they'll see, oh, we found an edge case, and now this is broken in x, y, and z.

Yes. Yeah. So really cool stuff. And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.io/syntax.

You don't want a production application out there that, well, you have no visibility into in case something is blowing up, and you might not even know it. So head on over to century.io/syntax.

Again, we've been using this tool for a long time, and it totally rules. Alright.

Anchor positioning. We're pretty much almost there. We've talked a whole bunch about anchor positioning. I absolutely love anchor positioning. This is an API that allows you to position two elements relative to each other even if they are not nested inside of each other. So this Wes this is really helpful for, like, a tool tips or or little pop ups that need to be shown or, like, price tags that you wanna put something on.

And there is a whole bunch to anchor business engineering. Right? You can you can have different named areas where you can you can stick things in the top left or bottom right, but then you can also use a calc size, which is a CSS function to, center it. You can animate a whole bunch of them.

It's an absolutely massive spec. It just landed in Firefox. I've got some demos that I need to make a video on because I've been been pretty excited about this. It it the stuff that is not, it's we're at, like, 99% in almost all the browsers.

Yep. And the stuff that is not supported is some of the animation stuff, and then there's just some some oddities. But this is one that you can you can start using today.

Yeah. Which is great. I love anchor positioning as well. It's one of the coolest new APIs.

Getting AI to write anchor positioning, though, still, I gotta pass, like, the whole API. It'd be like, hey. It's like it's like, well, maybe I'll just position absolute and say, no. Yeah. I told you. This is the way.

Listen to me. Or it installs, like, a like, a floating UI. There's there's, like, libraries out there that are, like, floating UI. And another thing anchor positioning does is if you have, like, you can tell it multiple spots where you want it to go. So if you, like, go to the right of this element. But if for some reason that element is on the very right of the page and there's not enough space for that element to to pop over top of it, then it you can you can fall back. You could say flip in line or flip block, like, flip vertically, or you can just give it, like, a like, three or four different possible areas where you'd like it to go, and then it will then, update itself.

Yeah. Let's get on to the next Node. CSS a t t r. What does this do, Scott? Oh, yeah. CSS attributes. So CSS,

the attribute function inside of CSS is something that has existed for a long time inside Yeah. Of CSS.

But the improvements here for CSS attributes is getting to use the values from a CSS attribute inside of your CSS. So, if we go to browser compatibility, you can see why this isn't, like, widely a 100% already considering the attribute function first dropped in Chrome in version two of of Chrome.

But more recently, it's it's along with the ability to use the the new, like, what type of something is. Like, we had the at property syntax in CSS that was basically, like, TypeScript types for CSS Wes you can find this as a number? Is it a rotation? Is it a

background, an angle, etcetera?

And that gives us the ability to use the attribute function in a much better way inside of CSS. The way that I like to think about the attribute function is it's almost like props in CSS. You remember in styled components, you could put a prop into a styled component and get access to those values in your CSS.

Well, that's pretty much what the attribute allows us to do with this API. It allows us to actually access the values of an attribute directly in your CSS as the value. It's Mhmm. Really, really sick. Like, imagine you could put a data rotation value as an attribute on a div and then use that actual number value as the rotation degree in your CSS.

So that's what this JS, and it is really cool.

Yeah. It's it's making declarative UIs a lot easier. And and, previously, I've had to do, like, inline CSS Wes you, like, pass a variable, and and that has a whole bunch of issues just with simply being ESLint CSS is much more specific. Don't make me say the word, but that and, like, the other thing about this is that like, imagine you combine this with the the first one we talked about, which is container style queries. So you could have you could have, like, a attribute of, like, data dash size is equal to large. And then you can say, like, when the variable size is set to large, then apply the following styles to this this container.

This is so great for, like, components, and making reusable things over and over again, which have many different permutations, can live in different areas.

And then when the people are authoring them, you don't necessarily need to dip into, dip into the CSS.

Yeah. It really feels like this is a step of getting HTML and CSS to be more, like, less out of your front end framework and more into the browser.

Like, I I've been thinking about this as if they are props in that kind of way, and I I think it's really super neat. This is one of the ones it's 99% available in Chrome Canary today, by the way, folks, if you're listening to this, and as well as Edge. It is only 11% in both, Firefox and Safari. That's because they have the old version of this where you couldn't actually use the values. So, hopefully, we'll be getting those very soon in the other two browsers because this is one that I'm super, super excited to use, and, we'll be getting deep on this one for sure.

Next one here we have is a contrast color, the long awaited contrast color function.

I do feel like the actual what we got with contrast color is maybe less useful than I was hoping it would be. But contrast color basically takes a color value and will return a contrasting color. There is not that much control in this API that I was hoping it would be, where, again, it's basically going to be returning

a black or a white value, essentially. So let me find out exactly here. It's only black or white? I thought it would it would calculate what the color should be based on That's what I'm telling you. Yeah. What it's falling on? The the actual implementation

returns a value of white or black based on which value has the greatest contrast with the input. So it feels like this API was nerfed. It's so hard, though, because, like, if you did give me the, like, the

calculated perfect contrast, then, like, you you would be getting, like, green on red. Sure. And, like, you would be having awful looking combinations.

I wish this would be, like, a light Yarn situation where you could specify what that is so it's not just like that white bread. Feed that? Like, stick it in a variable and then feed that into the the from? Like, you you basically say, alright. Here it is.

Yeah. Or

use a again, the the the thing about first today, use a style query. So when it is black, when it is dark, then use red. And then when it is white, then then use x, y, and z. So it's probably doable.

Yeah. But the Yeah. Color.

Did do you know that there's there's color drama, Scott? It's like never not. Color drama.

No. I had a post the other day about, like I forget what it was. But but, Kilian Volkoff, he's the, dev behind Polypane, which is a fantastic browser. You should check it out. And he was he just, like, filled me in on like, you know how you if you put, like, white text on a red background, it's technically inaccessible.

Right? Like, YouTube red, white text on top. It's that that is inaccessible. And and you just, like, you look at it, and you're like, well, I'm I'm not disabled, but that looks very readable to me. And there are so many color combinations out there that are are simply like, okay. That that is fine, but it's the algorithm says that it is is incorrect. Right? And then it turns out that those colors that are in your dev tools are w c a g two, but then there's a they're working on a new one called w c a g three, but then there's, like, a competing standard called APAC.

And I'm not gonna go into it, but, like, there's drama in the color space of, like, which one should be Deno. And what the browser ends up figuring out JS this accessible or not JS is going to be up to the browser, which may or may not also be like like, people you can get sued if your if your website is not accessible right now. So right now, if you have a button background color red, text white, that is inaccessible, and you can get sued for that, which is is nuts. But under the new this APCA, it there is much more reasonable, and it it it stands to whether this will actually be the standard, but hopefully, it is because it seems much more reasonable.

Yeah. Word. Cool. Alright. Next one here that we have is a feature that's been around in all of the browsers for a billion years, which is CSS Zoom.

CSS Zoom, we talked about on the show before. It's kind of like the scale property in many ways. But, Wes, do you wanna explain, like, what makes it different?

Yeah. It if you zoom an item, it scales its size up, but but will then bump down. It still takes up its room in the DOM. Right? So, like, if you I don't know, Scott. If you just inspect element on any element in there and then put a zoom two on that, what it will do is it will grow to be twice the size, and then it will bump down the elements below it, which is fantastic. So we we had something in, the Synhax platform where I needed to to scale up and down iframes. Right? Because, like, I want the iframe to be rendered 600 pixels wide, but I I I literally warp it to scale and I wrote this very complex thing with container queries and transform, and scale so I could, like I got it working. I was pretty proud of it, but then I was looking at it being like, oh, that would probably been a lot easier with just Zoom.

Yeah. Right. Yeah. Yeah.

So that's that's awesome, especially for, like like, almost everything on the web is is vector based. Right? So you could just Yes. Scale things up and down accordingly.

Yeah. In my understanding with this, why it's an inter Interop twenty twenty six JS that this is an API that's kinda existed and was written and kind of implemented differently and, kind of not neglected that it even existed at all. So my understanding is that this is just kinda shoring things up, making sure all the browsers handle it the exact same way, making sure that there's no bugs. So, this should work in any browser today already. It's just making it. It's tightening it up and saying, you know what? I looked into, like like, what's actually making it fail, and it it turns out it's, like, nested iframes. So if you have an iframe and you zoom it down, but there's, like, an iframe inside of that, which is

somewhat of a legit legitimate use case.

You know, like, a you could have, like, a YouTube video, and that YouTube video could have another iframe inside of it, then then you're in trouble, but whatever.

Next one is CSS custom highlight API. I've Cool. I've looked into this several times, and this is great. So if you've ever done wrapping, meaning that you want to highlight something, you know that you'll have to like, you literally need an element to to color something. You know? Put a background color, change the color, whatever.

And then the custom highlight API will allow you to create ranges on your DOM nodes.

And then in CSS, you can name them. And then in CSS, you can simply just write a selector that is like a custom highlight. Scott will show it, and then, you can you can change the background. And what you can apply to it is somewhat limited.

You can only use I think it's, like, background color, probably opacity. You Node? Like, there's only a couple things you can apply to it, but it certainly is really handy for just highlighting text.

I'm I'm trying to remember when I used this. I think I used it to blur out to, like, redact some information.

Yeah. That's cool. That's a cool usage. I I don't know. Like an AI thing that would figure out would it would tell me I had, like, a paragraph, and I said, where in the paragraph JS, like, a phone number or any sensitive information? And it gave me the start and stop values from all of them. And then I turned those into, like, DOM ranges, and then I I simply just blacked them out.

Yeah. There's some of their examples are showing, like, highlighted search results or, spelling errors and stuff like that. It's, like, just giving you that level of control over the display of text when it needs to be highlighted. So I think this is a really cool API. It's not one that I see myself using all the time, but I Node that, like, when I'm gonna need it, I'm gonna be thankful that it exists. Because, like, your alternative right now is JavaScript for this that is, like,

hacky to some degree, not hack. But You look at something like Versus Code. Versus Code does a lot of text decoration. You know? Underlines, squiggles, overlines, there's all kinds of little decorations on Versus Code. And if you inspect element on Versus Code, they have an entire separate layer that they just render these elements on top of and then place them exactly where they need to go. And that would probably be easier with with anchor API now, but, like, there's not always an element wrapped around, like, a line of code.

So this API would certainly make that a lot easier. Totally.

Dialogues and popovers is also included in here, not because dialogues and popovers don't exist. In fact, they're, very well supported, but there is a number of little outstanding things here and there. Actually, Safari only has a 26% on dialogues and popovers.

I I didn't realize that. But, yeah, there's there's new features in here, like a dialogue closed by attribute.

It allows you to to, like, close have a a dialogue that's closed when you click outside of it and having to, like instead of having to write that with JavaScript, there's an open CSS pseudo class that allows you to style whether, based on if the dialogue is open or not. Popover hint is another attribute here that is used for, like, tool tips for pop like, you can make tool tips really easily in popover. It's actually really nice. I've used this, myself.

So a lot of little things here and there.

The this close by is actually really handy. On the Synhax platform, when we finish a battle, we use a popover or a dialogue to say, time's up, and, like, you just have to wait there. But if you hit escape, it closes it because the escape key is is by default. So we we need to put this in because the close by attribute will allow you to disable hitting the escape key.

Yeah. Because there's a difference where it's like a takeover or, like, some things that you you have to prevent the user from advance. I actually just hit this exact same issue, ESLint my, video, my v framer app. I have, like, an onboarding Node, and I hit escape. And it's like my onboarding model went away, and I'm like, I can't get that back now. Like, the user Yeah. Could hit escape and then never see their onboarding again. So definitely, a lot of nice stuff needed here. Next JS, JavaScript API, which is fetch, uploads, and ranges. So there's a couple of things. The the readable stream inside of the body to stream data to the server, supporting form data data and MIME types for requests and responses, and supporting the range header. Now I don't really know too much about these ones, Wes, or,

specifically, I don't I don't I don't know where they're gonna come in handy for me. They seem nice. Wes. It's kinda interesting. It's more of a lower level thing that maybe you haven't run into previously. But, essentially, when you are sending off a fetch request, the body of that fetch request, in in all browsers cannot be what's called a a readable stream. Meaning, like, it's something that is is still being worked on. And and as we are getting more into to AI, as we're getting more into like, if you are compressing video as you go and you wanna, like, send that off as a fetch request, you wanna send data somewhere, likely to a server, at once. You you need, like, a readable stream for that, and and that's not something that is is totally doable. And simply, one could be like, I wanna upload this large file to a server, and I wanna get, like, progress reports of, like, how how much is is currently being uploaded.

And that is just not doable with a fetch. And I quite honestly, I've never run into that. It's because, like, usually, when you're doing this, you're using some sort of library, and then the library will will handle that under the hood. Because you can do it with, like, XML HTTP requests. You can do it with, like, Axios, things like that. But this would be a nice feature being added, especially, like, everything's starting to be streaming right now. All of those React server components. Looks like the opener of this issue is the maintainer of SvelteKit, so certainly lots of things there. What's the new SvelteKit stuff that's, like, streamable?

The async components, that's it? Yeah. Yeah. Yeah. Components. Yeah. Yeah. There you go. Cool. Yeah. I'm sure there's some people that are more excited about this than me. That's for sure. I I don't I just, I don't hit I don't hit these issues, or at least I don't directly hit these issues. But, this is an interesting one nonetheless.

Next is going to be indexed DB, API changes, and this is one that really just brings Firefox and Safari up to the level of where Chrome's at. There's a number of APIs like get all records, which returns the records and their primary keys from an IndexedDB store or index. So, the the get all records method speeds up operations on large datasets.

It seems like that is the main focus for this inside of IndexedDB.

But as somebody who does use IndexedDB for my local data stuff, gotta love, that. And I'm I'm sure library authors who work with this stuff will be liking this as well. Next one is JSPI for WASM, which, really, my understanding of this one is that it just, makes WASM more reliable in an asynchronous setup.

It says that it allows for WASM applications that were written assuming synchronous access to functionality to operate smoothly in an environment where the functionality is actually asynchronous.

And that is, already at a 100% in Chrome and Edge, but at 7% inside of Firefox and Safari. So, again, another one of these APIs that's just like a nice thing that exists inside of Chrome that we're getting in the other browsers.

Next one, media pseudo classes. This is amazing. The playing, paused, seeking, buffering, stalled, muted, and volume locked CSS pseudo matches on an audio and video element based on their Scott.

Absolutely.

Please. Please give me this. I basically, if you want to hide a button while you're playing or paused, you wanna toggle them.

If you want to, like, show a buffering, little icon when when it is buffering, when when it's stalled, do you wanna, like, show a little spinner? All of that right now has to simply you you set up some JavaScript. You listen for the events on your your media element, and then you, like, apply a class and then or, like, show and hide things. This is gonna be a game changer for building custom, video and audio elements.

Yeah. I love this stuff.

Very excited to have all of this.

Next one is the navigation API. Now the navigation API, I believe, is already pretty decently supported. We're at a 98% in Chrome, 89%, and 92% in Safari. But if, this is one of the ones where framework authors are going to really have a good time, but us normal folks probably won't be using this, directly.

But it do you are you familiar, Wes, with the the navigation API? Yeah. I I know, like like, React Router.

Anybody who's working on a router for a framework is is already using these types of things because, essentially, it allows you to intercept navigation things. So, like, you know, like, one thing right now is some frameworks let you use, like, an anchor link, like SvelteKit. Right? And and what they'll do is they'll simply just, like, listen for link clicks, and then they'll prevent default on that. And they'll sort of, like, intercept it, and then they'll they'll do all their little special sauce to preload that data in and and then switch out the page. Right? This is sort of like a native API for intercepting navigation APIs, and and then you can sort of, like, step in. So, like, I don't hopefully, I always hate these frameworks that make you use, like, a link component. Oh, I hate it.

Yeah.

So that's one of my favorite things about Svelte JS, like, yeah. A link is a is a a tag? Hell, yeah. I'm into that.

Dude.

Yeah. That's, like, actually, it's one of the low key, you Node, you can't go an episode without mentioning Svelte things, but it's one of the low key things I love about Svelte JS just that link. Like, when I think that, React devs are still using a link component or something, I like that blows my mind, honestly.

Yes. But navigation API changes more than just that. I I think it could be really cool and stoked that, I'm sure framework authors are are stoked to have this with better support here.

Next one is Scott custom element registries. This is a web components thing for basically allowing you to construct a custom element registry that's separate from the global one, which is living on Windows. So, therefore, by creating more than one registry, you can have multiple custom elements with the same tag Node, to coexist. It's basically just like scoping for creating named, custom elements.

So super cool for that one. The the big one for

what? Hopefully, that will save some of the stupid names for all these web components. You know? Hate that. Yes. Yeah. Oh, yeah.

That's one of the my least favorite things about web components is the names, the prefixes, and stuff. I don't know why. I would just rather the names be nicer. That's, like, so it's such a minor complaint. It is. Yeah.

Next one here is, man, one of the coolest APIs in the world, scroll driven animations.

You can tell where my interest lie because all of the things that I'm deeming to be are the coolest or, like, the visual CSS things. And, like, it's like the JavaScript APIs. I'm like, oh, okay. Whatever. But, like, if it's scroll animations, I'm, like, going nuts over it. So scroll animations allow you to do all kinds of stuff. It already has good support in in, Chrome with 95% support. Firefox is still majorly lagging. Safari has good support for them. But it's really just, like, when this gets a little bit more closer, we'll do an extreme deep dive. There is so many outrageous things you can do with scroll animations beyond just making fancy things fly onto the screen when you scroll down. Yeah.

Scott snap is is also one on there. Scroll snap is is pretty well may Very well supported. Yeah. Where where are we at right now with that one? So the the thing with with scroll snap here

is there are a number of if you come into the test suite, this was the one I found very interesting, a number of small bugs and different behaviors across browsers that that make it so it's not, like, super consistent across all browsers.

So you can see a handful of bugs and some red here. But, basically, if you read through the the test here, but also you read through the proposal, it it's it's just a number of little small things with the API where they're saying, you know, things can be jumpy or the the the snap behavior, how it looks and feels across different browsers is not consistent, doesn't have full control. And what this is doing is it's just shoring up that, API to make sure that Scott snap is, as useful as we all want it to be. It's so cool. Yeah. I love scroll snap. There's a couple more things to to scroll snap,

which is often kind of a bummer when you go to build, like, if you're going to build a slider or if you if you're simply making like, Scott was working on something where you could do that, like, kind of, like, swipe to delete Yep. Experience.

In order to, like, get those full experiences, you need scroll snap events, which is basically when something has has changed or snapped. Like, something as simple as, like, highlighting the current little dot.

I know that there is a CSS API for, like, being able to show, like, you've you've got five slides and you're sliding through them. You wanna show that you're on slide three of five. Right? And make that one yellow instead of black.

Right now, the way to do that is is you have to listen for, like, the the snap event, or scroll snap. I forget what the actual event name is. Yeah. Scroll snap changing is is when it starts, and scroll snap change is is when it's when when you have snapped to something. And that that's not in Safari. Being able to style things with a container query when something is snapped versus not, that's not in Safari. And then scroll state queries, that's kinda cool. Right? Like, people have always wanted the, like, stuck. You Node? Like, CSS sticky is something currently stuck.

That's another one that that's just not in Safari. So I'm hoping that those are part of this interop.

Yeah. And if you wanna see if you go through the tests, it will show you what exactly is in the interop here. So, capturing snap position, scroll target, align, snap after initial layout, snap after reload. Oh, that sounds nice. Unrelated gesture during snap? Yeah. So some of these are are really just containers.

Bugs in making this a little bit more reliable. Usually, when everything is nested very, very deep,

snap after re layout. Oh, that's a interesting one. Right? You have scroll snap on, like, a container, but then you resize that element.

What happens? Right? Mhmm.

So Yeah. It doesn't look like there is anything related to the events

here, though. Yeah. That might be a separate separate work. Separate Yarn? Next up is CSS shape, which we've talked about shape before on the show, can be used with things like clip path, but it's basically just a really nice API for declaring how to to create shapes. I actually, I don't know if you would say famously. I used this in one of our CSS battles without knowing the syntax very well, and it it doomed me for that.

But it it's to me, this is a much nicer syntax than trying to write the SVG syntax inside of the shapes.

So the the the syntax, if you don't know, is is basically you're saying, like, if I wanna make a shape, you have a shape function. You can say, from 10 pix 10 pix, each line by 50 pix, v line to five rems. Like, the syntax is so readable comparatively. It's it's a great API. It it's really cool. I wrote a library,

for, like, following paths on one of my sites Mhmm. About a year ago, and it was all with, like I had to, like, learn the entire, SVG spec. Like, if you ever look at an SVG and there's all these numbers and, like, m and p and a and, in there, like, that's that's basically just describing, like, where it's gonna go. Where arc two, move two, line two Mhmm. That sucks having to write all that stuff yourself. So this this is very welcome.

Yeah. Totally. Word.

Yeah. Shape and shape's one of those ones that has decent support at the end of last year. I don't even see it in this chart here. The CSS shape, 95% in Safari, 83% in Chrome. So just one of those ones that is completing the loop there and getting that one wrapped up. Next one is a handful of view transitions, API things. We love view transitions for animating things when you change pages.

Right now, this year's work will continue to focus on interoperability of the same document view transition. So SPAs, getting those animations, making sure that they all the browsers are functioning the exact same way, locking render attribute for link script and style elements, which blocks rendering until the external script of the style sheet has been loaded. And then there's link rel expect attribute, which is a hint to the browser to block rendering until the element that the href value references is connected to the document is fully parsed. So, again, these all seem like just nice little quality of life updates and then a new CSS pseudo class, which matches only when the active view transition was started with the specified type. That one that that's one of those little functions or or pseudo, classes that I'm sure will come up at some point, but that seems kind of interesting.

And then there's going to be work on cross document view transitions, which is multi page applications, view transitions, which is something that, I think is is really great. Because right now, like, if you want page transitions in the browser, you want your app to feel like a native app, you're pretty much guaranteed to be reaching for a a Scott type of style navigation, and this does work to improve that.

I was just looking. I was like, oh, the probably thing that's not supported is view transition groups. So if you have, like, multiple elements that you want to just apply the same value to, the same transition to, like, this is this would be helpful if you're adding and removing cards from from, like, a list of things. You know, you wanna you wanna transition them in and out. But it's that was interop twenty twenty or baseline twenty twenty five, and it looks like it's fully supporting all the browsers, which is fantastic.

Dude, view transitions, still supremely underrated API.

And this is one that is it it seems like most of the work to be done here is in Firefox and and a handful of other, things that are small time. But, like Yeah. Man, view transitions API, I recently Wes, I recently added a new view transition to my website because, I was tired of people saying my website was bad. So,

hold on. Wait. What is it? What's your domain that you're using now?

Tolinski.

Tolin.ski.

Yeah. You can see I got a nice little

What do what do I do? Oh, so you're on it right now. You just click any of the links. Yeah.

Which? Whoop.

Oh, yeah, baby.

Nice little grab and fall.

Just Yeah. And it's not too long. It's not too long. Away. Peels away. That?

I did, I I did some work overall on my website just to make it look feel a bit nicer after getting clowned on. It's not, like, perfect or anything, but I know. I was just tired of that.

And, the work.

The comments work. Bowling works. Yeah. It works.

So I needed to do that for for my own sanity here. Cool. Next one here is something that I also don't necessarily understand. Web compact web compatibility refers to whether a website is works as intended in a particular browser version.

This year's focus on web compatibility issues Yarn ESM module loading, the timing, scroll events relative to animation events, and unprefixing the Wes kit user select property. This feels just kind of like a

just a a dumping bucket of a few things. This seems like a grab bag of That's what you're gonna grab. Why these things are the unprefixing of WebKit user select property.

Yeah. Yeah. Okay. Maybe this is the grab bag of, like, alright. Safari. Hold on. Let's let's take a look at where Safari at. Chrome, 88.

Firefox, 88. Edge, 88.

Fire or sorry. Safari, 55. Yeah. This this is just like a shame bucket for Safari to fix their shit.

Yeah. Yeah. I know. No kidding. Yeah. It's super funny.

Next one here is WebRTC improvements. So they're going to continue to improve the interop of WebRTC, fixing the remaining failing tests.

So it just seems like, again, there is a handful of failing WebRTC tests.

This is for, WebRTC,

video over the web, like a real time video over the web. It's it's for anything. WebRTC is like a I always think about it. Communications channel. It's it's most likely going to be video or audio. That's how that's how a lot of these applications work. Right? But it could be could be torrent data. It could be literally anything, any sort of communication between directly between two browsers.

Yeah. And I've I've talked to many people over I'm sure the the folks at Riverside have many qualms about it. Like, not everybody is building a, like, a Zoom in the browser, but the Yeah. The people that do, I'm sure they are just mad at some of these browsers for, like, these weird edge cases.

Yeah. I'm sure they're seeing some of the the red on these tests and being like, would be really great if it was green. There's a handful of red and yellow here that, well, I would imagine anybody who's working with WebRTC in a professional manner is gonna be stoked about.

The last one here is WebTransport.

Wes, do you know anything about WebTransport? I think this one's actually pretty dang interesting if you if you haven't taken a look at this. Yeah. I've I've dipped into it, but give us an explainer.

Yeah. My and and you correct me if I'm wrong.

My understanding is that Wes transport is a you could think of it as an alternative to WebSockets, using HTTP three instead of, TCP, which is what WebSockets use. Now my research this morning led me to believe that the benefits of this are that it web transport allows you to it uses IDs instead of IP addresses, which becomes important because if you go from one network to another Wes network, the WebSocket would fail because it's based on the IP. Where if you were going from your Wi Fi to your five g using this, it would stay connected the entire time without having, like, a any a refresh required. Multiple streams on one connection as Wes,

stream priorities. So it's a it's a two way data transport. So if you're if you're sending data back and forth, which which could be like a like a video communication thing or, like, probably also just like streaming video, you wanna have multiple that I I keep wanting to say sockets. Right? Like, what do you what do you call that? Connections open at once.

Sweet. I'm I'm into this. Says a high What I was doing where somebody suggested that I look into it? Real time games, live streaming, collaborative apps,

mobile users switching networks frequently, high latency, lossy connections.

Yeah.

Safari currently sitting at 0%.

So let's get it together, and, let's get all these things on board because that sounds like something I like. I've been using WebSockets a lot for my I mean, we use it all over SynHax. So I would love some of these things to be fixed, not necessarily, who knows if there are actual issues that I face right now. Now there's also in addition to these new APIs being on the interop JS, like, these are what they're going to work on. There's also investigation efforts, which are things that have been, listed as these are things that we're going to be taking a serious look investigating and planning on, for interop 2026.

Now there's a whole thing about accessibility ESLint. So, basically, how browsers are able to generate consistent accessibility trees from the same DOM and CSS across browsers, making accessibility testing, I would imagine, inside of browser tools to be much more reliable, predictable, unified across browsers. The one that I am most excited about in these investigations is JPEG XL, which is an awesome JPEG format that sports animation in alpha, lossy as well as lossless compression.

JPEG XL has been one of those things that has been, kind of up in the air for a long time.

If you go through any of the proposals here on GitHub, there's a lot of great discussion about this.

And you see, basically, the dev teams for the different browsers all saying, yes. We are committed to working with JPEG XL, and, there's different there's a a Rust library. I went I went I read all all this stuff today. It it's very fascinating. But I think the long story short here is that even though JPEG XL isn't on the interop as a feature that will be coming into the browser, It seems like all of the browsers are getting on board saying, you know what? We're gonna figure this out, and Pnpm XL is most likely coming. That is, like, my read on the situation.

And people are probably listening right now and being like, like, why do we need another image format? You know? Like, we had we have WebP now, which seems to kinda support Scott of the stuff. Right? You can Yeah. WebP is dope for people who currency.

Who don't like it. It's dope.

Like, what's the

I'm just trying to look up. Like, what's the benefit of of JPEG XL? It looks like there's a lot there, Rev. We could do a whole episode on it. Yeah.

Alright. Send us leave in the comments below why we should be using JPEG XL. That's a dope ass name, though. Man, I I almost we should almost do some merch with JPEG XL on it, though. That's Syntax XL. Yeah. Wes. Come on. Yes.

WebP.

JPEG XL? What an absolute chat of a filename.

Somebody yeah. That's,

yeah, that's a that's a great point, Wes. I hope that I can drag them into apps without the apps crashing. Because it's freaking web p if I drag a Wes into ScreenFlow, the whole app crashes. What about, like, HEIC? Like, come on. Like Yeah. That that's those two formats.

Too many too many formats.

Yeah. Yep. Let's get just a good old JPEG going to make it better. Alright. Mobile testing. Just in addition to the accessibility testing stuff, there basically is going to be an effort in to standardizing how browsers, test mobile specific features like dynamic viewport stuff, which, like, right now, like, how you're doing that by testing it on your phone. You know?

So the little thing. Yeah.

I always find that the the little media query device view or whatever is just like, okay. I hate that thing. It it looks like a phone, but it doesn't actually represent your phone. And there's so many missing things. So, hopefully, that fixes some of that. There's also WebVTT, which is basically, like, the way that I'm understanding is is it's, four things like subtitles, but not limited to subtitles. Again, these are just things that they're investigating. So not anything that I dove into crazy, but that is the various investigations and all of the features in Interop 2026.

It's gonna be an awesome year.

We should do a follow-up on this later on to explain some of these things in more depth that we, haven't done so, especially like JPEG XL. If there's any of these features you wanna see us do deep dives on with examples and really cool stuff like me personally, I feel like I'm gonna be getting TypeScript animations heavy this year and, like, doing some experimental work there. So, anything you warp particularly excited about, Wes?

I I've been using WebVTT on my course platform for a long time, and it's it's awesome because you can, like, totally style a lot of it. You know? Although I've I've been like this is totally totally random, but I've been thinking about just putting the captions below the video player because, like, the captions always get in the way, especially with something important on the screen. Yeah. Especially with code. Right? And, like, you're watching a show, and sometimes they'll they'll move it above, you know, but there's it's it's not perfect.

I kinda wanna put it below the player. But that's the I out of all of this stuff, besides JPEG XL, what am I most excited for? I think probably either container style queries or the anchor positioning just being absolutely everywhere. Those are two big game changers that are gonna change how we write CSS, And those are things that I'll be using in in probably every app that I'm writing.

Yeah.

Yeah. Word.

Awesome. Well, that's it for Interop 2026.

Let us know what you think. Leave a comment below. We'd love to hear from you. Thanks for watching, and we will see you in the next one.