 Recently, I was asked to write an article about the Visual Viewport API. So usually I thought of the Viewport as basically the rectangle of top of your entire document, the subsection that you can see. Right, exactly. And that was kind of how things started on mobile as well. Like we had the idea of a whole document and then a Viewport, which is the bit you were looking at. But what Apple decided is to have this extra Viewport. So when you pinch Zoom in, you're now in a Viewport inside the Viewport. That's very inception-y. It is. Mup. Wow. Summer wins again. I think my job is done here. So here's the thing. And this is how a lot of browsers implemented at first is position fixed items would sit on the Viewport. If you position something fixed on top, it sits wherever you do that on the Viewport. So you're scrolling a lot, it stays fixed. It would still stick to the top. It gets bigger. And eventually your position fixed items, if you have them, are now taking up the whole screen. And this is something that I think Apple pioneered is the idea of adding multiple Viewports. And the names we've given them is the layout Viewport, is the outer one. And that's the outer scroll Viewport of the document. That's where the position fixed items will stick to. And when you pinch Zoom in, you're now in the visual Viewport. So it doesn't mean that a layout Viewport only moves vertically, because you can still have a layout that is wider than your layout Viewport. So it can still move both directions. You can think of the layout Viewport as being the same as the visual Viewport when you're zoomed out as far as you can go. One of the problems that a lot of mobile browsers had is they couldn't decide which Viewport the value should be for. So one of these ones is getBoundingClientRects. Yes, I see that would be a problem, because usually those are the coordinates of the rectangle of the object that you're calling that function on screen. But now on screen, right? Right. And most browsers agreed that that was going to be to the layout Viewport. So pinch-zooming didn't matter. I would tend to agree. Right. But then most browsers also agreed that scroll top would mean the visual Viewport. Really? Right. Yeah. Exactly. And this had a sort of thing that the visual Viewport is a complete abstract. It's a layout Viewport implies layout. And then the visual Viewport is just basically a visual trimming of whatever you laid out. Exactly. And that's what browsers are now trying to do. Yes. Yes, you've come up with the correct answer. Unfortunately, you're too late. Other people already got there. And they're implementing it. And this has planned an agreement between Chrome and Apple, and so there's a lot of agreeing as well. So one of the things you would do with getBoundingClientRect is you didn't want that position within the Viewport. You wanted the position within the document. I was just about to say, and then you need to both scroll top and getBoundingClientRect to be layout Viewport. Because then you can just add the two up and find the position within the document, which is super important, which I just recently ran into. Because sometimes you want an element to detach from however it's laid out and position it absolutely but relative to the document. Right, because you want to do an animation. Exactly. And that's why you need to be able to do that kind of math. I guess if we had chosen the other way, it's all relative to the visual Viewport, we would have probably added some calls to do the calculations in there. But that's unnecessarily complicated. So I'm really happy they went that way. But the web is full of this code now that is doing that getBoundingClientRect plus scroll top. Which breaks as soon as you pinch zoom in. Yes, true. Oh yeah, we would have broken the web. Yeah, exactly. So this move to making everything the layout Viewport is actually starting to fix existing code, which is really nice. Nice, yeah. So the idea is, like you say, make the pinch zooming thing pretty much entirely transparent. Like that's something that is reflected in any web APIs. Isn't it exposed in any way? Can I figure out if the user is zoomed in? So that's what the visual Viewport API is for. Ha! Yes, that is what the visual Viewport API is for. And it is basically the idea is that this is going to be the only place where that is exposed. And it will tell you the position and scale of the visual Viewport relative to the layout Viewport. I think one of the things that would be useful for is when the user zooms in, get rid of all of the position fixed stuff. Because that is kind of getting in the way. Unless that is what the user's zooming in on, in which case that will be annoying. I mean, it just now landed. So I'm assuming some best practice and explanations are going to start happening soon around that. Yeah, and I think it's one of those extensible web things where it's like, it's information we have, we should be giving developers it. And you can use it if you need it. If not, everything's just going to behave the same. Right. Or better now, I guess. Yeah, and even there's something like analytics. So you could find out where your users are pinch zooming. You might find on one particular page, everyone's pinch zooming in, so you can then go and investigate and go, oh yeah, these buttons aren't great or something. So yeah, that would be one way. But yeah, that's the visual viewport. And this is something that I think Apple pioneered is the idea of adding multiple viewports. Apple pie on you? I had to do it. Sorry, no.