 My anger has just been building up slowly for the second half of this whole thing. But, you know, let's see how much more we can go. I can make you more angry. Yeah, I can make you more angry. I just start. Mate, just go for it. Just go for it. I'm already sad about this topic. Why? Because it's getting in the way of one of the things I'm working on. Actually, do you know what? I'm partially sad about it, but I'm partially excited because I've been putting off learning it properly because I thought, this is what I do, by the way. If I can't be bothered learning something properly, I just go, well, why don't they fly here and say it to my face? And then I'll know all the stuff. And you're here to talk about viewports. Viewports, yeah. It kind of gets complicated, so. It used to be complicated years ago and it's got more complicated as far as I can tell. That is, that is. We'll start at desktop browsers. I will be talking about this browser, but it also applies to this browser. There's Chrome and that was Safari. Yeah. Just making sure. Or this browser. That's Firefox. But of course, for obvious reasons, we'll be choosing this browser. OK. OK. Yeah, yeah. My question is, what do you call the big white section there? How do you call it? Well, you know. Don't overthink it, just. Well, I was going to say viewport, but then I'm worried there's now a trick question. The viewport. We call it the viewport. All right. OK. I'm doing OK. Yeah. It's back to the CSS2 level and it says user agents, which is speckling for browser, for continuous media, so not paged media, continuous. They offer a viewport, which is a viewing area through which users can consult a document. That's a beautiful piece of spec text. Perfect. Love it. All right. If you want to visualize it, this is the CSS8 you can use. So you insert an element, you do it position fixed, inside zero, which is top right, bottom left. Yeah. Zero. And I'm not giving it a border here, by the way. I'm doing an outline because border can affect its size. Yes. I was going to say, hang on, outline goes on the outside, but then I hadn't read your fourth line there, which is magic. Excellent. Yeah. If you do this, it will end up here. Yeah. That's what we define, right? The wide area is the viewport. Right now, I'm comfortable with that. Cool. If this is your content, so if this is your body, the yellow part is your body with a paragraph in it, some text, this is the viewport. If your content is too long, again, this is the viewport. Yeah. OK. So position fixed is the viewport, and now the episode can end, and we can all go, no, no. One thing with this, of course, if your content is too long, what does the spec say? Well, if the content is too long, the user agent should offer a scrolling mechanism. So on iOS, we get this thing there on the top right. You can't really see it because it's an overlay scroll bar. So you have the scroll thumb there. It's on top of it. But some other systems, or if you have changed it to your system preferences, you can have a classic scroll bar. Yes. Last time I checked on Max, that switches automatically if you plug a mouse in. Yes. Yes, OK. Yeah. But did you see the change? Let me go back. Oh. This is with an overlay scroll bar? I see. And this is with a classic scroll bar. Which, again, is what you would expect with position fixed. So OK. So the viewport gets resized because the classic scroll bar eats away some space, and you will see also the body. It also became a bit more narrow. Yes. Yeah. Yeah. This is fine. All right. OK. One thing, though, is we call it the viewport. And that name has changed over time. Because nowadays we not only say the viewport because more viewports have come in existence, we now call it the layout viewport. Exciting. OK. It gets difficult, though, because sometimes if you read an older spec, which was published a long time ago, it will say the viewport. Then it means the layout viewport. New respects will say, oh, I'm targeting the layout viewport explicitly, so they will use the correct name. And it's called the layout viewport because that's the... Well, it's called layout viewport because if you... Put position fixed. If you lay an item out using position fixed, it will remain there. So position fixed bottom is there at the bottom of our viewport. If we scroll, the element stays into place. Yeah. I was kind of sensing that you are not too happy with the layout viewport. Neither am I. Why do you call it the layout viewport? And why don't we call it the position fixed viewport? It's because it's where things are layout when the position fixed, right? Because we saw with the body thing, it was going way outside the layout. Things were being laid out outside the layout viewport, right? So that's... Yeah. Yeah, OK. I agree. So this is my personal opinion. I would love to call this the position fixed viewport, but everybody by now uses the layout viewport. So we'll just go with that. OK, OK. That was the layout viewport. But we need to talk about more stuff, namely the ICB. OK. I will explain what it stands for. No words, no words. But first let's take a step back. Say I have a parent element with a width and a height of 10 Ems on both sides. And then in there, I have a child with its width set to 100% and its height also 100%. Yeah. It's giving it a red color just so that we can see it. The child will now fill the parent. That was my question. How tall will the child be? It's just going to be your 10 M, 10 M box, right? Yeah. 100%, 100%. If you put it in the browser, it looks like this. This is a square 10 Ems, 10 Ems. If we pop open DevTools, we can query its size. So we can do, hey, get me the bounding client rectangle of this element. And I will say, well, the width is 160 pixels and the height is 160 pixels, which makes sense because 1M is 16 pixels by default. Multiply them by 10, we get 160. So this is right. Brilliant. Yeah. Now what's happening here is that the child is being sized by its containing block. And the containing block was defined by its parent. So the parent kind of limited, like, hey, this is how tall you can be. So this is a new term that I'm introducing here. It's a containing block. It is also specified. And it says, well, many box positions and sizes in CSS are calculated with respect to the edges of a rectangle called a containing block. And it is the parent that establishes the containing block for its descendants. OK. And then maybe you're about to get onto this, but things like position absolute might change what the containing block is because that will change what 100% and 100%. All right, I'll shut up. That's why it says, in general. Ah, good, good. OK, excellent. So if we take a look at our markup here, the child, its containing block is the parent. The parent's containing block is the body. The body's containing block is the HTML or the root element. Yeah. But what is the containing block of the root element? Oh, dear. Is it the layout view ports? Yes, you're on to things. Is it? Yeah. I guess it's going to be that or this ICB thing. I don't know what it is. We'll just try, right? We'll just, like, for our child, a few sides back, we gave it a width and a height of 100%. We can do the same thing for the HTML element. So if we give our HTML element a width and a height of 100%, we can visualize it. We do the same thing, not a border, but an outline. And we can show it on screen. Just like before? Yeah. So this is our browser. We have some content in there. And to visualize our root element, it pops up like this. OK. Yeah, I've done this before, especially when I was, if I was trying to have a fixed header and an inner scrolling element, the thing I'd start off doing is making the HTML element like 100% or something like that. And that's what we've done here. OK. We call this area the ICB or the initial containing block. So ICB is short for initial containing block. Which so far is exactly the same as the layout view port. That's what the spec says as well. Oh, this is good. The containing block in which root element lives is a rectangle called the initial containing block. And for continuous media, it has the dimensions of the view port. This is sounding good. I mean, we've got two terms that mean the same thing. For desktop browsers. Yes. We'll cover mobile in a while. OK, OK. So it has dimensions of the view port. So that means if this is our view port for long form content, it's the same thing. If we have the classic scroll bar there on the right, if view port gets resized, so our ICB also gets resized. OK, so that's the same still. OK, OK. Look, I'm still OK with this, I think. Cool. But there's a grin on your face. Yeah, we're just building towards something. OK, OK, OK. The definition also says the second part. It is anchored at the canvas origin. So the canvas is where the document is being drawn. This has nothing to do with the canvas element. No, no, no. When CSS talks about canvas, it's just the kind of paintable area, right? We're at pace with the document. And the ICB is anchored at that origin. So that origin being 00, top left. Yes. OK, so as you scroll, that's going to move. Yes, yes. On this slide, I have a boat laid out. If I scroll the page down, you will see our ICB move up with that. I see. Interesting. Yeah, OK, I guess that does make sense. Yeah, yes, it does. We follow the definition. Yes, so this explains the thing of where, if you have the HTML element like 100%, 100%, and then you give it a background color, stuff will overflow it. But as you scroll down, that background color will have stopped at the ICB. Ice. Aha, OK. And the reason, by the way, why you see the content here is because by default, we have this concept of overflow in our documents. So the body bleeds out of the HTML element, so it remains visible there. Right, OK. Huh, I learned a thing. Cool, teach me more. If you want to measure the ICB, so right here, I have Chrome opening it with the DevTools. So it gets resized because we have less. There's less area for that document to paint, right? Yeah. And we can measure it using JavaScript. What would be your guess? Like, if I want to measure? Oh, OK. So if I was going to use inner width and inner height, that's the viewport layer, I suspect. So if I wanted to measure the ICB, well, I guess I would. If the HTML element is 100%, 100%, I could use the bounding box of the root, but only if it's 100%, only if the HTML element has been made to be that size. So that's why we have other properties that we can ask, namely these. On the document element, we can request the client height and the client width. And that will return the width and height, of course. Right, I see. And you just mentioned window.innerHeight and window.innerWidth. By default, these are the very same, but in certain browsers, as you pinch zoom, the value for window.innerHeight and innerWidth change, which is pretty weird. Yeah, that's not good. I don't like that. No, that smells bad. Well, not all browsers do it, though. But some do it, which I also think is weird. So that's why we can't use window.innerWidth or window.innerHeight. We need to use these. OK, client with client height on the document element, that's OK, that's the correct. OK, yeah, yeah, yeah. But does that only work if you had 100% on the HTML element? This just generally works. This is the general. So you use this instead of using the getbound and client track, because for getbound and client track to work, you would need to size it 100% or 100%. Whereas this doesn't. Yeah. OK, learned another thing. Next up, viewportUnits. Yes. Yes. So I'm less familiar with some of the new ones that we have. We'll cover the old ones first, and then we'll talk about the new ones later on. Be brought back into my comfort zone. So this is our viewport, our layout viewport. What if I want to size an element equally to that size? We've got VH and VW. Yes, so we've got viewport percentage lengths, which are relative to the size of the ICB. That's what the spec says. They are relative to the size of the initial containing block, not the layout viewport. OK, yeah. But the size of the ICB is linked to the viewport as we just established. They're the same thing right now, so everything's. There's a link there, right? We've got these units. VW, which is 1% of the width of the viewport size. VH for the height. You also have VI and VB. Yeah, those are new to me. Those are the logical ones. And then we have Vmin and Vmax. Vmin being the smaller of VW or VH, and then Vmax being the larger one. Which I don't feel I've used them so much. Or maybe for font sizes. Sometimes it's handy if you're making a demo where you want a little square in the center. And it should work on landscape and portrait or whatever. That makes sense. So we can use these units for that. So if you want to size a box to the size of the viewport, we use for the width 100 VW, for the height 100 VH. And we give it a light blue background so that we can see it. And it will appear right there. It will fill up. That's exactly what I expected. Yes, cool. If we have larger content, again, the box will appear on there. If we have classic scroll bars. Oh, no, it's going to be fine. It's going to be fine. It's not going to be. Oh, it's bigger than. Yes. So we have the classic scroll bar there on the right. 100 VW becomes too wide. And then as a result, because it is painted too wide, we also get a horizontal scroll bar. Oh, I don't like it. Oh, but so hang on. But that's not then that's this is according to spec, because the spec says scroll bars are assumed not to exist. That's a bad assumption because do you know what? I've seen scroll bars before. They do exist. People either roll their eyes or they go. Yeah, this is not how it works. I'm going to do both at once, mate. We are aware of that. This is one of the things that we are discussing within the CSS working group and the viewport investigation effort, which is part of interrupt 2022. We are looking at this. Media queries, like when you're doing a media query with that assumed scroll bars don't exist. But there's a good reason for that because you can create an infinite loop otherwise. But I can't immediately think of an infinite loop that you could create if VW assumes that scroll bars exist, which they do. OK, whatever. OK. Anyway, you're correct on this. This is developer frustration. Yeah. You didn't expect this right to work. So we will be looking into it. Let's talk about pinch zoom. Which we have on desktop as well as mobile. Yeah, OK. So this is our ICB in red. This is already out viewport in blue. Let's scroll a bit down the page like this. Right, so our ICB is up there. Yeah, our viewport, layout viewport is there. It's the blue one. Yeah, OK. Now what we see there inside of the browser, so inside of the layout viewport as well, let me give it a orange dotted border. This is the visual viewport. Yes. This is the part that we currently see. If you pinch zoom in. Very good. Yes. This happens. Yes, I've seen this before. And you end up with this fun thing where if you will start scrolling up until you hit the layout viewport and then you start dragging that around. So it's kind of like this whatever the visual viewport is kind of like knocks around. The visual viewport is contained by the layout viewport. And if you now scroll the page down again, the visual viewport will move a bit down until it hits the bottom edge of the layout viewport. And then go. Starts dragging it with it. Yeah, yes, OK. If I now pan to the right, this happens here as well. Interesting. So you could be like moving around there, but you're not changing scroll left. You're not changing scroll top until you start hitting against that visual viewport and dragging that up. Yeah, and that's when your scroll events are going to happen. Yeah. Yeah, because the visual viewport has its own scroll events and its own resize events. Of course it does. Yes. So this is what we call the visual viewport. It is also spec that says the portion of the viewport that is currently visible is called the visual viewport. That's nothing too fancy. I can understand this. And we have JavaScript visibility into this as well, right? Yeah. If you want a different visualization of what I just did, so I first I scroll down a little bit. Yeah. Then I pinched, zoomed in. So what I basically did is I made the visual viewport smaller. Yeah. And then we pan to the right. So this is a different representation. This is what you just mentioned. If you start scrolling now again, you will move the visual viewport down. And it's good that it does this, because if you had a few fixed position elements, and so if you were changing the size of the layout of viewport, you would pinch zoom in to try and read a word. But all of the fixed positions that would get massive and obscure the thing you're trying to zoom in. So this makes sense. It's complicated, but it makes sense. As you mentioned, we have some JavaScript API for this to tap into it. We can measure the visual viewport. We can ask, like, hey, how tall are you and where are you positioned? So if I open up DevTools, I can use window.visualViewport. And it will give me a bunch of values. Width and height is the width and height of the visual viewport. So it will always be equal to or less than the size of the layout viewport. Oh, I see. And then the other two, one is relative to the layout viewport and the other one is relative to the ICB right at the top. OK. So you get the distances to both the origins of the R2 port and the ICB. And then scale is a scale factor. The amount of pinch zooming. Yeah. What about these browsers, though? Oh, I've seen these before. Yes. So on the left there, we have a Safari on iOS. In the center, we have Chrome and Android. And on the right, we have Firefox with the URL bar in the correct position. Yes. I think so, too. I think so, too. We tried it, and I liked it, and people didn't like it. And we removed it. Anyway, another topic. It takes some time to get used to, but I like it as well. It's near where your fingers are, so it's easier to type into. Anyway, yes. So we've just established these three concepts, ICB layout viewport and the visual viewport. These browsers, of course, they have it as well. So they have a layout viewport. Yeah. They have an ICB. They do, and it's all looking good. It's the same size as the viewport, and they have a visual viewport. For the pinch zooming and all of that sort of stuff. All right. But, uh-oh. Uh-oh. If your page content is too long, and if you scroll the page down, stuff happens, right? Yes, it does. So we're going to see URL bars disappearing, and presumably that bottom bar in Safari goes. They won't be animated, because this is way too hard to do in Keynote, but I will just show you the after version. So if we scroll the page a bit down, we get this. Great. OK. Yeah. Dynamic toolbars have contracted. They have gone away. How does this affect the layout viewport, the ICB, and the visual viewport? Come on. So rip the band-aid off. Come on. So this is the layout viewport. The layout viewport simply resizes. Yeah. Does it do it frame by frame? As the thingy does it? No. Great. OK. So that's going to snap some point as the URL bar goes away. So some browsers, they just flush it at a regular interval, but only after you scroll a certain distance. Right. Yeah. Some other browsers, they do it immediately. Yeah. Some just wait until you have ended your gesture. And also depends if you're slowly moving, then it will like say, OK, I'm doing this. If you are swiping up, then it will wait. Well, some browsers will wait until the animation has settled. So. Thanks. I hate it. I hate it all. It depends. So there's no spec for it. So the browsers are all doing whatever they want. Great. Perfect. But it's also there for performance reasons. Yeah, of course. Because they want this to run on the compositor and running layout on every frame is expensive. Yeah. OK. So yeah, this is obvious fact. Why it resizes? Because it is the area through which you consult the document. So that has changed the size. Yeah. Right. OK. Just like you resize your desktop browser window, it also changes. OK. Yeah. OK. Yeah. All right. OK, Tic, I agree. What about the ICB? That's the one that scrolls away, isn't it? Yeah. Oh. Does that change as well? And it's still going to scroll away, but is that? I'm just going to tell you. It's not going to change. OK. It's not going to change. Oh. It will just move up. And it won't adjust its size. Because it took a look at the layout support when it was initially there with all the dynamic toolbars expanded, and it says, this is the initial containing block. Right. So yeah, so that means if I have something that's 100 VH, that's going to be assuming all of the, all of the. We'll get there. Oh, OK. This is, that's a tricky part on the mobile. OK. What about the visual viewport? Well, that does change. That one does change. Yeah. That's the easiest one, right? Yeah, that one does change. So if we scroll away, it stays there. It adjusts as the toolbars expand or contract. And then if you pinch the zoom in, they will remain there because it's the part you are currently looking at. Cool, right. Yeah, that was OK. That was OK. That was fine. That was painless. Now let's talk about the large, small, and dynamic viewport. Because you just mentioned viewport units, and this is all related to that. Because we've done this before, we've given an element a width and a height of 100 VH and VW. We've positioned it on the screen. Yeah. On a desktop browser, it would cover up the entire layout viewport. On mobile, it will do this. Well, it's not breaking the rule. Wait, the rule was that that should be the containing. No. Isn't that wrong? Is that wrong? It said it's containing the block thing, which is the we had a box. You drew a box around it before. Why isn't it the same size as the box you drew? I don't like it. Well, developers don't like it either. So CSS developers don't like it either. It's a behavior that was put in there by mobile Safari back in the day. Chrome on mobile eventually adjusted to also do this behavior. So that was consistent across browsers. And the definition now has been updated. So it's kind of OK now, but you have to understand. So I will try and explain it to you. OK. What is interesting, though, if you scroll the page up a little bit, it gets sized like this. Yeah, I can see why this makes sense, right? I suppose. But a lot of times when you want to use that, it's in a situation where you're not going to have a scroll bar. You're wanting to have just that box within the thing. And your scrolling is going to be somewhere inside that. And yeah, I have encountered this problem before. Yeah, now I know why. OK, how do I fix it? If we take a look back, we have these two types of viewports. And we could call the one on the left the small viewport. And the one on the right, the large viewport. Right, OK. And note the colors that I'm using. OK, so green on the left and blue on the right. Yeah, and the box was blue before. So it started making sense. These have been defined at the CSS level. It's a recent update. Well, recent as in no more than two years ago, I think. OK. And it says the small viewport is a viewport size assuming any dynamic UI interfaces. So these are two bars that can go away to be expanded. So here, the address bar is expanded. And the tab bar is also expanded. The large viewport is one where those elements are retracted. OK, yeah, fine. And we've got units for that. Oh, OK, OK. You've got SVH for small viewport height, LVH for large viewport height, and of course, the width and so on. And we can just forget that VH ever existed and just use these instead, right? Because these actually have more meaning. Yeah? Yeah, yeah. OK. You sound confident. That's what I'm going to do. There's also an extra unit in between there, which is dynamic viewport. Can be the small viewport height or the large viewport. And I presume, again, due to composited scrolling, it's not going to happen frame by frame. It's going to snap at some point. Yeah, some browsers only update it after you have done scrolling. Some browsers only do it as a resize good trigger. Some do it after a while. Some add an interval. It is what it is. OK, it's fine. It's fine. But you can use it. So this is both through. Yeah. This is one of the VH, and the one on the right is also one of the VH. So a lot of cases where this is actually what you want, I suppose. Sometimes, maybe. OK. If you're wondering about browser support, by the way, they're on the top right. So this is supported by Safari on mobile, of course. Firefox on mobile as well. It's behind a feature flag right now in Chromium based browsers. OK, so we're not quite there yet. So we're not quite there because, well, stuff that I'm about to tell you later throughout this episode. We are waiting on launching it until we kind of resolve on an interrupt issue before we go all in. So the small viewport units SV and then with height min max, large viewport LV, DV, and then the UA default viewport. So those regular viewport units from before have been renamed to the UA default viewport. Forget about them. Put them in the bin. And the spec says, you know what, user agents. So browsers, they can decide whichever one they want to use. If you want a default to small or to large, just choose one. All browsers have settled on using the large viewport for that. For historic reasons, despite the word before, so to say, you know what, the default one is a large viewport. All right, OK. I'm kind of OK. No, I'm just like, I'm going to forget about those old VH things. I'm going to use the small, the large, or the dynamic one. Once they are there in Chrome on Android. Oh, yeah, yeah, yeah. They're still behind the flag right now. You might be wondering, OK, I kind of get this concept. Where do we get the sizes from? Or does it link to any of the stuff that we just mentioned before, to the ICB, to the layout viewport, and whatnot? Well, the answer is yes. Because our SVH, that's kind of the same as the ICB. ICB, right, IC. And then our LVH is the size of the ICB plus something. Well, plus the size of the stuff that's going to go away. But OK, there isn't another term for that, though. The stuff that's going away. Is that what it says in the spec? Going away stuff. Dynamic user agent interface elements. That's the official term. Oh, I love web specs. Brilliant. Or just dynamic toolbars. That's the easiest to say. Yes, stuff that goes away. This is in the spec, by the way, because I just mentioned before, the viewport lengths are relatively the size of the ICB. OK. And they weren't directly linked to the size of the viewport. They were linked to the size of the ICB. And the ICB is linked to the size of the viewport. Yes. So that's why this kind of makes sense by now. If you want to put them next to each other. Yeah, I see it. This is an old browser with the expanded toolbars. If the toolbars are contracted, you get this. And this makes sense to me. Yeah, I like this. This is fine. And the dynamic one is going to be the, yeah. So just remember, and it's weird to say, but the viewport units, they are based not on the size of the viewport, but on the size of the ICB. Updated slide here. So I've added their small viewport as ICB size, large viewport as ICB size, plus the size of dynamic toolbars. Yeah, I'm on board with that. Are you ready? Yeah, just do it. Come on, I don't. So I haven't talked about resize behavior. I did mention it about the ICB. What is that that you see there on the page? I was going to say it's a box, but you're going to tell me it's a text input. And what happens when you go into a text input? The virtual keyboard gets shown. Yeah, OK. And this is where all things just fall apart right now. This is the ICB. If it's not focused on text input, what happens if we focus the input? Go on. Bam. Right, I hate it. OK, so we're seeing a difference in Safari, which makes Safari look like the outlier. But the other two are on Android, so you could say this behavior is evenly split between Android and iOS. Not exactly. I've created a little table for you. OK. Defines that says this browser resets the ICB. This one doesn't. It looks like this. I see. Interesting. Firefox resizes on both platforms. Chrome doesn't resize it on iOS, but does on Android. And for the record, Chrome on Chrome OS also does not resize the ICB when the virtual keyboard gets shown. Right, OK, so Chrome on Chrome OS behaves more like Safari that we saw before. Yeah, the keyboard is overlaying. OK, well, not OK, but it's in my head. I'm not happy it's in my head, but at least it is. Facts. If you want to see me add some opinion to this slide. Yeah. This is it. This is a personal opinion. OK. Because I have been using iOS for over 10 years by now, and this is the behavior that I'm accustomed to. As a web developer, I suppose, as a user, it's sort of, well, I guess it will crop up. Yeah, OK. I think it kind of depends like what your default is. And then you see the other platform as the other platform. And so this is this is my personal opinion. So this affects our viewport units, right? Because our viewport units were in relation to the ICB. Yes. And due to a resized ICB or SVH or LVH, they also change. Yeah, I mean, I sort of prefer the Android behavior. But maybe, again, I've been an Android user for 10 years. So maybe this is why you are not shipping viewport units just yet. Do you know what? I had this issue on Chrome OS for something that I built for Google I.O. And I had to hack around it in order to get the behavior on the right. Because I wanted, when the keyboard appeared, I wanted the layout to change as the results of the keyboard appearing. But by default, it wasn't, which I presume is what Safari is doing here. We're getting there because this is the layout viewport. Uh-huh. Which one resizes, which one doesn't. Well, same scenario right here. Yeah. So again, if you use something like a position fixed bottom, they will end up in different places. Unless it will be obscure on Android, it will not be. And because we've got here, I now know that the behavior is different on Chrome OS if an element is full screen. Like the full screen element will resize for the keyboard. That one I didn't know. That was the hack I used to work around it. So there we go. All right. Whether that's supposed to do that or not, I don't know, but it does. Our visual viewport, just to make the chart complete, it goes on top of there. This one thankfully makes sense. Yeah. So this is common between all of them. Yeah. It resizes. It resizes. Good right. Yeah. It resizes. Yeah. Yeah. What happens though on iOS sometimes, if the input is like too low on the screen and if you focus it, it will offset the layout viewport and make sure that the text input is centered in there. I think I've seen Android do this as well. So you can end up in this behavior. Android does it well. Yeah. But since it is resized by default, you don't get into it. I see. It does that off. I see. Yeah, that makes sense. So the layout viewport versus the virtual keyboard, does it change yes or no? Well, on iOS, most of them are unchanged. On Android, they all get resized. Okay. Okay. This is the layout viewport, not the visual viewport. Good. Yeah. The visual viewport is changing on all of them. And then on the previous table slide, we had versus the ICB. This is here versus the layout viewport. All right. What happens right there. If you want me to see, add some opinion on there, well, I don't have one. Because there's stuff to say for both. If you are building an app-like interface and you have a bottom navigation bar. Yeah. You want to be there as on iOS. You want to be there at the bottom and you want, if you have a floating action button, I think you do want to behavior on the right where it stays above the keyboard. For example, if you go to the Twitter web app, if you pop up the keyboard to search for something, you want the new tweet button to still be in place there sometimes, I guess. So I think there's something to say for both of these scenarios. Perfect for navbars. Perfect for floating action buttons. Yes. Yeah. So we kind of want both. Okay. I want to talk to you about the virtual keyboard API because this relates to all this viewport resize thingies and whatnot. The virtual keyboard API is only supported in Chromium-based browsers. So that's very unfortunate. Yeah, it's relatively new. And we've asked for standards positions with the other vendors and they seem very hesitant, which is unfortunate. Is it because they don't want to expose that information at all or is it because they don't like that particular API? They don't like the shape of the API because it also has some show and height methods that you can trigger the virtual keyboard being shown. For example, that was one of the things that they didn't like. Okay. Which might be handy if you're building some kind of tool with a toolbar and a button. Yeah. That doesn't have an input that you want to trigger the keyboard somehow. So yeah, I've wanted that before. Yeah, that's fine. Let me show you some code. First, you check if the virtual keyboard is available in the platform. Yeah, of course. And then you can say, you know what, virtual keyboard not overlays content equals true. But there's also this interesting event that you can listen for, namely geometry change. It will give you the dimensions and the position of the virtual keyboard. On the left is a default behavior of Chrome on Android. It resizes the whole lot. If you set overlays content to true, it doesn't resize anything. And I think this is a bit weird that it doesn't resize the visual viewport. Oh yeah, that is weird. But hey, okay, we have a way to switch between. You're right, it shouldn't, the visual viewports should change. The visual viewport, yeah, that one should change, right? Agreed. What's cool is that in CSS, you can use these values as well. There are some environment variables available where you can say, hey, give me the height of the virtual keyboard and take that into account. So by default, if it is not shown, the value here will be zero. So we have 20 pixels plus zero. If it is shown, it will have this extra offset. So you don't need to use JavaScript to lay things out using these values. Nice. One quirk. This virtual keyboard overlays content equals true line. Yeah. That's the way how you activate it. There is no non-JavaScript way to activate this behavior, unfortunately, which is a bug. I filed an issue for it and I've also, hey, give us a way to change it through MetaTec or whatever. But if the keyboard's not overlaying it, then you don't need those values anyway. If it's not overlaying, then... Oh, but if you're on Chrome OS where it overlays by default, you still don't get those end variables. I'm not sure. I need to check that. Okay. Something to look at. Interesting. Now, what if I look into my crystal ball? Because I just mentioned that you need this extra line of JavaScript to activate it. What if we have ways to change it and to choose one of the behaviors? What if we had like, overlay content, which is the overlay content mode that we can enable? Yep. The resize layout mode where it does the Android behavior, but also as a third one, the resize visual... Stick it in a viewport meta tag and let us pick. Is that where this is going? Hey! Yes. If it's not part of the viewport meta tag, well, whatever, we can have a separate meta tag for it. Of course, of course. But it's all to do with the viewport stuff, so it kind of feels like the right place. But we would love to see a way where authors have the ability to change behavior so that they can opt in to one of the platforms. There are cases where you want one or the other and having this ability to set it. I think that's what we want. Yeah, I would love to see this as well, but this is all just me looking into my crystal ball. Of course. Ship it. Jake said it. Ship it. Ship it now, so people don't have to care about this stuff. Well, they do have to care about it, but they at least get things the same across platforms, eventually, when everyone supports this. Yeah. Okay. If I look more into my crystal ball, because if you have the ability to change it, we still haven't solved something. The second part of the problem, namely, if you do position fixed with this iOS behavior, content can get obscured by the virtual keyboard. What if you want an element to be there above the virtual keyboard? Do we need position something else? I don't know. So I was thinking of an addition to position, where you can say position fixed against the fixed viewport and position fixed against the layout viewport. And this fixed viewport would be a new viewport that is introduced. Oh, that's just what we need. Yeah. Why are we talking about viewports, right? So why not add a fourth one? Great. Yeah. But I see the feature. Yeah. What would be cool with this is that this position fixed viewport would not resize as you zoom in. That makes sense, because you wouldn't want it to oblige. You get the obscuring a problem and layouts happening on Pinch Zoom. Yeah. So this is something that we might be considering. Well, I've proposed it to the CSS Working Group. The issue didn't get closed after a first discussion. Good stuff. That's a good sign. So we're getting there, hopefully. Nice. This is the issue, by the way. If you want to compare the different behaviors of the viewports, one of our engineers, Robert Fleck, he made a wonderful demo where you have a drop-down that says, I want the iOS behavior. I want the Android behavior. I want two other behaviors just for demonstration or I want this last behavior that I just proposed. Cool. So you can test it out in your browser. It's all there. He's got screenshot up there as well. Great demo, great stuff. So if anyone has an opinion on that, this is where you can leave it. Excellent stuff. To close off, Jake, these are the last slides. We're almost there. I want to talk about the viewport investigation effort. So all of these things that I've told you today, they are the result of me looking into how viewports behave, how the ICB behaves and whatnot for the viewport investigation effort. So all browser vendors are part of this viewport investigation effort. So we have people on there from Google, from Microsoft, from Mozilla, from Apple. We are all putting our heads together and the goal is to identify the problems with the viewports and differences and hopefully we can get to a consensus, even if that means through an opt-in way or whatever and whatnot. Which means that developers won't have to, they'll have to care about all of the different viewports but they won't have to worry too much about them being different across platforms. Yes, please. So in the top link there, you can follow along. This is where we have our discussions, our meeting agendas and whatnot. The bottom link contains a bunch of test pages which show you all these blue boxes, red boxes, orange boxes that I have shown you. So you can point your browser to there and check them out how they all behave. Great. Hopefully this can all be fixed. Yes, I hope so as well. Your sleeve is folded up. Almost covered the British flag. You're going to get spelt from the country. You can get hung for treason for that.