Is setting height as bad as people like kevin say or is it exaggeration? what about aspect-ratio?
3:28 kevin suggested not to use height. He also says that in some of his other videos and I've also heard it from other people.
1. Does this apply to aspect ratio since it's also setting height?
2. What about when I use
height: 100% on my <img/>? should I stop doing that?
3. What if I set height with rem or em units? Is that still a no-no?
4. If I had a <table/ which was pushing all the contents bellow to a mile away and I wrapped the table in a <div style={{ height: 50vh, scrollY: 'scroll' }}>, would that be an 'ok' case to use height?Kevin Powell
YouTube
Are you using the right CSS units?
There are a lot of different units that we can use when writing CSS, in this video I give some general rules of thumb of which ones are best suited for which situations.
Zell's article on media queries: https://zellwk.com/blog/media-query-units/
Em vs. Rem: https://youtu.be/_-aDOAMmDHI
Using clamp() for fonts: https://youtu.be/U9VF-4euyRo
The ...
21 Replies
The majority of the time you wouldn’t set a fixed height on something. for example, If you had a card, the contents should decide the height, that way it makes it more flexible. If you absolutely must set a height on something, use min-height. Setting a height means that the element taking that property will not shrink nor grow causing overflow in some cases however min-height allows the element to grow past that defined point if needs be as it’s defining the smallest height that the element can be. Taking the card example again, a use case for this would be setting an image that you may have used in the card which is too long to have a min-height to prevent it from stretching the card vertically beyond your liking due to its default ratio.
Def avoid setting height with vh period. Avoid this or use new viewpoint units.
#2 no not if you need it for object fit or a good reason.
new viewport units like svh? so intead of 100vh it shold've been 100svh?
I'd still avoid them unless you have to use them, I'd use px or rem if I needed.
by that logic point 4 should be fine since content that won't fit would just overflow within the wrapper because of
overflowY: 'scroll'
wouldn't px be even worse? I don't think ive used px anywhere ever iirc.
I do like to believe that my table example is a good place where you must use fixed height. with a table with 500 items it would make it really difficult for the user to "skip" the table if they want to because they won't know where the table ends unless they jump around with the scroll bar. Now if you set a fixed height, the table has its own scrollbar so the user can just skip the entire table and move to the next content.Px is fine.... I don't know why people think it's not...
If you need it to change size with font use rem or ch otherwise I always use px
Yes that's a valid case
idk either but it was drilled in my head when I started web dev so just I ended up not using it, ever.
okay. thanks.
It's not never use height... It's just know what you're doing (most people set heights all over and it makes for a rigid.
Well I'd drill don't use vh other px
Vh/VW are cursed
As b1 said, that would be a valid case, what I would do in this case though is perhaps have a few items visible from the 500 item list with the others viewable via an 'expand’ or ‘view all’ button, this would give a cleaner look than a scroll bar in my opinion.
Kevin Powell
YouTube
The problems with viewport units
Conquering Responsive Layouts (free course): https://courses.kevinpowell.co/conquering-responsive-layouts
Join the Discord: https://kevinpowell.co/discord
Viewport units often feel like this cheat code that makes things so much easier when you first discover them, but they actually are problematic for a number of reasons, from creating horizon...
Kevin made this for me so I didn't have to rant*, but I still prefer the 100% for me fall back
bruh that is exactly what I do.
But yet you don't use px 😆
People form some really weird habits "best practices" but I'll never get avoiding px or media queries
hmmmm. basically virtualization of sorts. that's a great idea. I might just do that although it's marginally more CSs than setting scroll on y axis.
thanks
No worries, and it’s not too much more css either which is quite good, just from visualising it, I’d wrap the the remaining content in a
display: none; div which changes to display: block; via interaction with the extend button. Or if you want to have it smoothly animate I’d use a grid with a column height of 0 transitioning to auto as you can’t use transition with display: none;.just thought about it today but all this stuff also apply to
grid-template-rows right? since technically it's also setting a height.At the end of the day, a lot of it comes down to "it depends". Sometimes we need to define a height (or a row), but more often than not, we don't... 😅. If you have a good reason to do it, then by all means, go for it.
the issue is that it's still a bit hard for me to tell when i should or shouldn't define it. However, I do get the gist of it now.
Start by assuming you don't need to define one. If you end up putting one, you should be able to say "I added a height here because..." and explain the purpose of what it's there for.
So if i address the main problem that comes with setting fixed height i.e. where does the content go if set height is not enough for the content to fit, in that case I think I can justify setting height for a lot of cases.
also, I really appreciate the help. ♥️♥️
If you have a good reason to set a fixed height that is not adequate for the content, use overflow-y:scroll. You might possibly also use text-overflow: ellipsis if it is text content and you want to make the container expand upon hover/focus but restrict the height by default.
I don't understand why you think the problem of overflow justifies setting a height. It is a good reason to NOT set a height.