I’ve learnt more css from your short videos, than from hours upon hours of other css videos on TH-cam. It’s so easy to follow and you keep focused on one thing at a time. Thanks! ❤❤❤
@@dmtrmrv I was thinking regarding zoom, when you zoom it all scales up. ps- I tried this on codepen: html{font-size:16px;} h1{font-size:2rem;} h1.test{font-size:32px} one p, one h1, and one h1.test they all scale up if I choose to zoom, if I change font-size they remain the same
@vertigoz Oh I see, so zoom feature works a bit differently. It just scales everything. These changes also do not always carry over between the sites. Font size, on the other hand only affects the font size and those changes are global to all sites you open in the same browser. Does that answer your question?
What about using em units for the paddings on buttons? Or when u have an h1 element or an element that’s has a big font size and has a bigger space around it compared to other elements?
I've thought about similar use cases. It makes sense to use `em` when you need to set a top margin of an element, for example, and it has to be proportional to the element font size. This can be handy if the font-size of the element is set using `clamp()`. But if the font size itself is set with `rem` units, then it means we can technically set the same top margin with rem as well, it's just going to be a bit more verbose. I think this use case is a strong contender for using `em` instead of `rem` units, but not a replacement. I'm curious whether there is a scenario where `rem` wouldn't work, but `em` would.
one request my client told me that i will give you figma design in 1440 but it should look same in 1920 and 2k, how to acheive that in term of font sizes, paddings, images etc, please make a video on that
It's somewhat difficult to provide a definitive answer without viewing the designs. However, based on my assumptions, you could set a maximum width for a container to ensure it doesn't exceed a specific width. This approach would center the content on screens wider than 1440 pixels. If the designs are more flexible, using the clamp() function might be an option. It allows you to set a value that stops increasing beyond a certain viewport width. I'll make a video on that soon. On a separate note, in an ideal world, we would have designs done for every viewport. However, this is rarely the case, and such requests are quite common. If requesting additional mockups from a designer for a larger viewport isn't an option, I recommend thoroughly inspecting the designs and identifying any potential risks. These should be communicated to the client, preferably via email rather than verbally, to avoid any surprises upon delivery. Also, developing the skill to visualize how the page will work across various scenarios and proactively addressing potential issues is a critical skill. That’s one of key skills that sets apart a senior front-end developer.
You can change the base size as well: Example :root{ Font-size: 62.5℅; } Body{ Font-size:1.6rem; } No more calculations, your base font size will change in root to 10px then in body change it 1.6rem which means 16px and so on. 62.5*16/100 = 10 Now, 2rem is 20px 2.5rem is 25px Hope this will help you...
True, adjusting the base font size in this way does change the default font size for everything within the body. However, it doesn't address compatibility issues. Consider a scenario where we might use a package that includes the following: .dialog__content { font-size: 1rem; } The developers of this package assume that the default font size is 16px, but in our project, it's set to 10px. This discrepancy could lead to various problems. Not the end of the world, but something that could be avoided.
I’ve learnt more css from your short videos, than from hours upon hours of other css videos on TH-cam. It’s so easy to follow and you keep focused on one thing at a time. Thanks! ❤❤❤
Thank you so much! Happy to hear that!
another eye opening video 👍
bless the day i met your channel
Thank you! Glad you are here!
Fantastic lesson Dmitry. I needed to hear this to help me get it straight in my head. Great channel - glad I found it.
Thank you. Glad you liked it!
thank you man, very good explanation and to the point and short, loved it
Thank you!
Thanks, I see that you use clamp+rems in your codepens, would you please make a video on that subject?
Yes! That's already planned. Stay tuned!
I use em’s for line height. line-height: 1.5em;
Making the line height relative to the font size.
Yeah, you can do that, for sure! Curious why not unitless values like this ‘line-height: 1.5’?
Appreciated
hey, thank you so much, you explain things very well!
Thank you!
5:00 2rem should be equal to that of .pixel, but why is that html that is 16pixel by default changes and not .pixel?
@vertigoz Not sure I fully understand the question 🤔
@@dmtrmrv I was thinking regarding zoom, when you zoom it all scales up.
ps- I tried this on codepen:
html{font-size:16px;}
h1{font-size:2rem;}
h1.test{font-size:32px}
one p, one h1, and one h1.test
they all scale up if I choose to zoom, if I change font-size they remain the same
@vertigoz Oh I see, so zoom feature works a bit differently. It just scales everything. These changes also do not always carry over between the sites. Font size, on the other hand only affects the font size and those changes are global to all sites you open in the same browser. Does that answer your question?
@@dmtrmrv Yes, thanks! :)
Nice one bro
Thank you!
What about using em units for the paddings on buttons? Or when u have an h1 element or an element that’s has a big font size and has a bigger space around it compared to other elements?
I've thought about similar use cases. It makes sense to use `em` when you need to set a top margin of an element, for example, and it has to be proportional to the element font size. This can be handy if the font-size of the element is set using `clamp()`. But if the font size itself is set with `rem` units, then it means we can technically set the same top margin with rem as well, it's just going to be a bit more verbose.
I think this use case is a strong contender for using `em` instead of `rem` units, but not a replacement. I'm curious whether there is a scenario where `rem` wouldn't work, but `em` would.
is it bad to use fontSize: "clamp(1rem, -1.5rem + 8vw, 3rem)" because it might not be able to resize from the user settings
Since 'rem' is part of the equation it should be fine. But you can always test by changing the font size yourself.
one request my client told me that i will give you figma design in 1440 but it should look same in 1920 and 2k, how to acheive that in term of font sizes, paddings, images etc, please make a video on that
off-topic: It should be the designer's job, not yours.
It's somewhat difficult to provide a definitive answer without viewing the designs. However, based on my assumptions, you could set a maximum width for a container to ensure it doesn't exceed a specific width. This approach would center the content on screens wider than 1440 pixels. If the designs are more flexible, using the clamp() function might be an option. It allows you to set a value that stops increasing beyond a certain viewport width. I'll make a video on that soon.
On a separate note, in an ideal world, we would have designs done for every viewport. However, this is rarely the case, and such requests are quite common. If requesting additional mockups from a designer for a larger viewport isn't an option, I recommend thoroughly inspecting the designs and identifying any potential risks. These should be communicated to the client, preferably via email rather than verbally, to avoid any surprises upon delivery.
Also, developing the skill to visualize how the page will work across various scenarios and proactively addressing potential issues is a critical skill. That’s one of key skills that sets apart a senior front-end developer.
Thank's man! I've got it))
Glad the video was helpful!
I still don't understand why there's no babana for scale...
Maybe we can propose 1bbs (one big banana scale) for those really large elements.
You can change the base size as well:
Example
:root{
Font-size: 62.5℅;
}
Body{
Font-size:1.6rem;
}
No more calculations, your base font size will change in root to 10px then in body change it 1.6rem which means 16px and so on.
62.5*16/100 = 10
Now,
2rem is 20px
2.5rem is 25px
Hope this will help you...
True, adjusting the base font size in this way does change the default font size for everything within the body. However, it doesn't address compatibility issues. Consider a scenario where we might use a package that includes the following:
.dialog__content {
font-size: 1rem;
}
The developers of this package assume that the default font size is 16px, but in our project, it's set to 10px. This discrepancy could lead to various problems.
Not the end of the world, but something that could be avoided.