Weird min-width: max-content behavior (jsfiddle)
Can someone explain to me what's happening in this fiddle? https://jsfiddle.net/th147dmf/53/
This is a simplified version of something that is happening in my actual app.
If you comment out the
width: 1px the overflow behavior is ruined, even though the 1px width doesn't seem to be used.
The max-width: 100% doesn't change the behavior either way. even though it seems like it should.
Can someone help me understand whats going on here?Edit fiddle - JSFiddle - Code Playground
Test your JavaScript, CSS, HTML or CoffeeScript online with JSFiddle code editor.
67 Replies
After a little more experimenting I noticed that none of the fiddle can be simplified even more so that it doesn't do the line clamping my app does: https://jsfiddle.net/th147dmf/72/
Edit fiddle - JSFiddle - Code Playground
Test your JavaScript, CSS, HTML or CoffeeScript online with JSFiddle code editor.
i guess my bigger question though is "how SHOULD i be doing this?"
what are you trying to achieve in the first place?
i want the behavior you get when you add the width: 1px
but i want to understand why that works or if its actually terrible (like it seems) and why max-width: 100% didnt work
just remove the
on the .wrapper
i need that for other things in my layout
eh?
so the fiddle is a simplified version of this problematic layout in my app
the layout looks like this
and the part that the fiddle represents is the list of options on the left
when i remove the hard-coded width i get this:
the min-width: max-content is applied on the root div that holds all the tabs and i want it to stay the same width as you shift between tabs
im sorry, thats poorly stated. i want the root div for the left side of the UI to not force any of its children to shrink
i want them to be as wide as possible until they hit the max-width that i set
assuming the .wrapper in your example is that column why are you setting a min-width instead of a max-width then?
as i understand it you want the width of that column to always be the same right?
im sorry. i did a bad job explaining it
the column needs to be responsive
but i want it to take up as much room as possible up to a max-width that i set and i dont want any of the children to overflow it horizontally
thats basically all of it
so my idea was to set the max-width the way i wanted it and then use min-width: max-content to make sure the children didnt overflow
maybe
?
on which div?
on the wrapper?
and no styles on the inner
with that the wrapper will always be as small as possible but never larger than the parent which is the column
or maybe i still don't understand haha
whats the difference between min, max and fit then?
that worked
nice
but idky
so min-width says this element may never be smaller than the set width
max-width says this element may never be larger than the set width
those are just constraints for when your normal width attribute is dynamically set eg. 100% or something
no im sorry
min-content, max-content, fit-content
oh sorry
this is a great article:
https://blog.logrocket.com/understanding-min-content-max-content-fit-content-css/
Ibadehin Mojeed
LogRocket Blog
Understanding min-content, max-content, and fit-content in CSS - Lo...
Learn about the fit-content, min-content, and max-content.In keyword values in CSS and how to use them in real-world projects.
ill take a look
min-content:
According to the W3C specifications, the min-content is the smallest size a box can take without overflowing its content.
max-content:
According to W3C specifications, max-content represents a box’s ideal size in a given axis when given infinite available space.
fit-content:
Depending on the size of a container element, when applying fit-content to a box element within the container, the box either uses the max-content size, the min-content size, or the available container as its ideal size.
these are the important parts
ok..... im gunna need to read more about this. but i have a meeting right now
thanks
no problem
ok so that makes sense for what fit-content is
but min/max-width: fit-content now seems really weird to do
but its in tailwind
and they usually try to push people away from bad practices
so im still confused
but for now this is solving the problem
so tyvm
i think there is an easier way to architect this with just flexbox and maybe grid for the whole layout but i assume you don’t want to refactor everything 😂
sorry. back from meetings / lunch
i'd really love to learn it
for me the big issue in my app that kinda prevented a lot of things was scrollbar placement
like theres tons of demos of stuff online that look like this: https://n27v5.csb.app/
but if you want the scrollbar to not be in a really dumb place i havent fond any way to do some of this stuff but with at least some position: absolutes
also the layout COULD be a lot simpler if i wasnt also trying to make my code maintainable and have reusable components
but it seems really challenging to build a component that you can use in different places when the parent might be display: flex, it might be display: grid or anything else
not to mention the fact that css only really has good support for screen-based media queries so i cant ebven make descisions based on the size that a given component actually is
idk. it seems like impossible to build good modular css with how everything in css is so based on what its parent / children are doing
i totally agree you're basically trying to build your own component library which can be very challenging to get right
although there is already a draft for container queries it's far from usable
i think the two most common methods for this problem are:
(0. components should only contain visual (not dimensional or positional) styles maybe defaults at most)
1. allow passing of additional classes to the component (so dimensions and position can be set from context)
2. variants (render different component based on some prop
not sure what you mean with that scrollbar problem...
if you have an example i can have a look
0) so my problem with that is that if the component needs to work at every size then every component needs to be completely responsive, which seems to necessarily reasonable or like a good use of time
for instance, if i have a card it doesnt make sense for me to make that card work at full width of the screen if its never designed to be bigger than the width of a phone screen
and even if i did want to make all of my components super responsive i still only get to make them responsive based on the width of the screen because, as you said, its 2023 and people are just now considering the idea of container queries
my current solution for this is that my components have variants that work at different approximate ranges of widths
so for instance the row of options weve been talking about has a 'thin' variant which looks like this:
but the parent layout decides which variant it should use
which i guess is exactly what you meant by (2)
but even by doing variants, theyre only approximate. they dont work for every situation the parent might decide to put them in
so i end up with a lot of wrapper divs that just try to kind of isolate the component into some kind of predictable world that it can render itself in
which kinda brings me to the scrollbar issue
because i end up doing a lot of this 'div resetting' i end up with scrollbars in weird spots
because some of the components had to reset overflow
i dont have a great easy example of this cause ive worked around it in all the spots i know about
i don‘t think you should optimize every component for full page width but have the option to override the flex behavior the dimensions and self positioning from outside of the component
variants should not change positional or dimensional styles they should change things like column layout different colors etc.
yeah but thats really hard cause theres like 40 ways the parent can influence the childs size, right?
in general you should not abstract every part of your ui into a component only if it makes sense
what's the problem with just:
for example
i get that but im just saying it annoys me because it seems like that advice only makes sense because css has a billion ways to do everything
and i have ^ in a lot of my components but theres nothing stopping me in there from only changing the actual things i should be able to touch
like i want people to be able to specify width, but if i give them classname they can screw with the whole compoent itself
theres no way i can make sure the caller is being responsible like that
oh yeah that's the problem
then just allow an options prop to be passed to the component which only allows like width height etc and merge it into the className inside the component?
if that makes sense
kinda except like
from a ts perspective that seems like a nightmare
cuase i need to be able to accept like pixel widths, and a bunch of special values
parse that into classes
eww
thought you were using tailwind
i am
how does that help?
it doesn't i am just confused why you're using pixel widths and special values then
well 1) im using tw for 95% of things
but my app has customizable themes which i cant use tailwind for
sorry 1 sec
almost done this thing
fair enough
ok back
2) even if i am using tailwind for everything
so my options are
a) provide a className parameter
but i only want to be able to specify classes that will effect the sizing
so i need a giant ts enum of all the
w-*, min-w-* max-w-*, values
and even then that doesnt really cover it cause i can do w-[203px]
or b) i allow them to specify a width: number | 'min-content' | 'fit-content', etc
but then i need to use a style object which means my app ends up being even less tailwind-y than i wanted it to be and i have 2 systems for styling almost everything
cause i cant do w-${props.height} without breaking tw
or c) allow className: string and just hope the parent doesnt screw with things too badly
which is my current strategyor something like this?
that's not a good idea
width this it doesn't get too complicated but if you want to have it to be more restrictive you could use my type
is that a valid ts type?
you can bake regexes into the types like that?
yeah i know. im just listing all the options i can think of
idk. but theres other problems in there too. like even with your SizeClasses type (if it does work)
1, i cant specify a min and max width
i cant specify flex-1 or any other flex prop
also there are other props that are even more conviluted like how i can have a component that i really always want to be display: flex, but the parent wants it to be display:none
improved it a bit
yes
it's not regex but yes
Not quite regex. But you more what I mean
why can't you
just add it to the union
I guess maybe it’s possible if you can do that. But that type seems like it would get crazy if I tried to list out all the properties a parent can specify that affect size
at some point you have to make a decision
either allow everything
Idk. Right now my mind is just blown that you can specify types like that
or restrict it
there's no way it will magically know what to allow and what not
haha
cool right?
I know but none of this seems like “the right way” TM
It seems very complicated and manual and if tailwind wanted me to be doing stuff like this they would have included those types in some package for me to use
normally you don't restrict that access
i'am just saying like keep it stupid simple
over abstraction results in over complication
That’s what I’m doing now but it feels like there should be a solution for this
i don't know if there is a problem tbh
i think you're trying to build a fully autonomous component library as a side effect
which companies like shopify do to keep a consistent look throughout their applications
but is mostly overkill for projects at normal scale
Kinda but I feel like I’m really just trying to draw reasonable boundaries between parents and children
Maybe that’s asking too much
maybe someone else has another opinion on this...
Maybe. I gotta sleep now. Thanks for the chat
Have a good night
cya
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
this is so cool
thought they were still working on them
maybe that's the solution to your problem then
Hmmm. Thanks for the link. I thought they weren’t going to be supported for like another 6 months