 I think, they asked me to go this side, I think so. Oh, like inwards. Bobble in the middle. Bobble in the middle. So, yes, here we are. We are back. This is our third episode of our, is it a Christmas special? It's the AGP203 2019 Chrome feature. Olympics. Slam dunk. The Olympics at Christmas, the Christmas Olympics. The Olympics. So, we have already taken 68. Thank you, some, it's the end of the year. I'm so tired. What have we taken? We've taken numeric separators, Intel stuff, match all class fields, image aspect ratio, blob reading, image and clipboard. This takes us really small for the, and I don't have my glasses on. And sharing, and we have whittled it down to just sharing. Just sharing, yeah, that's the best of them all. And that is canonical and infallibly correct. Infallibly. Infallibly? Infallibly. Whatever, that's fine. Yeah, get me to speak German. I'm not going to. You did? Are you a friend? You have a Zwei pony. Zwei ponies. Actually, Zwei is two. Yeah. Well done, you. You are genuinely, I said I know a tangent. No, a tangent on 203. It's Christmas, we're allowed a tangent. I was speaking at a conference in Germany, and I went to the bar, and on the way to the bar, I was like, I did German at school, I got this. And I went to the bar, and I went, Eina, and then I realized that's all I got. But you know Zwei, you could have said Zwei. Well, but it was more, I didn't want Eina's Zwei. I wanted a beer. I thought maybe just go for two beers and keep it simple. The problem wasn't the number, it was the beer. Let me tell you, if you go to a German bar and just say Zwei, you will get two beer. Yes. If only I knew. That's how we roll. Excellent. OK, circling back to this. So we came up with sharing as our finalist. And now we need to find the other finalist. The other finalist. Yes. We have 16 mostlots. We have eight mostlots. So now you're getting the number on. Can I guess, 8, 9, 10, 11, 12, 13, 14, 15. 15. I meant 15. Oh, I see, you're trying to get out of it. OK, yes, you're right. OK, we've got multiple decisions to make. Actually 16 for the winner. So 16, boom, I was right. Shut up. OK, OK, let's stop talking nonsense. Let's get down to business of finding out the feature we like the most. What have you got? Takes two to tangent. That's what we should have called this show. Why is it two or three instead of takes two to tangent? Right, OK. Backdrop filter. Backdrop filter. OK. I like this one. There it is. And you want to jump straight in. No, oh, I do, actually. This is how we do it. Yeah. OK, so backdrop filter is basically allowing you to define how an element's background interacts with whatever is behind that element. So we have a couple of decently sized square elements here and go through different variants. So the background image is just an image in the background. And depending on which elements on top, they render differently. So you can do sapear. You can saturate the background. You can shift the hue. You can do brightness, all these things, which can yield really, really nice effects. So you've seen this on, I think it was Windows Vista when it first did it. But Mac also does it now. It's like where the window has that sort of frosted glass effect. Oh, yeah, Blur Swarm. Here it comes. Whee! Here it is. Blur Swarm, look at it go. Where you can blur whatever is behind the element. Excellent. Amazing. And that's it. It's just a simple CSS feature, but I think it allows you some really, really nice visual effects. It's something developers have been trying to hack around, like having to provide multiple images. And then do masks. And then, yeah. OK, OK, fair enough. But I am going to pick something else. I'm going to pick this one. Oh my god. Something good, please. All settled. All settled. There it is. Take two. Take three. So all settled. Here we go. This is not as good as your feature. Or maybe, maybe we'll find out. So promise.all. Yes. You've seen this. You give it multiple promises. And it will resolve with all of them. The thing all of them settle with. Yes. Fulfill with. But it will also reject as soon as one of them rejects. Right. So I think they call it a short circuit. If one of them rejects, it's short circuits. Yes. So if you are fetching 10 things and one of them fails, the whole operation fails. Yes. Which can be problematic, because in that case, you would really want to know which one failed. And then keep the other ones. Keep the other ones and re-fetch that one, maybe, or something like that. Well, it's amazing that you want that, because look, it half arrived. This is promise.all.settled. Oh, it's quite complex in the data structure that it gives you, isn't it? But at least you have access to both the data and the actual status explicitly. Yes. So you get an object for every promise you pass in. You get the status of fulfilled or rejected. And you get the reason if it rejects. Yeah. And you get the value that it fulfills with. If it fulfills. So this is where you would get all of your fetches, or you'd get your responses for everything that worked, or you'd get your reason for the one that didn't. And you can decide to re-try that one. And that is it. That is it. That is it, isn't it? So. Actually, now I said that out loud. It sounded better than I thought. It's nice to have. I actually, I have to admit, I haven't needed all settled. Because fetches, for example, only reject on network error. So it's kind of rare that some fetches would succeed and others don't. Oh, I see. Because a 404 doesn't. There's lots of other operations, though, that will. I know. I'm saying that I haven't encountered them in the things that I've written, which is not surprising. I don't write that many things on a daily basis. Yeah, that's fair. And also, what I will say is, I'm glad that all settled is there, but this is so easy to polyfill. Yeah, it's just a little map. Because these promise are all just map over the error you pass and just use a catch. Yeah. Actually, both then and a catch to turn it into the data structure. You wouldn't even need the then. You just need the catch. Oh, no, you would to convert it into the object. Yes. OK, fair enough. Yeah, but it's like five lines of code. Yeah, it's not the thing. Backup filter. Yeah, backup filter. Come on, you. I agree. No, I absolutely agree. I think that's totally fair. You won the first seven rounds in the other side. But you've got the other finalists, so I'm getting a little bit worried. Right, so we're on to our next set of frames. I shall pick a candidate. Media keys. Media keys. That is an exciting one. Yeah, it's off you go. You can present it. Media keys. If you have ever wondered. Media keys. If you have media keys, which many of us do, you might know that there, for the longest time, there was a problem of pressing play pause. And if you had media playing in the browser, they just wouldn't know. And they would usually just interact with, like, open my tunes or whatever. Yes. What happened, which is really annoying. Yeah, exactly. Now, web apps actually have the capabilities to subscribe to these keys. However, it is gated on having a media session. So you can't just say, give me the media keys. I own them now. You have to be playing a video file or an audio file that may be via web audio API or anything like that. But if you have a media session, then you can set what is called an action handler. I don't know why they called an action handler and not an event handler or an event listener. That's the spec. Maybe because there's only one rather than multiple. Is it worth defining a new API for? Well, yeah, I guess. That's fair enough. Well, you could already do key listeners for this, but you have to be in on the page. Right, so this means that the window doesn't need to have focus. Right. And it would work. And music is an important use case for that, right? Yeah, like, I mean, the Spotify web player is really good. And this now allows that web player to actually listen to the media keys, even if you have focused something completely different on the system. I wonder if this works in the previous episodes. We were dropping each other in like a difficult question. Keep going. Does this work with the media keys you get in an Android notification? Yes, well, the thing is that I think the media session on Android already is in the notification bar and that is already directly tied to the playing element that may be. Oh, so this might have already existed before that. On Android, it probably had worked before. Although this would obviously allow you to add custom code. So I think the play, pause functionality worked before, but now you can run custom code in response to this action. Yes, which would be things like if you're, especially if you're using media source extensions to fetch chunks, you'd stop the fetching. Exactly, so I think this will also work on Android. I'm pretty sure it will. All right, cool. Well, so my turn to pick a feature. Pick a feature. Come on, then. I'm going to take this one that you ripped as we were. Nobody would have noticed if you didn't say it. Look at that. Look at what he did. All right, but. Oh, Jake gets a Jake feature. I get a Jake feature. This is background fetch. There we go. Another one that we did a whole episode on. We did, because it's your feature, so why wouldn't you force it down? Again, I'm really happy that I picked this, because yes, it was one I had some involvement in the design and the specification. This is a little app that we made. It's on Glitch for downloading a podcast. We do a podcast. We do a podcast. Yeah, you should download it. With the app, if you want to. Or a real app. Or a real app. I'm like, confidence in your own app. I don't maintain this app. It was built for a demo. I think it still worked when I did this video. Anyway, so what we're seeing here is you click download. It will start downloading the podcast, but it will be using background fetch rather than normal fetch. And that means that you get this nice little notification that shows the progress. But it also means that you can close the web page. You can literally kill the app or the browser. And this will keep down, because it's now in the operating systems hands, right? Yes. And then as soon as it's complete, you can change what the notification says. And then you get an event in the service worker. In fact, should we look at some code? Should we look at some code for that? So this is where you take a service worker registration. You want to fetch these things. It can be multiple things. Good. That's often the case. Yeah, artwork and MP3. In the case of video, it can be thousands of chunks of video. They chunk the videos off the road quite often, right? This is the information that will go into the notification. Nice. There it is. And then over in service worker land, on success, you get the files, and you can do all of them. So I can't believe that this is what you call the event. Well, what would you call it? We talked about this in the episode. Watch the episode if you know what I would have called this event. We will have a second argument about it. And then you can also have a click event on the notification, which will do what you want, right? You open the window, depending on whether it was a success or a failure, or whether it's in progress. And that is basically the whole thing. That is quite nice. Yeah, we do have a whole episode on it. And it does upload as well, right, if I remember correctly? Yes, that's correct. Well, it's background fetch. Yeah, it's fetch in the background. Yeah, so it can be upload, download. It can actually be a combination of the two, because you can have a fetch which has a body on the request and on the response. So you can imagine sending something to server and getting a converted version of that back. Oh, yeah, that can work. Yeah, so that's upload and download, which is something that I don't know that people often forget about. It messes with progress bars a lot, although I think we've dealt with it in this spec. Anyway, so yes, here you could, instead of caching all the stuff, you could just be looking at the responses going, yes, I uploaded all the videos. Well done, me. That is possible. That is background fetch. Good. Yeah, this is not a very good thing. Media Keys, actually it's a non-polyfillable capability. In that sense, it is cool that we ship this. And I think there are apps that are gonna be so, so happy that this exists. The average web developer probably doesn't care as much. So it's fair to say these are both somewhat niche features, right? Yeah, I guess. So, you know, the key is only if you're playing... Media, shockingly. That the user's likely to have in the background, so your YouTube just Spotify's, things like that. And background fetch is only if you're going to be dealing with larger downloads and uploads. Yeah. Which feels like more, but it's still like your blog, you're not gonna use it, right? Yeah, that's true. So, I mean, maybe if you offered the user a button to say, you want to download all the articles for offline, background fetch would still be useful in that case. So, yeah, I don't know. What do you reckon? I think in terms of capability, background fetch is gonna be more impactful. All right, all right then, cool. Oh, and that means we would need to do this. Oh, interesting. And we've got backdrop filter and background fetch. Again, this problem we come up against of like a relatively somewhat low level feature. Like fetch is the real low level, background fetch is a little bit higher level because it handles the operating system. It's a combination of service workers and fetch. Whereas backdrop filter is just, it's like a one-liner to make this do stuff to the background, don't care. And it's one of these things that you could, you can definitely imagine two different camps of people having a strong opinion about. Oh, yeah, absolutely. We're gonna upset people with this. Yeah. That being said, I feel like backdrop filter is somewhat polyfillable, probably in an awful way, but there's ways you can work around the issue. You could provide multiple images. And most of the time it's not about functionality. Backdrop filter is for visual embellishments. Which are the web, right? The web is a visual embellishment. They're important, but it's not holding the web back in terms of capabilities. Yeah, we did have ways of working around this. The bit that you couldn't really do is if you had an SVG animation happening in the background and a thing on top, which would combust and blow up. There were limits. That would be difficult. You would sort of have to go down to canvas to that. But I mean, yeah. But with background fetch, you either force the user to stay on the site to do your downloads or keep the cat tab alive somehow and do it while the page is open. It's definitely almost impossible to get resilience to a normal user lifecycle on the phone. Yeah, and this does take a chunk of what was previously native only territory. Like your offline video sites and make some possible on the web. What'd you reckon? What'd you reckon? Should we go? I pressed the button. I'm not entirely sure which button you're gonna press. Oh, you leave it up to me. Well, then. Oh, I disagree with that. Don't press it. Then we will use the correct one. Excellent. Fair enough. OK. So that means we have found, once again, our first semifinalist. Yes, there's only one episode to go where we will declare the winner. The most popular feature, according to us. And that's really all that matters. Yeah. Well, until the next episode then. See you. This would be my tactic if I, you know, if you go to the toilet in a place and you're in over and then you look down and you realise you have just splashed back all over yourself. That's the tactic is just to go to the sink and just put all the water everywhere. And then I'll go out and just like, the tap exploded. Yes, yes. It's definitely not we.