New Viewport Units

CSD.

Welcome to Syntax. In this Monday, hasty treat. We're gonna be talking about viewport units And, specifically, why we have new viewport units. So in the last view part, you would say, what about the viewport units we have at home? Well, we got new ones here. We have a brand new Viewport units. We're gonna be talking about the problem with the old ones and what the new ones solve and when you can use them. My name is Scott Dalinski. I'm a developer from Denver, Colorado. And with me, as always, is Wes Bos.

Hey, everybody. Stoked to talk about these new v port units. It's funny. I was on the last show, I was talking about How much of a pain the, like, iOS problem was? We'll talk about that in a second. And Scott said, no. There's new ones. I had no idea about these. I'm excited to dig into them.

Yeah. There's new ones. And you know what else we have today, Wes? We have 2 great sponsors. We have LogRocket and Sanity. Now LogRocket is the perfect place To see all of your errors and exceptions happen in real time. And maybe in one of those scribble videos, you're gonna be able to see that you used the wrong viewport units. Maybe that's gonna be something.

So LogRocket, what it is is that they are an exception handling tool, but it's more than that. It's basically a way to understand your users and what's happening on your site. Because More than just getting a scrubbable video replay for your errors and exceptions, which you do get that, you also gain the ability to take control of your user user engagement it. By proactively surfacing issues that could impact conversions and those types of things because what you can see is custom funnels. It. You can see your user's journey through your website, and you get to take advantage of all of these really neat tools that LogRocket has made. So it. No longer is it just the error and exception tool that gives you a scrubbable video replay, which it does. You now get things like heat maps and The ability to really understand what's happening with your users on your site. So give LogRocket a try. Head on over to logrocket.comforward/syntax.

Sign up today and get 14 days for free. This is a service that we use and love and really enjoy. So check it out. Logrocket.comforward/

syntax. We're also sponsored by Sanity, the structured content platform for your next API. I'm going to talk about 1, just one part of their API right now, and that is real time updates. So Sanity has this a thing or you can subscribe to updates on specific things, but they also have server sent events. Have you ever heard of server sent events, Scott?

Server sent events.

No.

Server sent events is okay. So, like, let's say you have, a blog post Or let's say you have a, like if I'm selling a course and I have, like, a purchase and you want to be able Whenever one of those thing is created or updated or deleted or anything like that, you want to be able to Send an event, a push notification, email, or literally anything.

Literally anything can happen when those things happen. It's Kind of like event listeners in the browser, but things that happen on the server. So there's a protocol. It's a standard. No Sanity didn't make this up. It's called server sent events, and you just subscribe to that data, and then you can also pass it one of their Grok queries. Their Grok quick Grok is, Their ability to query for specific items. So give me a all of the blog posts that I have that are in a specific category that I have said I'm interested in. And when when a new one is is published, then go ahead and that server sent event will fire, And then you can do whatever it is that you want from there. It is really, really cool.

Even if you're just it. Kinda interested in, like, oh, I've never actually played with server sent events before. Sign up for Sanity.

Try it out with their real time updates, Because it's pretty nifty. Sanity.i0forward/ syntax. That's going to get you double the free usage. Cheers. Thank you, Sanity, for sponsoring.

Alright.

Let's get into it. So viewport units are kind of interesting. Let's talk about real quick about the ones that we have. We have v h, a v w, v min, The max and that's it. Right? Those are the 4 that we currently have, and those stand for, viewport width, viewport height, Viewport maximum, which gives you the max width or height and viewport min, which is gives you the min width or height, whatever is the lower of those 2. And Those things have worked pretty well, but, they don't take into account specifically on mobile. This is the the big problem is that your view will dynamically change as you are using the web app, specifically in iOS.

As you scroll The bottom bar, which has your forward back, all your button settings, buttons and the top bar, which has your what, like your your URL bar and Anything else in there. Those things hide and show based on where you are in the page. And that can be a big pain in the butt because viewport units don't necessarily Play along. So I was just complaining about that, and Scott said, no. There's new ones. So what are the new ones, Scott? Yeah. Yeah. Well, I should go and say, Wes, that the URL bar in Safari On the bottom, is is yours on the top? Mine's on the bottom. I don't use Safari, actually. I use Firefox on Ios.

So but, like, I've I've had to battle that many times in my career just because I've wanted something to be the full height.

And it's not as easy as saying height a 100% or throw a display grid in there or something like that. Never works as you want. Yeah. And I think the URL bar and stuff on Chrome moves 2 on Android.

It it is, like, a a shifting landscape, especially because when we got these these initial units, we just thought that they would do this.

It. So, like, I personally I was like, oh, why why why is this the, so what we've now been given Is a host of of new viewport units, which kind of seems like a weird solution. Right? Because we have the viewport Units that were the quote unquote viewport units, but those didn't necessarily work in in practical applications, so to say. And so the new ones are l v h, l v w, l v min, and l v max. That's one set of them, and that stands for large Viewport height, large viewport width, large viewport min, and large viewport max.

