In the example code below I have a complex structure of nested containers which represents blue boxes in flex containers. The whole thing is nested ina scroll container.
The issue is that the blue containers are squished on Safari:
There are lots of examples here on SO which concern such an issue. The accepted solution in most of them is to add flex-shrink: 0;
In my case, this would mean adding flex-shrink to the .stackchild and #StackChild. This is a styled react component but for the sake of the example, the random CSS classes are replaced with a class and id just to be distinguished.
When I add flex-shrink: 0 to the stackchild I get another layout issue on all browsers:
Tbh I'm not quite sure what's going on here ...
Any idea why does the shrink prop break the layout in this way? And how to solve this so that all browsers are happy?
Code example here: https://codepen.io/pollx/pen/oNbmEoE
Setting a min height alongside stack child appears to work.
https://github.com/philipwalton/flexbugs
.stackchild {
display: inline-flex;
margin-top: calc(16px / 2);
margin-bottom: calc(16px / 2);
min-height: 0;
flex-shrink: 0;
}
https://codepen.io/jspenc/pen/rNxEOme
Related
I have an application with layers containing the following properties related to layout, each line is a layer. I've added relevant properties to positioning/display.
1. display: grid
2. display: flex
3. position: fixed, 100vh
4. display: flex, overflow: hidden
5. display: flex
6. display: flex
--------------- Splits into two columns, each one should scroll independently
7. display: flex, flex-grow: 1, overflow-y: scroll
8. display: flex, flex-grow: 1
The issue I'm seeing is that a few users are unable to scroll to the bottom of the children starting after the point where it splits into two columns. They can scroll partially, but about 30% of the remainder gets stuck off-screen.
I have been searching through chrome updates/issues related to the min-height: auto changes and cannot nail down the cause. I am completely unable to reproduce and am having a very hard time determining differences in the users' setup and my own.
Are there any known issue with nested flexboxes that would lead to one of the children be unable to scroll fully for some chrome users?
All theories so far have been relating to nesting of flexboxes causing a child at some level to not be contained, thus the hidden overflow of scrolling content.
I could use a new lead on any similar issues/workarounds/anything! Thanks!
First thing: I'm not a frontend programmer, but sometimes the only way is become one.
So I was thinking about behavior of flex or flexbox. Probably the way I use it is bad, if so, please let me know. Thanks.
To the problem:
I tried to write basic layout using flexbox, but I found a problem.
Honestly I don't know if it is a bug or my expectations are too high, but I expect same behavior from these cases below.
https://jsfiddle.net/bargl_vojtech/upvb1Lgk/7/
https://jsfiddle.net/bargl_vojtech/h7eokuua/1/
https://jsfiddle.net/bargl_vojtech/q0kegr8o/1/
They are similar, but if you look closer, you can see change in main and #inside-main in css and #wrapper in html
Simple info:
main - part of view
#main-header - header for content (example: fixed title)
#main-content - scrollbox
#inside-main - endless content
I expect second case to be just like first case in behavior, can someone tell me why it is not same?
Thanks for reply.
My expectation: main has flex: 1, so it should be resize to rest of parent size, but somehow #inside-main tells #main-content to resize itself (because it expected in most cases... bigger inner div should resize smaller parent div to same size), and because #main-content is now bigger than its parent it resize him, and so on, but should not this be ignored by overflow: hidden/scroll?
Flex items, by default, cannot shrink below the size of their content. That's why your content element is overflowing the container.
The initial setting on flex items is min-height: auto (in column container) and min-width: auto (in row container).
To override these defaults use min-height: 0, min-width: 0, or overflow with any value except visible.
Add this to your code:
main {
background-color: red;
flex: 1;
overflow-y: auto; /* NEW */
}
For a complete explanation see these posts:
Why doesn't flex item shrink past content size?
min-width rendering differently in flex-direction: row and flex-direction: column
I'm trying to add padding to an element inside a display:flex element. When the padding is defined as a percent, it doesn't display in Firefox, though it does when defined in px. Both cases work as expected in Chrome.
div {
background: #233540;
}
div > div {
color: #80A1B6;
}
.parent {
display: flex;
}
.padded {
padding-bottom: 10%;
}
<div class="parent">
<div class="padded">
asdf
</div>
</div>
Chrome:
Firefox:
Edit:
This may be because of Mozilla's decision to interpret vertical percentages with respect to the height of the parent container. Seems crazy to me. https://bugzilla.mozilla.org/show_bug.cgi?id=851379
Edit 2:
Yes, it appears that the spec actually defines vertical padding and margin as being resolved against the container's height, so perhaps Chrome is the one not honoring the spec?
https://drafts.csswg.org/css-flexbox/#item-margins
See https://lists.w3.org/Archives/Public/www-style/2015Sep/0038.html
Grid/Flex Percentages
The group tried to work through how vertical percentage margins
and paddings are defined.
Note: Top and bottom margins in CSS have traditionally
resolved against the containing block width instead of its
height, which has some useful effects but is generally
surprising. Existing layout modes must of course continue
to do so.
Previous group resolution had been for option 2 (below), but
Google felt they had new information regarding abspos
behavior that merited reconsideration.
The discussion came down to three potential solutions:
Option 1: Always resolve percents against the width.
Option 2: Grid and flex resolve against height, and
abspos items always resolve against the width.
Option 3: Grid and flex, including their abspos items,
resolve against the height. Abspos elsewhere
continue to resolve against the width.
In a straw poll the group was pretty evenly divided between
options 1 and 3.
Microsoft would object to option 1 and Google to option 3,
so the discussion reached an impasse and will be continued
privately during the F2F in hopes of reaching a conclusion.
See https://lists.w3.org/Archives/Public/www-style/2015Sep/0113.html,
Flexbox % Follow-Up
[...] there was still no conclusion.
The current Flexbox spec warns about this:
Percentage margins and paddings on flex items can be resolved
against either:
their own axis (left/right percentages resolve against width, top/bottom resolve against height)
the inline axis (left/right/top/bottom percentages all resolve against width)
A User Agent must choose one of these two behaviors.
Note: This variance sucks, but it accurately captures the current
state of the world (no consensus among implementations, and no
consensus within the CSSWG). It is the CSSWG’s intention that browsers
will converge on one of the behaviors, at which time the spec will be
amended to require that.
Authors should avoid using percentages in paddings or margins on flex items entirely, as they will get different behavior in
different browsers.
However, more recently the CSS WG resolved (with some controversy):
Both flexbox and grid items top and bottom margin and padding percent resolves against the available inline direction.
See the updated editor's draft.
For me this does the trick: adding display: table to the div. Don't know if that causes other problems though.
div {
background: #233540;
display: table;
}
div > div {
color: #80A1B6;
}
.parent {
display: flex;
}
.padded {
padding-bottom: 10%;
}
<div class="parent">
<div class="padded">
asdf
</div>
</div>
Try this:
.padded {
padding-bottom: 10vw;
}
The current draft spec says
Percentage margins and paddings on flex items, like those on block boxes, are resolved against the inline size of their containing block, e.g. left/right/top/bottom percentages all resolve against their containing block’s width in horizontal writing modes.
So, Firefox is now incorrect according to the latest draft.
CSSWG discussion: https://github.com/w3c/csswg-drafts/issues/2085
Spec changelog reference: https://drafts.csswg.org/css-flexbox/#change-2017-margin-padding-percent
Current spec on flex item margins: https://drafts.csswg.org/css-flexbox/#item-margins
I have created a site that uses flexboxes and it is working in most parts, but I have come across an issue with something.
http://kudos.topspindigital.com/#/table-tennis
If you look at the page, the top right panel is cutting off text. This is because the panels below are set to be 1.5 x the height of the one above.
This works fine for this page:
http://kudos.topspindigital.com/#/archery
but as you can see, anything that has 2 lines of text for the header brings the content down.
So my question is 2 things.
Is there a way I can tell my panels to grow to 1.5 x height of the top but allow the top to expand (and let the children shrink).
I tried doing this:
.flex-double {
flex-grow: 1.5;
flex-shrink: 1;
flex-basis: 0;
}
but it had no effect.
Is there a way of forcing the top panel to overflow and get the bottom panels to fill the remaining height?
ok, so I was having problems with this, so I made a codepen with my CSS and tried to solve the issue myself.
Here is the codepen:
http://codepen.io/r3plica/pen/qdPeYp
I have managed to fix the issue by creating a new class called .flex-auto which replaced .flex-double.
It looks like this:
.flex-auto {
flex-grow: 0;
flex-shrink: 1;
flex-basis: auto;
}
Applying this to the item I want to be just enough height (in this case the top panel) will set it to the correct height and the second panel will then take up the rest of the space.
Yes. Just set your desired flex factor:
flex: 1.5;
And then the Flexbox module changed the initial value of min-height:
4.5 Implied Minimum Size of Flex Items
To provide a more reasonable default minimum size for flex items,
this specification introduces a new auto value as the initial
value of the min-width and min-height properties defined in
CSS 2.1.
So the min-height will compute to the content size, which is exactly what you want.
You can see this behavior on Firefox, but Chrome hasn't implemented it yet.
If you want it to overflow, just unset the min-height and add overflow to the appropriate element:
.row {
min-height: 0;
}
.panel-gray {
overflow: auto;
}
As the title suggests, I have two stacking <div>s.
They are placed in an absolutely positioned container that covers the whole page. Basically, those 2 <div>s, taken together, should also cover the whole space of the containier.
Another important aspect is that these <div>s have dynamic content. The bottom one can have a lot of content, so an overflow: auto rule is required. The top one can also have dynamic content, but it's not really expected to grow out of control. Thus, I don't want to cut the overflow.
The main question is: How can the top one affect the other one's height without the risk of overlapping? (I prefer a CSS only solution, or something that wouldn't imply JS pixel values computations)
Here are two images that describe the best what I'm trying to achieve:
"initial state"
a state with some more data in the top div
Here is also a JSfiddle for convenience: http://jsfiddle.net/60qan4t6/
This is the kind of situation that display:flex handles extremely well. Update to your fiddle:
http://jsfiddle.net/60qan4t6/1/
Note, I quickly wrote this, so it's missing browser prefixes to support some browsers, but the fiddle should work in Chrome just fine.
Be sure to see check browser support for flexbox here:
http://caniuse.com/#feat=flexbox
If it's acceptable to set height to div's you can use such an example
.top-area {
background: red;
overflow: hidden;
height: 40%;
}
.bottom-area {
overflow: auto;
height: 60%;
}
http://jsfiddle.net/xqh2vw2g/