As a casual web developer, it's challenging to keep up with all the changes and recommendations, so I'm grateful that someone like you is undertaking this and providing us with all that information.
You are King of CSS not necessarily because you know everything but a very deep understanding of what you are talking about which i personally love and admire the most about you. Thank you Kevin for every single effort of you
Even better: use dvb/svb/lvb. These are called "logical units", and they will respect the writing mode. "b" stands for "block", which is the dimension perpendicular to the flow of text within a line, i.e., the vertical dimension in horizontal writing modes, and the horizontal dimension in vertical writing modes.
why would you want any element to be 100% height with horizontal writing mode but 100% width when it’s vertical. isn’t that what respecting the writing mode would do?
svh is not just better u have to do it as for the performance tests you will always find the CLS (cumulative layout shift) and definetly the dvh may cause problem there in tests
The timing couldn't be more perfect. I was creating a "Coming Soon" page and when I was working on the mobile version, the footer and hamburger menu sidebar were overflowing with 100vh. I was stuck trying to find a solution, but then I came up with a dynamic vh solution using JavaScript, and it worked really well (even though it took me almost 3 hours to figure it out). And now you post a video, showing me a super simple way to fix it 😂😂
Fun Fact : the :D sign or emoji (in the chrome toolbar) instead of numbers it mean like there is already more than 99+ tab opened funny that Kevin too have the habit of not closing tabs XD..........sometimes i make it change to this emoji ;) if in incognito but i don't know the number
Luckily and accidentally i used svh through vs code suggestions, and it fixed the issue i had with the vh in mobile screens. I didn't really knew what svh was back then but i was super pumped up to see that it worked like a charm
Welcome to another episode of new units to work around issues with old units but have issues of their own. Of course you could also use: bottom but I get that that isn't the point of the exercise. We kinda needed a new way to make pages jump up and down now that most of the old methods have been fixed.
I used svh, dvh and lvh for a project a few months ago and during user testing had complaints from everyone using Apple devices because they weren't working properly (like not at all). Never again, at least not for a few years.
Anyway Everyone can do they own way of CSS - The Dev Tool is way to test and see what's new and what values and units are included and supported by your Browser Inspect Tool. Especially for CSS - when you type your new or select class or id hit the Tab and you will see all available values for the CSS attribute you want to edit, change or check.
I like to use an outer element with 100vh to prevent page to shift height, and then use an inner element with 100dvh to adjust the for objects placement in the wiewport.
I used dvh in one of my projects, it was my first time using it, when i saw the scrolling in mobile i had no idea what was happening, took me some time to discover the issue was being caused by this dynamic heights, and yeah, svh solved the issue
Still prefer the JS route personally, All the advantages of SVH plus you can animate if needed, update on scroll or not. But glad there is more support for this issue. So many years of hacks and work arounds! let vh = window.innerHeight * 0.01; document.documentElement.style.setProperty('--vh', `${vh}px`);
Thanks Kevin. I had this exact problem and I just skipped it, because I couldn't find the perfect solution. Now this video showed up to me and it's so easy :)
Thanks for the easy to understand explanation. I used to think these concepts would just be out of reach for me. 🎉 I struggle a bit with html and css. I think it is because I started with winforms and then later xaml.
I wish dvh had been created the way I proposed it (which even had scrollbars logic built-in) and not the downgraded version they ended up implementing. I also had specified that unless battery saving options were active, the adaptation should be animated. I guess the "should" was taken with it's permissibility of "not". Downgrade being: It doesn't take scrollbars into account while in my specification, it must and I even specified the algorithm...
@KevinPowell, in case you are short of ideas for new videos, I would like to understand how you manage the Cumulative Layout Shift (CLS) issues that occur by adding to the page some dynamic elements, fonts, s, etc.
If you are talking about dynamic elements that are loading when the page loads, you could use skeleton loaders like RUclips does to make up for the space they will take once they fully show up. :)
I'm definitely going to be using lvh for one thing: full-page background images. With vh or dvh they'll get resized, which isn't a desirable side effect of scrolling. With lvh the image will always stay the same size.
I used 100svh in my code and it completely broke my site, spent hours looking for an error only to realise the problem was right infront of me (100svh), these view port units are not supported by all browsers especially old browsers. Fixed it by putting 100vh as a fall back.
Oh my god. I was having this exact issue with fenagling vh on a static site that doesn't scroll but fills the viewport, instantly fixed with one extra letter lmao thank you based css god
actually, sometime this problem happen on desktop, for example when you have a horizontal scrollbar, and then you set the height to 100vh, it will have this problem
I've just tested this out in my current project... Indeed, for most things, svh seems to work better on mobile than dvh. The one exception is for my background overlay effect, which covers the mobile viewport more accurately when set to dvh.
Hey Kevin, an important question! I haven't seen many CSS guru's on YT tackle this problem and so I am wondering if it is only me that encounters it. I have noticed that most people over the age of 45+ tend to have their windows system set to a zoom of 125% or 150%, this zoom tends to break the original style defined for the site when viewed at a normal zoom of 100%. How do you handle these situations ? I mainly use TailwindCSS for my styling, I don't know if it is a specific problem of TailwindCSS where the class uses pixels instead of rem and such... My only solution up till now is to generate a special media query for these 125 and 150 zoom cases and define a rule to zoom out a bit so it looks more faithful to the original design. Many thanks for your genius content!!! (example: @media (-webkit-device-pixel-ratio: 1.25) { * { zoom: 0.99; } })
You don't necessarily need a specific zoom media query. If you use relative properties and appropriately implement media queries for different sizes, zoom effects can be minimized, if not entirely mitigated. It's important to note that zooming primarily alters the appearance by making the screen pixel size appear larger or smaller. For instance, on my Full HD monitor, the viewport width is normally 1920px. However, at 110% zoom, it becomes 1745px, at 125% it's 1536px, and at 150%, it resembles a HD monitor with 1280px width. So, if you've got those media queries set up for different screen sizes, they should still work fine, even when someone zooms in or out.
Sadly dvh is bugged on Chrome Android when you make a fullscreen request when the browser header isn’t already visible. It makes the content height even larger than 100vh because it adds the browser header’s height once more in fullscreen when it isn’t supposed to.
All of you CSS enthusiasts. Please consider not only making videos about super ultra new CSS features and then propose them as solutions, but to propose realistic solutions that include browsers versions from 2018 at least. You know it's wrong proposing something like this as a solution. Or at least change the thumbnail and the title to explain that this is just a showcase of a new feature.
Recently dvh was useful to me for a fixed collapsed menu on mobile. There is no layout shift there because the element is a fixed menu and when I was using vh, bottom of the menu would get cut off in certain cases because of browser UI pushing it down. Using dvh it worked in all cases as I wanted it so that was nice.
What about for width? I always use percentage when creating a container per page but when i check it on an iphone size it has excess space which i can scroll sideways
That’s nice but it’s always worth asking: is it ready for the production? I checked caniuse, so looks like there is only one known issue, the major one though: Safari 15.6 on macOS has an issue where dvh is larger than expected (242758).
WOW, VERY GOOD! I needed that already years ago! Thank you! Is there some way how to affect FONT SIZE (e.g. much LARGER FONTS on much smaller devices?), or on portrait vs landscape?
Interesting that looking at the demos on firefox iOS, all of them function identical to how you'd expect dvh to function. Initially it's all visible, like dvh or svh, and once the URL bar disappears, there's a layout shift. On all of them.
God I've been struggling with this with one component for weeks on firefox iOS. I'm tempted to just throw some JS at it at this point, but if anyone has a work around in CSS I'm all ears.
@@RidingWithJake There is no workaround with CSS as of now, it has been an issue for over 10 years, as recorded in the Firefox bug tracker. The only way is to use a CSS variable updated with JavaScript but you have to make sure to update it only when the height of the page is increased only, not decreased, then you'd just be recreating the issue.
I am reminded of developing SPA's must be 15 years ago now as a creative person the frustration that mobile brings was brought back. But not all bad...developing flash for 800x600 or 1024x768 wow did I just remember those dims off by heart? (not edited)
As a casual web developer, it's challenging to keep up with all the changes and recommendations, so I'm grateful that someone like you is undertaking this and providing us with all that information.
You are King of CSS not necessarily because you know everything but a very deep understanding of what you are talking about which i personally love and admire the most about you. Thank you Kevin for every single effort of you
ditto!
I normally ALWAYS have questions when learning. You cover all the nuances so well I have no questions only full clarity. Excellent Ive subscribed.
The timing. I was fixing a layout and was experimenting with dvh. Will surely try out svh as well. Thanks Kevin
Same here 😅
How did it go?
How did it go?
bro can you tell me difference between vh, Lvh, svh and dvh.coz i am not understanding it
Just when I got to use the vh properly, lol
Me with big brain using 100%
I have the same situation haha
The guy is a developer - streamer, not the CSS god who is commanding you something. If 100vh that’s working for you and you do it right, keep it up.
Well its the same thing anyways
😂
I just started using dvh to avoid some issues, and now I discover that svh is even better. Thanks.
Even better: use dvb/svb/lvb.
These are called "logical units", and they will respect the writing mode.
"b" stands for "block", which is the dimension perpendicular to the flow of text within a line, i.e., the vertical dimension in horizontal writing modes, and the horizontal dimension in vertical writing modes.
Thanks
It's just a different use case, I assume? The video describes a situation when you need an element with 100% height of viewport.
why would you want any element to be 100% height with horizontal writing mode but 100% width when it’s vertical. isn’t that what respecting the writing mode would do?
svh is not just better
u have to do it as for the performance tests you will always find the CLS (cumulative layout shift) and definetly the dvh may cause problem there in tests
You know what, your content is a step above most other channels regardless of content type. Keep doing what you do please. I think you're excellent.
The timing couldn't be more perfect. I was creating a "Coming Soon" page and when I was working on the mobile version, the footer and hamburger menu sidebar were overflowing with 100vh. I was stuck trying to find a solution, but then I came up with a dynamic vh solution using JavaScript, and it worked really well (even though it took me almost 3 hours to figure it out).
And now you post a video, showing me a super simple way to fix it 😂😂
1:09 DVH - Dynamic
2:26 SVH - Smallest
3:11 LVH - Largest
You are the best tutor in teaching CSS. The one reason being you explain in detail and help to understand better the properties and their use cases :D
Believed or not - one of your most powerful videos. Short and sorts a years of problems. :)
Fun Fact : the :D sign or emoji (in the chrome toolbar) instead of numbers it mean like there is already more than 99+ tab opened
funny that Kevin too have the habit of not closing tabs XD..........sometimes i make it change to this emoji ;) if in incognito but i don't know the number
When I saw the thumbnail, I thought this is absolutely clickbait. What could be better then vh? But this is really great!
Luckily and accidentally i used svh through vs code suggestions, and it fixed the issue i had with the vh in mobile screens. I didn't really knew what svh was back then but i was super pumped up to see that it worked like a charm
Welcome to another episode of new units to work around issues with old units but have issues of their own. Of course you could also use: bottom but I get that that isn't the point of the exercise.
We kinda needed a new way to make pages jump up and down now that most of the old methods have been fixed.
Not really, these units were just not necessary before mobiles started having a dynamic height.
Amazing Man... I just had an issue and from 100vh went to 95vh for Mobile view, but now I think I'll use svh for mobile view !
Apparently it's already supported more than 98% by now. Really comes in handy to know about it right now. Working on my first mobile application.
I think applying transition on the Hight property will take care of the jumps in with dvh. It will be cool if the jump is rather a smooth stretch.
Great content, you helped me learn HTML, CSS and, SCSS. I'm now learning JavaScript. Have a blessing day.
Useful! Looks like I’ll be switching my vh to svh from now on. Thanks
love how they made it super trivial to solve a problem that was super annoying to handle
My No.1 channel for CSS content!
I tried to use 100dvh, but my clients don't like to see layout jump when scrolling the page. I will try to use 100svh :)
Nice video!
I have been using dvh and didn't realize that it was causing the layout shift, I guess I will be using svh instead. Thanks for the video.
I used svh, dvh and lvh for a project a few months ago and during user testing had complaints from everyone using Apple devices because they weren't working properly (like not at all). Never again, at least not for a few years.
I just spent a few hours today working on this exact issue and suddenly i find this in my feed, the algorithm is pranking me
omg, someone who actually taught me something i didn't know, thanks kev!
Anyway Everyone can do they own way of CSS - The Dev Tool is way to test and see what's new and what values and units are included and supported by your Browser Inspect Tool. Especially for CSS - when you type your new or select class or id hit the Tab and you will see all available values for the CSS attribute you want to edit, change or check.
I like to use an outer element with 100vh to prevent page to shift height, and then use an inner element with 100dvh to adjust the for objects placement in the wiewport.
I used dvh in one of my projects, it was my first time using it, when i saw the scrolling in mobile i had no idea what was happening, took me some time to discover the issue was being caused by this dynamic heights, and yeah, svh solved the issue
Thank you, I have dealt with the vh problem quite a bit, and didn't know about the new dimensions.
Still prefer the JS route personally, All the advantages of SVH plus you can animate if needed, update on scroll or not. But glad there is more support for this issue. So many years of hacks and work arounds!
let vh = window.innerHeight * 0.01;
document.documentElement.style.setProperty('--vh', `${vh}px`);
We having that CSS convo , About that time!
Oh ya! Did I struggle with this a while ago till I found those units. Thanks for the reminder.
I was suffocating but after adding dvh instead of vh it works and love from my heart
Thanks Kevin. I had this exact problem and I just skipped it, because I couldn't find the perfect solution. Now this video showed up to me and it's so easy :)
Will certainly try this out. Have been using 95vh or so for mobile to fix this, but it's a bit unpredictable.
For me this is useful in media queries since you've mentioned that vh doesn't have problem on desktops but only on mobile view
it just feels so dumb that browser mobile app devs didn't even realize that those moving address bars can absolutely ruin viewport heights
God such great content I need to support you like yesterday.
Thanks for the easy to understand explanation. I used to think these concepts would just be out of reach for me. 🎉 I struggle a bit with html and css. I think it is because I started with winforms and then later xaml.
Thank you for explanation, 0:57
I wish dvh had been created the way I proposed it (which even had scrollbars logic built-in) and not the downgraded version they ended up implementing.
I also had specified that unless battery saving options were active, the adaptation should be animated. I guess the "should" was taken with it's permissibility of "not".
Downgrade being: It doesn't take scrollbars into account while in my specification, it must and I even specified the algorithm...
@KevinPowell, in case you are short of ideas for new videos, I would like to understand how you manage the Cumulative Layout Shift (CLS) issues that occur by adding to the page some dynamic elements, fonts, s, etc.
If you are talking about dynamic elements that are loading when the page loads, you could use skeleton loaders like RUclips does to make up for the space they will take once they fully show up. :)
good one. i didn't even know this existed. no time to catchup. thanks for this!
Only took 2 years for someone to post this solution. I spent a week on this 2 years ago. Never found a solution.
I'm definitely going to be using lvh for one thing: full-page background images. With vh or dvh they'll get resized, which isn't a desirable side effect of scrolling. With lvh the image will always stay the same size.
This is awesome! Solves mobile browser UI overlaps
you help us so much Powell ........wish i had financial means to support you☺☺☺
Thank you, you solved my problem.
really helpful. I wish you a good day.
I used 100svh in my code and it completely broke my site, spent hours looking for an error only to realise the problem was right infront of me (100svh), these view port units are not supported by all browsers especially old browsers. Fixed it by putting 100vh as a fall back.
Best CSS teacher.
He is just like a gold mine but for CSS stuff! Great videos!
Thanks for sharing. Im new to your channel and really enjoy your teaching style.
Love all the short hints and help from you, bro. Shor, simple nd extremely helpful. Keep them coming. I try to give back something whenever i can.
Oh my god. I was having this exact issue with fenagling vh on a static site that doesn't scroll but fills the viewport, instantly fixed with one extra letter lmao thank you based css god
actually, sometime this problem happen on desktop, for example when you have a horizontal scrollbar, and then you set the height to 100vh, it will have this problem
Life saving. I was having headache with it. Thank you soooooo much❤
I've just tested this out in my current project... Indeed, for most things, svh seems to work better on mobile than dvh. The one exception is for my background overlay effect, which covers the mobile viewport more accurately when set to dvh.
Hey Kevin, an important question! I haven't seen many CSS guru's on YT tackle this problem and so I am wondering if it is only me that encounters it. I have noticed that most people over the age of 45+ tend to have their windows system set to a zoom of 125% or 150%, this zoom tends to break the original style defined for the site when viewed at a normal zoom of 100%. How do you handle these situations ? I mainly use TailwindCSS for my styling, I don't know if it is a specific problem of TailwindCSS where the class uses pixels instead of rem and such... My only solution up till now is to generate a special media query for these 125 and 150 zoom cases and define a rule to zoom out a bit so it looks more faithful to the original design. Many thanks for your genius content!!!
(example: @media (-webkit-device-pixel-ratio: 1.25) {
* {
zoom: 0.99;
}
})
You don't necessarily need a specific zoom media query. If you use relative properties and appropriately implement media queries for different sizes, zoom effects can be minimized, if not entirely mitigated.
It's important to note that zooming primarily alters the appearance by making the screen pixel size appear larger or smaller. For instance, on my Full HD monitor, the viewport width is normally 1920px. However, at 110% zoom, it becomes 1745px, at 125% it's 1536px, and at 150%, it resembles a HD monitor with 1280px width.
So, if you've got those media queries set up for different screen sizes, they should still work fine, even when someone zooms in or out.
Thanks for the good explanation! :)@@parves
I'm getting into freelance development and your channel is super helpful!
Thanks
Thank you so much!
I had no idea about vh, never mind dvh, svh, lvh. Very clear explanations and demo!
I would subscribe, except I'm already subscribed :)
Great content and a big plus for the Star Wars + the 'too many' tabs in Chrome.😁
Mr KP! Awesome, always.
very useful info, thank you Kevin
Sadly dvh is bugged on Chrome Android when you make a fullscreen request when the browser header isn’t already visible. It makes the content height even larger than 100vh because it adds the browser header’s height once more in fullscreen when it isn’t supposed to.
Thank you for your Videos
After you mentioned this svh in an earlier video, i've been in love with it ever since. It's now a staple in all my projects 👍
This is awesome!!! Way better than using calc(100vh - computed height of UI element ). Thanks ))
You've fixed my life. Thanks a lot.
All of you CSS enthusiasts. Please consider not only making videos about super ultra new CSS features and then propose them as solutions, but to propose realistic solutions that include browsers versions from 2018 at least. You know it's wrong proposing something like this as a solution. Or at least change the thumbnail and the title to explain that this is just a showcase of a new feature.
Awesome Explanation! Loved It...
Really usefull rules, thank you for informing about these new features of CSS
This has been huge for web GIS applications since they are typically full screen.
Recently dvh was useful to me for a fixed collapsed menu on mobile. There is no layout shift there because the element is a fixed menu and when I was using vh, bottom of the menu would get cut off in certain cases because of browser UI pushing it down. Using dvh it worked in all cases as I wanted it so that was nice.
I was just going to use vh then I saw this. Thanks again
this is very usefull, thanks for te information, greetings from Costa Rica, Pura Vida! ✌
New suscriber, this video or the tittle in this one catch my attention . And Later Here you are! Great content
Omg having troubles with this kind of problem THANK YOU BIG SO VERY MUCH!!
There's also svmin, lvmin, and dvmin, as well as svmax, lvmax, and dvmax... Thanks Mr-Who-Invented-The-Auto-Hide-Address-Bar '-_-
Interesting useful information about css. Thanks a lot.
What about for width? I always use percentage when creating a container per page but when i check it on an iphone size it has excess space which i can scroll sideways
That’s nice but it’s always worth asking: is it ready for the production?
I checked caniuse, so looks like there is only one known issue, the major one though:
Safari 15.6 on macOS has an issue where dvh is larger than expected (242758).
Thanks man. This was helpful.
ohhh this could be a nice css puzzle to post about
WOW, VERY GOOD! I needed that already years ago! Thank you! Is there some way how to affect FONT SIZE (e.g. much LARGER FONTS on much smaller devices?), or on portrait vs landscape?
Love your sweatshirt and the video, of course!
Interesting that looking at the demos on firefox iOS, all of them function identical to how you'd expect dvh to function. Initially it's all visible, like dvh or svh, and once the URL bar disappears, there's a layout shift. On all of them.
God I've been struggling with this with one component for weeks on firefox iOS. I'm tempted to just throw some JS at it at this point, but if anyone has a work around in CSS I'm all ears.
@@RidingWithJake There is no workaround with CSS as of now, it has been an issue for over 10 years, as recorded in the Firefox bug tracker. The only way is to use a CSS variable updated with JavaScript but you have to make sure to update it only when the height of the page is increased only, not decreased, then you'd just be recreating the issue.
i love you Kevin Powell you are great
I've always used dvh, never heard of the other two, until now.
This is BRILLIANT. Thank you!
Really cool I’m gonna try.
Thanks for addressing my question!
Great content like always
I would love to see more videos of javascript from your contents... I love your teachings.
I am reminded of developing SPA's must be 15 years ago now as a creative person the frustration that mobile brings was brought back. But not all bad...developing flash for 800x600 or 1024x768 wow did I just remember those dims off by heart? (not edited)
Now, Some videos are gonna pop up on YT with title 'Ten CSS tips you don't know' and I am pretty sure svh will be in it