That is An interesting name. And then we have SVH, SVW, SV min, SV max for small view port, small view port width, Small view viewport height, small viewport min, small viewport max. And then we also have I can please don't say the viewport min on the next one.

Next, last lastly, we have dynamic viewport, which is dynamic viewport height, dynamic viewport width, dynamic viewport min, dynamic viewport map. And this area these are the new viewport units. All all in all, altogether, there are 12 of them, 12 new units.

And if you add in the other ones, there's 16.

The other doodle. The old viewport unit. So we have now 16 units To essentially do the task of what I think most people were hoping the initial ones would do.

That isn't that always the case in coding, though? It's like, This is what I'm expecting. And then the people who make the standards go, yeah, but what about

these 400 edge case things, and it's always just like, oh, yeah. I didn't didn't think about that. So then you have to come out with a new standard. Wasn't expecting the whole URL bar to shift up and down when I You built this. So okay. Wes, do you wanna do you wanna give maybe a a quick little difference between what the difference is between small and,

large here? Yes. What is small and large is? If you want a really good visualization, there's a we've got a link to braam.us, in the in the show notes, you can sort of visualize it. And, let me start with the small viewport because that makes the most sense, is that As you are scrolling, if things come into and out of the viewport, the small viewport is going to give you the smallest version of that. So If you have a URL bar or, some icons along the bottom. Or I could also imagine this it. Starting to become a thing when you get into, like, Ipads, which are wider screens, or maybe, we're they're probably thinking about multiscreen devices, those Foldable phones. Those are going to start to become a thing. So stuff could maybe come out from the side as you have more room or go in if you don't have enough room.

Or maybe you could swipe out with 3 fingers and bring out a tray that has maybe some copy and paste in it or some some URLs that you could bookmark in there. So the idea is that the viewport is always shifting, and the small viewport is gonna give you the smallest version of that. The large large version is going to give you the large version of that. So basically the small version is at worst case what's the smallest this will get? The, large will give you the the largest. So that includes all the possible URL bars. And then you have the dynamic, which If I'm reading this correctly, it will include or it will be a dynamic value that changes based on as you are scrolling in and out. Is that correct? That's My understanding

as well, in in the weird thing about that to me is that after reading all of that, the the first thing that comes to mind is I'm only going to use the dynamic one. Like, dynamic seems like I thought that too. Yeah. The only one that I plan on using. In fact, once this becomes like a standard or it's in all over the browsers, I might just do a command or a a find and replace all VH To be DPH and just call it a day. Because, honestly, what I guess it's giving you more control. Right? There's there's no harm and no foul with more control. But it seems like at the end of the day, we kind of just want to know the viewport height, you know? Yeah. I was thinking like like maybe

if you were building an app and you wanted to implement your own URL bars because like let's think about like electron on the desktop and the URL As we're part of that and you wanted to be able to slide them in when you scroll down and slide them out when you scroll up or like I'm trying to think like they're trying to give us Everything because at some point there's going to be some like animation library that has to throw things just off, it. Just outside. Right? Or, and they need to know, okay, what is it at the min and max so we can make sure we hide these things and whatnot. But I would I'm going to go in there and say, like you said, probably a 99% of the use cases, you're just going to use the dynamic version because that's what the viewport units do right now.

Except. Yeah. Because if you port, if you resize your browser, they will update.

Yeah. Do that. Yeah, they update, but they don't include the URL bar currently. They don't. No, they don't. And actually, in this example,

the large is not including it doesn't include the actual like the Ios bar, like the top with your the time and everything you kind of this. Yeah. All right. Because you can't you can't put anything there. And that stuff doesn't change. I think that's the biggest part. Exactly. Exactly. Yeah. That stuff's not coming up and down. The viewport size, assuming any UA Interfaces, UA's user agent, that's your browser, such as the address bar that are dynamically expanded and retracted To be retracted.

Interesting. Interesting. Interesting. Yeah. So viewport units, you know, these things have been always very, very, Exciting to have. And me, personally, I really loved using these viewport units these past, little while here, especially, you know, they solve one of the big issues that as web developers Has been like kind of an LOL CSS moment for a long time, which is how do I give something a height of 100%. Hey. I put height 100% on this div. It. It's not expanding to the height that I'm expecting it to.

And so now what we're gonna be moving from an LOL height 100% to LOL.

I have no idea which of these 16 viewport units to use to, give my thing to be the height. That's gonna be the new joke. It it's It's interesting. You know what? I'm not gonna hate on having control here because I I like having, more control. I I wonder about the keyboard.

Wes, what do you know about the keyboard popping up and how that affects any of these units? Yeah. So I immediately thought,

