Absolutely Positioned Flexbox Doesn't Expand to Fit Contents

Absolutely positioned container not expanding width to fit flexbox content

Your code works in Edge.

It doesn't work in Firefox and Chrome.

This appears to be a bug with flex-basis in those browsers.

There's a simple workaround: Instead of flex-basis, use width.

.parent {  position: absolute;  padding: 10px;  background: red;}
.flex {  display: flex;}
.flex-child {  /* flex: 1 0 100px; */
  width: 100px;  flex-grow: 1;  flex-shrink: 0;
  background: #EEE;  border: 1px solid black;  white-space: nowrap;  overflow: hidden;}

<div class="parent">  <div class="flex">    <div class="flex-child">One</div>    <div class="flex-child">Two</div>    <div class="flex-child">Three (really really long)</div>    <div class="flex-child">Four</div>  </div></div>

Flexbox container with position absolute doesn't fit content width in IE

The problem is not related to flexbox.

It's an issue of absolute positioning rendering variations among browsers.

When you set position: relative on an element it sets the bounding box for descendants with position: absolute.

In Chrome, the absolutely-positioned descendants are permitted to overflow the bounding box.

In IE11, they are not. The absolutely-positioned elements are cut-off once the limit of the bounding box is reached.

One workaround would be to remove position: relative from the container. Now the absolutely-positioned submenu has a larger bounding box (based on the nearest positioned ancestor or, if none exist, the initial containing block (i.e., the viewport)).

ul li.menu-metier {
   /* position: relative; */
   padding-bottom: 25px;
}

revised demo

Another workaround would be to adjust the right offset to accommodate the content.

ul.sub-menu {
    right: -600px;
}

revised demo

You can also try setting a width.

None of these options are pretty. But then again, we're dealing with IE.

You may find other workarounds via search.

Does 'position: absolute' conflict with Flexbox?

No, absolutely positioning does not conflict with flex containers. Making an element be a flex container only affects its inner layout model, that is, the way in which its contents are laid out. Positioning affects the element itself, and can alter its outer role for flow layout.

That means that

If you add absolute positioning to an element with display: inline-flex, it will become block-level (like display: flex), but will still generate a flex formatting context.
If you add absolute positioning to an element with display: flex, it will be sized using the shrink-to-fit algorithm (typical of inline-level containers) instead of the fill-available one.

That said, absolutely positioning conflicts with flex children.

As it is out-of-flow, an absolutely-positioned child of a flex
container does not participate in flex layout.

absolute positioned parent with a flex growing child not inheriting width

You have to set a width for the parent. That is because whenever an element is positioned absolutely the width and height is automatically set to auto. So in your case the child's flex-wrap: wrap will cause an overflow unless a width is specified for the absolutely positioned parent.

.parent {
  color: white;
  background: blue;
  margin: auto;
  padding: 1em;
  position: absolute;
  left: 10px;
  top: 100px;
  width: calc(100% - 20px); /* can be any value */
}
.child {
  background-color: green;
  display: flex;
  height: 100px;
  flex-direction: column;
  flex-wrap: wrap;
  margin: 0;
}

Using flexbox with absolute position children?

The absolutely positioned element innerContainer is not properly filling up the space of its container divA - instead of using width: inherit and height: inherit you can use 100% and also settop and left to zero.

Optionally I've added flex-shrink: 0 on divB so that it doesn't shrink when the window height is small - see demo below:

body {  margin: 0;}.wrapper {  height: 100vh;  display: flex;  flex-direction: column;}
#divA {  position: relative;  flex-grow: 1; /* occupy remaining space */  background: lightblue;}
#divB {  flex-shrink: 0; /* do not shrink */  background: lightgreen;  /* center horizontally and place buttons vertically */  display: flex;  flex-direction: column;  align-items: center;}
#innerContainer {  position: absolute;  top: 0;  left: 0;  width: 100%;  height: 100%;}
#centeredIcon {  width: 2em;  height: 3em;  left: 50%;  top: 50%;  transform: translate(-50%, -50%);  position: absolute;  z-index: 1;}

<div class="wrapper">  <div id="divA">    <div id="innerContainer"></div>    <img id="centeredIcon" src="https://via.placeholder.com/200" />  </div>  <div id="divB">    <button>button 1</button>    <button>button 2</button>  </div></div>

When flexbox items wrap in column mode, container does not grow its width

The Problem

This looks like a fundamental deficiency in flex layout.

A flex container in column-direction will not expand to accommodate additional columns. (This is not a problem in flex-direction: row.)

This question has been asked many times (see list below), with no clean answers in CSS.

It's hard to pin this as a bug because the problem occurs across all major browsers. But it does raise the question:

How is it possible that all major browsers got the flex container to
expand on wrap in row-direction but not in column-direction?

You would think at least one of them would get it right. I can only speculate on the reason. Maybe it was a technically difficult implementation and was shelved for this iteration.

UPDATE: The issue appears to be resolved in Edge v16.

Illustration of the Problem

The OP created a useful demo illustrating the problem. I'm copying it here: http://jsfiddle.net/nwccdwLw/1/

Workaround Options

Hacky solutions from the Stack Overflow community:

"It seems this issue cannot be solved only with CSS, so I propose you a JQuery solution."
"It's curious that most browsers haven't implemented column flex containers correctly, but the support for writing modes is reasonably good. Therefore, you can use a row flex container with a vertical writing mode."

More Analysis

Chromium Bug Report
Mark Amery's answer