Eric Meyer: Hello there. I'm Eric Meyer. I'm a developer advocate at Igalia.
Brian Kardell: I am Brian Kardell. I'm also a developer advocate at Igalia.
Eric Meyer: We thought we'd take this end of year podcast to talk about the year that's ending and things that happened in it. This was inspired a little bit by posts like the CSS Wrapped: 2023 posts that was put up on the Chrome Developer blog. We thought we'd get one of the authors here to talk about that and other things that happened on the web platform. Welcome, Bramus.
Bramus Van Damme: Hey. How are you all?
Eric Meyer: Please let people know who you are and what you do.
Bramus Van Damme: My name is Bramus. I'm a Chrome developer relations engineer at Google, and I'm mainly concerned with CSS and Web UI, so that's what I get to write and talk about.
Eric Meyer: Nice. It's fun having jobs like this, isn't it, where you write about stuff and talk about stuff you want to write and talk about anyway?
Bramus Van Damme: Yeah. I remember before I joined Google, I was doing all this stuff after hours. Now, it's part of my job, so it's amazing.
Eric Meyer: Wait. They pay me to do this? That's amazing.
Bramus Van Damme: Yeah.
Eric Meyer: There's a lot to talk about, so we don't really have time to shoot the breeze necessarily. There's so many things to cover. What are some things that stood out to you though?
Bramus Van Damme: Well, there's two main things that stood out to me, because I worked on them as well. Namely, scroll-driven animations and View Transitions. I think those are two huge additions to the web platform. They're right now available in Chrome, but we have good signals from other vendors that they will also be working on it. Who knows? Maybe it'll be included in Interop 2024? Things are working good for them.
Eric Meyer: I feel like those are things that go together. What is it about them that you feel is ... Other than that you worked on them, because clearly that's a major signal. What is it that they make possible?
Bramus Van Damme: Scroll-driven animations allow you to take an existing CSS animation or a web animation and link that to a scroller. The animation no longer runs at the tick of a wall clock, but it's driven by you actually scrolling from the top of the page to the very bottom. What I really like about this is that it leverages CSS animations and web animations, so you don't really need to learn anything new. You also get to take advantage of CSS animation that, for example, they know how to run stuff on a compositor, so they're not blocking the main thread. This is a win for everybody, because we've seen these patterns on quite a few websites and now you get to do them properly. It's so exciting.
Eric Meyer: Rather than having to script everything yourself?
Bramus Van Damme: Yeah. You're done using a scroll listener with some block in JavaScript you need to do to get the bind, incline, direct thing and whatnot. Scroller animation is much better to do that.
Eric Meyer: Okay. You said there's good signals, so that's good. On View Transitions, I didn't know quite what the signals were. Also, it feels like there's maybe some changes that might have to be happening at the spec level. Do you know where that stands right now?
Bramus Van Damme: What's shipped right now in Chrome is a single-page application View Transition. You need JavaScript to actively do transitions from one page state to the other with some little JavaScript. We are working on landing MPA support, so multiple page applications. That's what MPA stands for, which is just web pages.
Eric Meyer: You mean websites?
Bramus Van Damme: Exactly. Exactly. How we did it 20 years ago. Click a link and you end up at another page. Crazy. That is what's in the pipeline for that. We're also working on ... When I say, 'We,' I mean us, Chrome at Google. We're also working on improving the experience for developers. Because right now, for example, you need to sprinkle View Transition names, unique values on each and every element, but maybe you want to do something generic like adding a class name onto a bunch of elements in one go.
Brian Kardell: So it's funny, because on our last show, the topic was the struggle to keep up. One of the things that we talked about is the earlier you try to follow something, the more noise and stuff you have to keep straight in your head like, 'That's not real yet.' And then, people who come along at the end, they just have to learn what actually works in all the browsers. It's way more efficient for most people to follow at the end. But it's also ironic, because we do need more people ... Not everybody, but we need more people to follow earlier. Since this is the end of year post, it's difficult to know which things to focus on. I think there's probably enough that we could focus on the things that are in at least two browsers, and ideally, in all three. And I would like to have you back at some point to talk specifically about the scroll stuff, because I do think that's a huge topic all by itself.
Bramus Van Damme: Looking forward. What you just mentioned about, 'Sometimes it's hard to keep up,' and then you have to wait until it's landed in all browsers ... I think that's perfectly fine, because for scroller animations, for example, the Chrome engineers have been working on this since four or five years ago. They started at it before I even joined the company. And that was so hard to keep up with, because it has changed the spec and whatnot. Sometimes it really does pay off to just wait until it's available in all browsers, it has settled a bit, and then go in. Even so, you don't have to keep up with all the new shiny stuff. Maybe you can find an excuse to put it into a project or find a good use case, and then might be a very good time to start learning it.
Eric Meyer: Some stuff that is in all browsers ... I'm looking at the CSS Wrapped post, which I believe you had a hand in, and trigonometric functions for values in CSS. You can have values that are based on sines and cosines. Why?
Bramus Van Damme: This is often the topic where people go, 'Oh no. Maths. I remember this from back in school. I don't want to do this.' It helps if you have something like, for example, a circular UI pattern, where you lay out some items on a circle. To do that properly, you need the sine and the cosine. This landed in Chrome this year. I think we were the last to ship it. So this is available cross-browser for you, for more than half a year now.
Eric Meyer: And then ...
Brian Kardell: Can I hijack that really quickly and say, while it's not in your post, the true reason that we did that is to give everyday people something to write about and use MathML in their posts? Because another thing that happened this year that isn't in the post is that ML is now supported in all the browsers as of ... I think it was January this year. Chrome 109. That's pretty huge.
Eric Meyer: Yeah. It's been very interesting to play around with that. Not everybody needs math markup in their documents, but when you do, having MathML support is really good. And it looks really nice in basically all the major browser engines. You get some really nice rendering. And then, there's also the complex nth-child selector was one of the things that you talked about in the post. This is the, 'Of,' keyword, basically. Yes? Or is there more to it than that?
Bramus Van Damme: Yes. That's the, 'Of,' part. So if you have something like nth-child or nth-lost-child, you do something like even or odd or 2n. But with this extra addition, you can pre-filter the subset which you are applying the Nth logic on. You can say, 'I want to have the even of the .special elements,' for example. The engine will then first select all the special elements, and then applied the 2n logic onto that.
Eric Meyer: Okay. That's pretty cool. And now, it's apparently in all the engines as of this year. Similarly, and this one blows my mind, that this actually has come together so quickly. Selector nesting. It's in Chrome as of 112, Firefox as of 117, Safari as of 16.5, where you can nest selectors inside of other selectors the way that you can do in SaaS, for example.
Bramus Van Damme: People have been wanting this for ages. It's why technology such as SaaS and Nest and Stylus came along. And I really like this feature, because it shows that the web catches up. We see some novel innovations in user end, and then it's like, 'This should be part of the web platform. It should be part of the core of the web.' Now, nesting, we finally have it. We have it in our browsers. Woo-hoo.
Eric Meyer: This is why I really like pre-processors, because they are a way for CSS authors to experiment with things beyond what native CSS can do. And then, like you say, that clearly became very popular in many cases. It's the only reason why people at least started using pre-processors. And the working group looked at that and said, 'We should make that native, so that people don't have to use a pre-processor.' And the use of that can take advantage of the engine optimizations.
Bramus Van Damme: Another example that's in the same category are CSS variables, where people have been using variables in their pre-processors for quite some time. But what I really like is, for example, how this got implemented into the web platform. We didn't just get static variables, we got custom properties. That's how variables are implemented in the web. Because they are properties, they can respond to media queries, they can change values on the fly, like on hover, and then all your calculations automatically update. The pre-processors cleared the way and said, 'People want this.' But then, what we got on the platform is even better. It's variables on steroids, basically.
Eric Meyer: Yeah. You can have that sometimes. Layout-wise, Subgrid came to Chromium.
Bramus Van Damme: Yes.
Eric Meyer: It took a while compared to the other browsers, but Chromium, Chrome browsers did get Subgrid. I know that some listeners will probably know at least a little bit of the story, but I think a lot of people probably don't realize what took so long. Not to be a jerk about it. Just literally, what was it that Chrome needed to do in order to make Subgrid happen this year?
Bramus Van Damme: Subgrid, we've been working on this for quite a while. Subgrid is something that was contributed by the people at Microsoft. So there's a lot of contributors on the Blink engine, the underlying engine of the Chromium browser and Microsoft are the folks who contributed Subgrid. One of the reasons I think it took so long is that there were a few tests and edge cases that needed to be cleared out upfront, which were some vague areas in the spec maybe. And Ian Cole Patrick, one of our engineers who oversaw the project, he wanted to be clear that we are shipping the right thing and that it doesn't break in certain cases and whatnot. That's why it took a while.
Eric Meyer: And I'm given to understand there was also some engine rewriting that had to happen?
Bramus Van Damme: Yeah. Before Subgrid ever became an option in Blink, it was a whole BlinkNG rewrite, a whole LayoutNG rewrite from a while ago that laid the foundations to finally enabling Subgrid this year. So it's a lengthy process.
Eric Meyer: So it wasn't as simple as, 'Well we've got Grid. Just add Subgrid.' Really had to be completely re-factored.
Bramus Van Damme: We have Grid. Let's redo the entire foundation, so that we can build Subgrid.
Eric Meyer: Sometimes that's what happens with browsers. You find out that good faith assumptions made five, 10, 15 years, whatever years ago, don't mesh with whatever the new thing is. In your case, it was Subgrid for another browser. They might have to completely rewrite their compositing engine to deal with a new filter or something like that. Just because nobody anticipated that some new filter would come up in the future and they realize, 'We made a whole lot of assumptions that make that next to impossible. We're going to have to redo this whole section of the engine in order to make that work.' And in your case, that happened to be layout, which is probably slightly fundamental.
Brian Kardell: I don't want to skip ahead or anything, but I feel a little bit like we're burying the lead and a little kid at Christmas like, 'Hey. We got container queries and has() this year.'
Eric Meyer: We're getting there.
Brian Kardell: Wow. And in all the browsers. Amazing. Holy cow. Literally, for as long as I can remember, these have been sort of the top two. The number one was has() until responsive web design came along. And then, everybody who used that for about 10 minutes was like, 'Okay. But how do I do it on the element and not the viewport?' And the answer was, 'No. You can't do that.'
Eric Meyer: Right. They wanted container queries.
Brian Kardell: Then, container queries became the number one thing and has() became the number two thing, but wow. Wow. Amazing. Amazing. It's crazy. Not to always plug this every time this comes up, but Igalia had a role in both of those and I'm really proud of that.
Eric Meyer: That's true.
Bramus Van Damme: It's crazy how much the web has evolved, the postures. It's like there's a real CSS renaissance. Whereas, before I was under the impression, 'Okay. We're getting some new features and things not always work across every browser.' But fast-forward to now, 2023, we see that browser vendors are actively working together. We have things like Interop. We are planning to ... We should all release this year. We are getting so much powerful features like has() that you mentioned. The bug report dates back to ... I think it's 20 years ago that the first bug report was like, 'Hey. I need something like this in CSS.' Now, in 2023, it's finally the year that we have it.
Brian Kardell: It first appeared in 1999 in the first draft called CSS3. It was called Subject at that point, but the idea was the same and it very quickly became has(). Like you were saying, we're working together a lot and Interop ... We'll do a whole show on that probably too. Definitely, we'll all probably write posts about that at the end, but I would like to call out what a big deal that has been by just throwing out a number. I need to pause while I find my window where it was. Sorry about that. Somehow lost that.
Bramus Van Damme: No worries.
Brian Kardell: Okay. I do want to just call out. This year, we added a thing that was missing in all the previous years, which is, 'What is the Interop Number? What is the metric?' Previously, we would say Chrome passed this many, Firefox passed this many, Safari passed this many, and we would say your score is 80, 70, 80, or something like that. But this year, we have another number called the Interop Number, which is, 'What is the interoperable set that they all share?' And that number is much lower. This year, at the beginning of the year, the total score for across all the focus areas was less than 60%. That was the Interop score. As of now, it's up over 93%. And that is amazing. I think Interop is one of those things ... I've said this before that I feel like you wish didn't need to exist. You wish this was just how it works, but it is phenomenally hard to prioritize this stuff. I can tell you, as people being involved in the process of organizing it and choosing focus areas and all that stuff, it is astoundingly hard. Even when you do sit in a room together and work on shared priorities and things, it's very difficult. So it's amazing that we do it. And I really hope we continue to do it for a long time. It clearly has huge benefits.
Bramus Van Damme: Often it's always ... Let me rephrase that. Often, I think it's also a hard sell internally. Whereas, we want to spend a lot of time fixing some bug, so that this works interoperable in all browsers. Versus, 'We're going to ship this shiny new thing.' And it's a delicate balance that you have to strike, because I can see that that vendors want to ship new features, but this Interop part, this making things bug-free is also very important. Because it's these little details. It's like death by 1,000 cuts. It's the tiny details that make things hard for developers.
Brian Kardell: Interop does include new features that we all agree to focus on. Even that has a really outsized impact. You would think that it's easier to get ... And it is easier to get everybody to be like, 'Let's do this thing.' It's easy to sell that, but the advantage of everybody doing that at the same time, you can think about this like ... Everybody who listens to this show probably is familiar with the waterfall diagrams and things that are synchronous and asynchronous. You can just imagine that ... Let's assume that Chrome does it first, because well, they often do it first. They invest a bunch of money, they do it, they get it, they ship it. But then, we have to wait until it gets into somebody else's. Maybe it gets through halfway. Or maybe it takes a year. Then, somebody else implements it and maybe that inspires the next people. But what we've seen is that sometimes ... Summary Details, that took, I don't know, a decade or something like that before we had it interoperable in all the browsers. And it's not that big a feature. If you can get people to focus together, you cut down that waterfall, because you just parallelize it. And the other thing that comes from that is that we don't bake mistakes into the platform for five years before the next browser gets there and says, 'Gee. That seems like a mistake.'
Eric Meyer: Ideally not. I know we've talked almost exclusively about CSS thus far, but there's a lot more that's happening in the platform. Some of it intersects with CSS. One of the things that I actually learned from the post about CSS Wrapped: 2023 was the scripting media query, where you could literally, in a CSS media query, find out if JavaScript's enabled or not, and then have styles based on that. And that shipped in browsers this year. In fact, very recently. In a couple of cases, like a week ago as we record this. But that's really cool that you could say, 'Hey, if there's no JavaScript, maybe you make a little widget on the page to just display none.' Because with no JavaScript, it's not going to work. Or maybe you could put up a little flag that says, 'JavaScript is disabled.' Whatever. That's really nifty, that intersection between CSS and JavaScript.
Bramus Van Damme: And I think it's one of those cases where this has been in the spec for quite a while. This existed for quite some time, but it's only now that it's in all browsers. And it was just a matter of, 'We need to pick this up and we need to do this.'
Eric Meyer: From the article, there's a number of things that are happening with media queries. There's one about the refresh rate of a device. How does that work exactly? I wasn't really clear about that.
Bramus Van Damme: I'm not entirely familiar with that one as well. Adam worked on that one. But basically, you can query, 'How fast is the refresh rate of this device?' And is it either fast, slow, or none? And none, for example, is a book. If you print something, printed media has an update rate of none. You can swap out a GIF maybe for a static image, something like that.
Eric Meyer: Okay.
Bramus Van Damme: Of course, you could also use add media print in that case, but there are other devices like an e-reader, for example, so you can target them that way.
Eric Meyer: And then, there's also the reduced transparency media query. It reminds me of the prefers animation or does not prefer animation queries.
Bramus Van Damme: It's another preference query, where you as a user can say, 'I'm fine with motion.' Or, 'I'm not fine with motion.' The same with transparency, which is an operating system setting where you can say, 'No. I don't want these translucent windows,' where the window underneath bleeds through. And then, you can flag the same on your website, so that you can say, 'We don't want to do these half-opacity things. We want to make them Opacity 1,' so that you can't see through it.
Eric Meyer: Okay.
Brian Kardell: Popover. Popover is a good one. That's something that came from Open UI. I think it's the first thing really to come from Open UI, and it's pretty great. It's declarative. It really is a little overly basic without the CSS bit that goes with it. Like anchor positioning. But it's definitely a huge step in the right direction.
Bramus Van Damme: Like you say, popover, I remember the discussions from back in the day. First it was, 'We should have a dedicated popover.' Back then, it was even called Pop-up, 'We should have a dedicated element for that.' And those discussions transformed into, 'No. We should make every element be able to be a popover.' That transformed into the popover attribute, and like you say, the popover attribute by itself ... Okay. It does things, but then there's all these extra CSS editions that you can apply to make things smoother. For example, you can animate an element and as it enters the top layer, which is what the popover does, it shows things in the top layer. You can animate them while they enter, while they exit. It's all nice that we can do it, because now you can create these really rich and smooth user interfaces that we most typically see in native apps nowadays. But like I said before, the web catches up.
Brian Kardell: There's also Exclusive Accordions, which is something that it feels like we should have had a long time ago. Almost everybody who sees Summary Detail intuits that you could just take a bunch of them and make an accordion. And more or less, you can. They lack a group. They lack some kind of group, but other than that, they're very similar. But Exclusive Accordions, where only one is open at a time, exist all over the place. I don't think that they're always a good idea. Oftentimes, it's much better to let the user open or close as many as you want. But there's a nice compromise in the design of Exclusive Accordion, where you can actually close them all. You just can only open one at a time. That really simplifies the problems that you're tackling, but it's pretty nice. And it's shipping in Safari as of yesterday. Gives you a hint when we recorded this, I guess. And it's been in Chrome since 120. I'm pretty sure we're working on it in Firefox, but it's pretty simple. You just add a name attribute to a number of details, and that makes them all participate as part of a group. There's a part of this that I really want to mention and hopefully even help hold pressure and feet to the fire on this, but Summary Details has problems. It has some accessibility problems. It has problems in its design. When we said we were going to tackle this and the Summary Details would be the base on which we would build, a number of us said, 'We agree to that as long as we address these issues that ...' Scott O'Hara provided a nice list of issues that need to be addressed in Summary Details. Here's hoping that those will all be addressed, and Summary Details will get much better because of this focus as well.
Bramus Van Damme: Like you said, Summary Details or the Exclusive Accordion is a very much debated topic, because you're basically saying to your users, 'You can only see one thing at the same time.' Maybe you shouldn't use the Exclusive Accordion, but when you need it, I think I like this. Because now, when you need it, you no longer need to rely on some checkbox hacks or some JavaScript to make it work. Now it's baked into the platform. And like you mentioned, all these other accessibility issues that are not specifically tied to the Exclusive Accordion, but to detailed summary in general, are also on our radar to have it solved over time. Because accessibility is important. We need to solve this.
Eric Meyer: And that's been an area of some debate over some of these changes like the Exclusive Accordion. Horizontal Rules in Select, which is another thing that was in your article. It's more of an HTML feature really, where you can put an HR inside a Select element in order to create little visual divisions in a dropdown menu. I think it's in all ... Maybe it's not in WebKit, I'm not sure, but it's in Firefox and Chrome. Oh, no. It is also in Safari according to the article, so it's in all the browsers.
Bramus Van Damme: Yes. Safari were the first to ship it, and I didn't really see that one coming. And then, a bit later on, it was like, 'We should also do this.' Sometimes it's an idea that's not really part of a plan. So it wasn't part of Interop, but other vendors saw Safari implementing this and they were like, 'We can also do it and we should also do this.' And now, it's in all browsers.
Eric Meyer: But there have been some concerns raised about it. And so, it'll be interesting to me, because it seems like this one did happen very quickly and without much of a plan. Now, it's in all the browsers. Has it been properly vetted? I'm not sure, personally, but it'll be interesting to see where that goes.
Brian Kardell: One other one that I didn't realize ... I'm not entirely sure how I missed this since we actually did a show on this. The inert attribute in Firefox 112, apparently, in April 10th, 2023. That's also another HTML DOM-oriented thing. The inert basically is a way to have something in the tree and say, 'This and all its children,' you just pretend it doesn't exist. It's very useful for building certain kinds of UI patterns where ...
Bramus Van Damme: Without inert, you are able to tap from a dialogue into a link in the DOM that's hidden underneath the dialogue. Visually underneath. That totally didn't make sense.
Brian Kardell: Right. Another thing that I think is really fun to mention is that this seems to be a year in which there was a whole bunch of new excitement and energy around novel and experimental engines. We had renewed interest in Servo. Igalia has been working on Servo and with some funding from an organization and we sure could use more. If you're excited by that, you definitely could support that. Reach out to us. Ladybird, which is Andreas Kling, we had him on and talked about that project.
Bramus Van Damme: Very exciting project, Ladybird. I like it.
Brian Kardell: That one actually is getting some interesting funding now too, so that's great. And then, Shadow is a really new experimental one by a friend of ours who's now at Mozilla, and we'll probably need to ask them on.
Bramus Van Damme: I think it's great to see these new engines pop up, because I'm a big fan of browser diversity. You might say, 'This is weird. You work at Google. You have the biggest user base.' Or whatever. But I'm really a fan of this browser diversity, because together we pull each other forward. The rising tide lifts all boats, and sometimes you need smaller boats and the big boats to all work together and go forward with things.
Brian Kardell: One of the really interesting things we pointed out on the Ladybird show, and it's happened a number of times since then, and I'm like, 'I'm so glad we called that out ...' Because these projects are implementing fresh, everyone that comes along and implements fresh does that thing that we were talking about. Finds a hole in the spec or finds something that needs clarity or finds something that's just wrong. Our interoperability on those is mostly accidental or something. They all improve the spec, everyone that comes along and implements it. I think that's another thing that they can do. Even if they don't wind up being some competitor engine. It's difficult to imagine the hobby projects evolving to compete, but who knows? WebKit, which is the basis of both WebKit and Blink is from KHTML and KSVG. And KSVG was made by two guys who work at Igalia. One of them when they started, Nico was, I think, 13. Maybe he was 15. I don't know. We did a show on it. It was one of the first shows that we did. You could go listen to it. But it could happen. It would take a really long time, but it could happen. I don't know. What else? Do you have anything else that's on your mind? Something else that you think is interesting that happened this year?
Bramus Van Damme: One of the things that we didn't mention that landed in CSS are access to the new color spaces and the new color functions.
Brian Kardell: Right. That's really exciting.
Bramus Van Damme: Because we've seen a lot of design systems where you have your base blue, and then you want to make it a little bit darker or a little bit lighter, so you need to pre-process those upfront. Whereas now, you can do it in CSS with the color-mix() function, for example. You can mix your base color with 10% black, and it will be a little bit more black. Along with that, you can also choose which color space you want to mix it in. The new color spaces are also something that's available across browsers nowadays. Because if you look at RGB, it's like a little triangle of all the visible colors that we can perceive as a human. But then, a color space like Display P3 is much wider than an sRGB triangle. You can, for example, have an even hotter hot pink that you can now access in all browsers. And then, again, you can use these to mix and to combine colors. It's so great. Or even the relative color syntax is also an interesting one, where you can take an RGB color ... Or any color, but I'm giving an example with an RGB color. You take that, you load it up in the HSL color space, and then you rotate the hue by 10 degrees, for example. And then, you get a new color that you can use in your styles. It's so cool to see.
Brian Kardell: I feel like one of the difficulties that we have in the color stuff is that frequently even the terminology seems complicated. Part of it is you have to understand that there's more colors. And that's mind-blowing, because you're like, 'Do I need more?' Most people don't even know about sRGB as how that equates to a color space. The way we think about it, the way we write it, and what it can represent are actually three different things. I feel like because we haven't spent a lot of time talking about this, the terminology for it gets really tricky. Do you know what I mean?
Bramus Van Damme: I'm looking up the article written by Adam Argyle, a colleague of mine. In there, he says, 'A color space is a mapping of colors, where a color gamut is a range of colors.'
Brian Kardell: Interesting.
Bramus Van Damme: The gamut targets the triangle on the 2D image, and then the color space is basically a 3D representation of all those colors like the RGB cube. That's a cube. And then, HSL is a cylinder, for example, and all this other stuff.
Brian Kardell: We should do a whole show on that. There's so many new things to color. It's such a deceptively simple-seeming thing.
Bramus Van Damme: And it's only until you start. For example, if you make a linear gradient from blue to white in RGB, which we are used to doing, you get this gray muddy area in the middle. People are like, 'Yeah. That's how color works.' But then, if you learn to understand the color space is RGB ... It's a 3D movement from one part inside of the cube to another part, and you're going to this gray middle area. If you don't understand how HSSL and LCH work, you're like, 'They don't have that,' because they don't have that problem.
Brian Kardell: And then, you have lab and having more perceptual uniformity as you travel across that space. You don't wind up in these weird rainbows that we don't think of, but it's how the color system works. You know what I mean?
Bramus Van Damme: I think one of the problems with HSL is if you go from blue to white, you make a linear gradient. You end up with something pinkish in the middle, which is weird.
Brian Kardell: It doesn't makes sense intuitively, but it makes perfect sense in the ...
Bramus Van Damme: In the model.
Brian Kardell: And you understand what it's doing. Right. So there's other interesting APIs. The origin private file system got a bunch of progress this year, as I understand. I think that there is support in just about everything for most of it. I believe this is maybe used in Photoshop for the web, if I'm not wrong. That's pretty cool. Import maps.
Bramus Van Damme: Import maps are great. They are so great.
Brian Kardell: Do you want to talk about import maps?
Bramus Van Damme: Sure. With import maps, you can say when you are importing something in your JavaScript import, this function from that file, whatever. If you're working in a Node.js application, it goes look into your node modules folder, and then it will find a file there. Whereas, if you're using it on the web, well, you don't have a node modules folder. With import maps, you can map the file name to an actual location somewhere available over HTTP. That's really great because you can take your existing code that you wrote on your local machine that is using modules dependencies, you upload it to the web, and then the import map will map all the requests of imports to actual files somewhere on the web. It's so great.
Brian Kardell: Yeah.
Bramus Van Damme: You can just have one version, upload it, it works.
Brian Kardell: There's also progress this year on compression streams. That I don't know a lot about, but it's a way that ...
Bramus Van Damme: Same here. Drawing a blank.
Brian Kardell: It's a way that you can use in-the-stream interfaces. You can pipe through to say, 'As the input comes in, I want to pipe it through this compression stream,' and using Gzip, you can zip it as it goes through. Like what you do on a server normally, and it's just done for you. This is now in primitive in the web platform and it is now supported in all of the places. That's pretty cool. I think most people aren't dealing with streams all the time, but there are a lot of special uses of the web where you are dealing with streams. And that's pretty great.
Bramus Van Damme: Another feature that I'm really excited about is the linear easing function. Don't let the name fool you, because if you think linear easing, you're like going from zero to one on a straight line. But with the linear easing function, you can take a complex animation curve, something like a bounce effect, and then you just mark some dots on it that represent that curve. Between the dots, it'll interpolate linearly. If you add enough dots to the line, you can approximate a bouncy curve and do that in CSS. Whereas, before it wasn't possible to do that. You needed JavaScript or needed some other library to do that for you. Now, you can just take any curve, plot some dots on it, and linear will do the job for you. And it's cross-browser. It just shipped with Safari 17.2, which is out just now at the time of recording. Great.
Brian Kardell: Did we miss anything in the article that the three of you wrote?
Bramus Van Damme: No. I think the big lines are there. One thing that's not part of the article is add property that landed in Safari, but it's not in Firefox yet.
Brian Kardell: That's huge.
Bramus Van Damme: That's huge because with that property, you can register a custom property to be of a certain type. You can say like, 'Hey, this custom property, it's going to be a number.' So it's going to be from zero to 255, for example. But what's really cool is that once you have registered your custom property using add property to be of a certain type, it's animatable. So if you change it from zero to 255, it won't switch discreetly from the zero to the 255. It'll actually add up zero, one, two, three, four, and so on and so on. You can use that in animations. It's so cool. Just change the custom property value, use it in a calc somewhere. For example, you can have something go from zero to 360. If you then use a custom property in an HSL function to set the hue for a color, it'll animate the hue as the animation is running. It's amazing.
Brian Kardell: I think there's so many things that opens up. I'm really glad that we finally get Interop on that. I think that is hard to appreciate, but will be one of the more important things in the web platform in the next several years. If you look back, you can see things that were really huge additions that are otherwise low-level. They don't all by themselves do a thing. And I'm not saying that's low-level. Comparatively, it's pretty high-level, but when you think about it, it doesn't by itself do something. It's just a way for you to define a primitive value and just say, 'This is a property that I'm making up and it is of this type.' It enables all kinds of things. And if you look back, you have things like Promises or XML HttpRequest or Fetch. These things that had this really outsized use. There's all these things that you could do with it that led to a lot of imagination and different things. I think that is going to be one that will just be used in so many cool ways.
Bramus Van Damme: It has really changed how I approach certain things. Like on hover, I change a, '--i,' from zero to one, but I then use a, '--i,' throughout the rest of my code and everything automatically adapts itself, transitions, animates. It's so cool. It's had so much impact on how I write my code.
Brian Kardell: That's great. Speaking of the things like Fetch and Promises, there's a bunch of things that happen in TC39 and in related groups. This year, we got well-formed Unicode strings. That is very low-level and I think it is mostly on the back of Wasm. So if you read WebIDL stuff, you see DOMString a lot. But then, there's also this USVString and it's about how you can translate between them, I think. And that's needed for web assembly and other things. Atomics.waitAsync() is similarly at the level. It's a way for you to wait on a value like an Atomic either synchronously or asynchronously. But also, it's not a thing that most people ever write themselves. Resizable and growable array buffers is another example that's like that. Lots of things use these array buffers in the web platform, a lot of the low-level things. Until now, they were fixed size and this is the way that you can allow them to grow. You have to say what's their max grow. What about Regexes? Do you use a lot of Regexes? You write a lot JavaScript? I don't know. I don't know the answer to that.
Bramus Van Damme: I write JavaScripts from time to time. No worries about that. Regex is you either hate them or you hate them a lot.
Brian Kardell: Right. You have a problem, and then you use a Regex. Now you have two problems.
Bramus Van Damme: Exactly.
Brian Kardell: I love them. I use them all the time. But I remember one of my very first jobs, I got partnered up with this very senior engineer and we were working on this thing that was really way over my head. But I was in that phase you are when you're young, where you really want to solve the problem and you don't really have enough knowledge to solve it well. You just keep trying until you get a solution.
Bramus Van Damme: Sounds familiar.
Brian Kardell: But the senior engineer came in at the end and was like, 'Let me show you how I can take this 80 lines of code and replace it with this regular expression.' And I was like, 'What just happened? Teach me this magic.'
Bramus Van Damme: We recently had a fun bug in dev tools related to regular expressions. When parsing values in CSS, we were doing some estimated guesses like, 'This parses as a color, so we should show the color picker. This parses as an angle, so we should show the angle tool,' and whatnot. With the tangent function being available, which is tan, and then you open the parents and then you parse in an angle or a number ... You parse in an angle. We were showing the color picker what we store.
Brian Kardell: I remember this.
Bramus Van Damme: Because tan is an actual color and the Regex for the colors was like, 'Here's all the named colors. Just Regex on the value.'
Brian Kardell: Right. So the reason that I brought up the Regex is that there's this V flag with set notation, which I just wanted to bring up, because I do think it's one of those things that might be interesting to a lot of people. They say with set notation, you can think about your characters like sets and you can do intersections and exclusions and things like that. It's pretty interesting. It's worth looking it up. That one maybe is, again, less used than the last two that I think will be really used. One is array grouping. Do you know the groupBy() things? Have you seen those?
Bramus Van Damme: I heard of those. I think these are other examples of the web catching up. Whereas, we've had these functions available in Lodash for quite a while and have been using them. And now, you're actually part of the platform. It's so great that it landed across all engines.
Brian Kardell: This is a thing that, I don't know, I've done 1,000,002 times, I think.
Bramus Van Damme: I like the example that's given on MDN, where you have an inventory of items. And then, you can group them by, 'Do we need to restock them or not?' You basically pass in a function, check the quantity. If it's less than five, they go into the restock pile. If it's bigger than five, then they go into the OK pile.
Brian Kardell: I think 99% of programming is massaging data into things that are easier to process.
Bramus Van Damme: I love that expression. Massaging data.
Brian Kardell: And then, string lunging. That's like 99% of the engineering in my career.
Bramus Van Damme: I liked the expression that you used there. Massaging data. That's basically what we're doing.
Brian Kardell: Yeah. And then, the last thing that I see that got to stage four this year is Promise.withResolvers. And this is very much like what you just said. It's a thing that everybody has had to do. There are ways to do it. It doesn't really unlock new capabilities necessarily as much as make it a lot easier to express a thing. When you create a Promise, traditionally ... I can't remember the name of this pattern. There's a name for this pattern. Do you know what it is called? It's like, 'Revealing constructor,' or something like that.
Bramus Van Damme: Drawing a blank here.
Brian Kardell: The function itself receives a resolve function and a reject function. What the outside gets back is just a Promise, but frequently, the outside wants to also create or specify even later the way that this will be resolved. The withResolvers lets you address that.
Bramus Van Damme: But I see what this is aiming at. It looks like a great addition to the platform.
Brian Kardell: Boy. Did we miss anything? There is a lot of things in here.
Bramus Van Damme: I bet we missed a lot of stuff, because I'm mainly focused on CSS and Web UI. All the stuff that's happening in JavaScript land or other places, I often see them float by, but I'm too preoccupied with all the CSS stuff. Because like you mentioned at the very start of this episode, keeping up with all the new advancements in web is so hard nowadays. Because it has exploded so much. Even if it is my full-time job now to keep track of all the CSS stuff, it's already a lot. There's three of us in our team, Adam Argyle, Una Kravets and I. We're all busy, busy, busy with all the CSS and Web UI stuff. Even then, internally, we sometimes have to say, 'No. Sorry. We can't support this new feature that you're shipping, because we have other priorities to take care of.'
Eric Meyer: It's just not possible. What do you think about coming forward? What's coming up next year do you see for the web platform? We won't hold you to anything. These are your personal guesses.
Brian Kardell: Or what are you really excited about?
Eric Meyer: Sure.
Brian Kardell: Or here's one. What is a use case that isn't being handled that you wish we would take up? You, personally, not on behalf of Google.
Bramus Van Damme: So one of the things that I am looking forward to is add property actually getting shipped everywhere and getting cross-browser support properly. But along with that, I'm also looking forward to some of the performance improvements along that. Because for example, if you animate a custom property right now in every browser that supports that property, that animation happens on the main thread and it's blocking. Say if you animate, '--i,' from zero to one, it's main thread. So it's not good. I hope that there's room there where these type of animations, these type of transitions can also run off the main thread, so that all our websites will remain fast. And then, of course, there's the big chunks like View Transitions, scroll-driven animations. There's very positive signals from other vendors. They've also started working on things. For example, there are commits for scroll-driven animations and View Transitions landing in WebKit as we speak right now. So I'm quite confident that these will become available in other browsers other than just Chrome. Very much looking forward to that.
Eric Meyer: Cool. Well, hopefully, we will get that and more.
Bramus Van Damme: I'm very much looking forward to Interop 2024 when the list gets announced. Looking forward to that.
Eric Meyer: And then, Interop 2025. We can't get everything. The same way we can't keep up with everything, we can't put everything in any given year of Interop. Once that list comes out and we're able to talk about it, there will inevitably be the, 'Well, why didn't you include this?' And it's like, 'Well, maybe next year.' Because at a certain point, you have to stop. There are way too many proposals. But anyway, we'll worry about that in the future.
Brian Kardell: What about you, Eric? Could you give anything that you're currently looking forward to? Or that you wish we had focused on that we haven't focused on? Or what's your holiday wish?
Eric Meyer: I did a wishlist at the beginning of the year. I should have gone and looked at it before we did this episode. I think, for me, it's more I'm looking forward to the community adapting to and exploring the stuff that came this year like has() in all the browsers. Maybe not CSS nesting so much, but container queries and other queries like that. Just people figuring out really clever ways to use those things that maybe weren't anticipated.
Brian Kardell: Boy, I really like your answer. That's a good one. I hope we do more and more of that. Studying the web and sitting back and learning what is being done, because we do have points when there are clear signals throughout this show. We've said, 'Look, this is another example of the cow path getting paved,' but there's more opportunities for us to do that and to learn from it. I wish that was part of what the W3C did, for example.
Bramus Van Damme: Stacking onto what Eric just said, that he hopes that people will start exploring all the new stuff. With that, very important, be vocal if something is not working for you, if features are missing on the web platform. Because that's the info that we as developers, we also want to collect. How can we make your experience as a developer much better? If you need 5,000 lines of code to do something very stupid? That's not good. We want to know that. So please reach out to us, blog about it, catch us on social media. Whatever. Speak to us at a conference. We're very open to feedback on all the stuff that has shipped and will soon be shipping.
Brian Kardell: There's several things that I, as somebody who cares about the web, would like us to solve. They're mostly the hard problems that I've seen drag on. Those are things like MathML investment. MathML Core is supposed to set out the interoperable subset. That's furthest in Chromium and it needs work in WebKit and Firefox. That stuff is just really hard to prioritize today. SVG also similar. It needs work. It's really hard to prioritize. Those two are historically special. They're historically special and historically weird and we have been trying to unweird them. I would like for us to prioritize finishing that work. I think also Shadow DOM has lots of really hard problems left. Some regarding accessibility. Some regarding, 'What even should it be? What does it want to be when it grows up?' There's stuff in there that I really would like us to finally solve. I think those are really my biggest ones. But I would like us to revisit Houdini. I think we focused on the wrong things in Houdini. We spent a lot of time talking about custom properties and things, but we also had on that radar custom media queries, custom functions. Those would be really important and huge, if we could get them done. They would allow you to polyfill, those kinds of things, and to suggest new ones and gain some experience with them that we could learn about before we bake them into the platform. Those are mine.
Eric Meyer: Cool. No. That's all really good. Hopefully, all that happens this year. So Bramus, thank you so much for joining us.
Bramus Van Damme: Thanks a lot for asking me and I'm very much looking forward to the future episodes on maybe scroll-driven animations, View Transitions. You know how to reach me.
Eric Meyer
Brian Kardell
Bramus Van Damme