yeah, this is handy because You pop the keyboard up.

The keyboard goes over top of your browser.

But sometimes you want to put a button on right on top of the keyboard, whether it's like some emojis that you could possibly hit or some information or simply just a button that says save form and you want to have that stuck right up against the keyboard. So apparently, this does not take into account The actual keyboard and this because the keyboard goes over top. Right? The viewport does not necessarily change. And that makes sense because if you have stuff that you want to go behind the keyboard and keep scrolling, then then that makes sense. So there is a new API that will be for detecting the size of the virtual keyboard.

And it looks like, Oh, this is cool. This is another viewport unit. It's using an environmental variable.

Remember we talked about environmental variables a couple episodes ago? Yeah. Where this is information not about the view This is information about the user agent, and that's why they are rolling out env variables in CSS.

And the example that they give is make the height of this thing the environmental variable keyboard Inset height. And that's really cool because that will give you a literally a variable of how high the keyboard is. And you can throw that sucker into calc or whatever it is that you need, and you can figure it out from there. So, man, there's some people that are really took a step back and thought about this type of stuff because It's it's all edge cases all the way down. So super, super helpful. There's also a JavaScript API for figuring out, if the keyboard is currently open or not, which is I I did that on my keycode.info website is trying to figure out how to programmatically

open and close the keyboard was It's always such a pain. So is that is that API navigator dot virtual keyboard dot overlays content equals true? Is that is that how you open up the keyboard? Is that kinda what I'm seeing here? Oh,

I think that is.

The overlay's content attribute enables the author to opt it. Out of resizing the visual viewport described in the okay. So if you don't want it so opening up the keyboard programmatically is actually very tricky, on Ios because they don't want you abusing it. I guess people People were abusing it. So I like it used to be where you just had to focus an input and You could programmatically focus literally any input. Mhmm. And then it would it would open up.

And then it was Okay. You can only do it if the input is visible. Kind of like like, you know, like a pop up blockers didn't let you just open a pop up. It had to be associated with, like, it. An actual click. And now it is even one further. The the input has to be visible, and you have to it has to be associated with, like, a touch event. So, like, I had I figured out that you could put the keyboard like 1 pixel.

I forget what I did on the key code info, but I did some sneaky stuff where I'm like, what's The threshold of off screen and opacity that will allow you to still do this programmatically.

That's funny.

That's funny. Yeah. I remember talking to the guy from who built Gmail mobile, like, years ago, and he said that they would Programmatically listen for the touch start event and then quickly move the input box under your finger. You would focus it and then move it off.

It. Oh my gosh. The amount of, like, clever clever hacks people can come up with. That's like the spirit of the web right there.

Okay. So cool. We have these new viewport units. They're going to solve this issue.

When can we get our hands on these viewport units? Well, it looks like they are Supported with the green, all green, ready to go in Firefox and Safari and Safari on iOS.

We got a big old red on Opera, Opera Mini, Android browser, a lot of the, just kind of extraneous Chrome or, Android browsers that exist. Internet Explorer is gonna remain red forever, obviously.

And then Edge has a big red too, but Chrome Has had this behind a flag for a little while. It was released in March 28, 2022.

So a few months here, it's been behind a flag, but It's remaining behind the flag. So Yeah. Unfortunately, this isn't something that we can really use just yet. I'm wondering when this is going to hit. And once it does, maybe we can do that command find replace.

So big question.

This is this is interesting.

Is is v w and v h dead to you? Are they dead to you? Not yet. But I think that

Probably in the next 3 or 4 months, what is gonna happen is Chrome will roll it out. That therefore, Edge will roll it out. And so then right across the board, it's already in Safari on Ios. And the beauty of this is that you can just use Height, a 100 v h. That'll cover everything as good as it can get, and that'll cover everything in most cases. I guess fine for desktop.

And then right after it, you can say height, a 100 l h.

And if the l h is not supported, that rule will break and it will fall back to the VH. So this is not something that we're going to have to be waiting on for months months months. Once it hits Chrome, I think we can sort of hit the hit the ground running. Those, like, Android browsers, like Samsung Internet and UC Browser, those are pretty popular browsers, But VH is going to cover you in in those cases as well. So I think we're in pretty good shape. The big one is iOS It's such a pain in the butt, and it's already implemented. So we're I think you're ready to start using this today as long as you provide a sane fallback. Saying fallback, that might be a good use case for a, like, Sass mixin. Oh, Sass mixin. Yeah. Oh, I thought you were there.

Not doing that transition. Yeah. Not doing that.

Awesome. All right. I think we are in good shape. Anything else to add? Or should we wrap it up? Let's wrap it. Alright. Thanks for tuning in. Peace.

Peek.

Head on over to syntax.fm for a full archive of all of our shows, And don't forget to subscribe in your podcast player or drop a review if you like this show.