-
Notifications
You must be signed in to change notification settings - Fork 642
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-sizing][css-overflow][css-flexbox] Ability to control the sizing of the overflown content area #8725
Comments
The other items work as desired thanks to So you should be able to just add The only problem is that browsers still treat Also, consider |
The problem is not to handle things on the children, but control this on the parent. If we would think of the elements as isolated components, then we need to be able to make the parent container not shrink children regardless of what styles are on them. We can achieve this with 2 wrappers — top one with the overflow, and the one inside with flex, but we cannot achieve this with only one wrapper — this is the problem.
Can you elaborate? I've tried it on the
The column case is what I actually have in practice, in the product code where we stumbled upon this :) And, lastly, even if all children would not get shrunk (see the case where we add the |
It's the children who opt out of the default behavior by becoming scroll containers, so it's up to them to mitigate the negative effects.
https://software.hixie.ch/utilities/js/live-dom-viewer/saved/11533 Try Firefox. It seems Chrome has a bug.
I don't get it, why can you set
That's by design, you want |
This is not really applicable to some of the real-world use-cases, where different teams can work on different components, and a design system needs to provide a component that is resilient and can accommodate whatever is thrown into it — in this case the component would need to be split in two elements. So, the limitation of CSS leads to a bloated HTML.
See above — a component would not know what exactly would be placed into it, and the child won't know in which container it would be placed. We could argue, that in that case the component shouldn't have the
Oh, interesting! Safari has the same bug, so I would need to look into if it exists in their bug trackers.
TIL, though, a bit sad that it works only in Firefox for now. And, maybe you know — is it intended not to work with |
It works with
So |
Ah, nice, the fallback alignment sounds good. Can't wait for all of that to be available — it + My opinion — almost every time there is something that makes sense to specified as Edit: To add to the above — another reason why |
I guess |
Hmm, yes, I imagine that in that case it would need to be “auto” which computes to the parent's |
I did recently stumbled upon some weirdness regarding how flex and overflow interact.
I could not find an issue that would talk about it, and couldn't find the exact place in the specs that describe this interaction, so would be helpful for any directions!
Disclaimer: this might be also the case for
display: grid
, I did not thoroughly tested anything other thandisplay: flex
for now.References:
The problem:
When we have a container that has both
display: flex
and a non-visible
overflow
(my exact case was withoverflow: auto
), we do not have any control on how the inner content box of the overflowing container is sized, resulting in content always shrinking up to the items' respective min intrinsic sizes:Screen.Recording.2023-04-14.at.21.19.44.mov
What I want to have, achivable, for example, if we would instead move the flex container inside the container with the
overflow
— we get control over how it would behave viamin-width
orheight
: the container is sized to fit all the items:Screen.Recording.2023-04-14.at.21.20.18.mov
My proposal:
Current workarounds:
.flex > * { flex-shrink: 0; }
— kinda works, but only for thestart
value of thejustify-content
property, otherwise things behave not in a desired way.The text was updated successfully, but these errors were encountered: