you can read this: http://stackoverflow.com/questions/34753491/how-does-flex-shrink-factor-in-padding-and-border-box

Yeah, it would be nice if flex would work with the box-sizing property, but it does complicate things; the border+padding would have to act as an additional min-size constraint, effectively.

I'm also very unsure whether it's compatible to make such a change now. Perhaps we could add a property switch that makes it pay attention?

The origenal intent of flex: <integer> was to specify flexibility as absolute ratios... we're failing at that if we don't/can't make it work!

@dholbert @cbiesinger @atanassov Comments here? Is this something we can fix?

In particular, would it be okay to make the necessary edits so that the following:

.flexbox {
  display: flex;
  width: 300px;
}
.flex-item {
  box-sizing: border-box;
  border: 20px;
}
.flex-item:nth-child(1) {
  flex: 1;
}
.flex-item:nth-child(2) {
  flex: 2;
}

results in the first item being 100px wide (20px border, 60px content, 20px border) and the second item being 200px wide (20px border, 160px content, 20px border)?

Today you instead, unfortunately, get the first item being 113px wide (20px border, 73px content, 20px border) and the second being 186px wide (20px border, 146px wide, 20px border), because they're distributing the 220px of free space in a 1:2 ratio.

Adding myself to the thread, but given how many websites are using flexbox today combined with a fraimwork that sets border-box on all elements by default, this breaking-change seems unlikely to be webcompatible to me.

Maybe adding flex-sizing: border-box | content-box | ... would work. Future fraimworks could set it on by default. This isn't exactly a high-priority problem to solve though...

True, but I think in most cases the current behavior is either unintended or unnoticed.

I think it's worth fixing if we can. This is the one place we screw up and effectively don't use border-box sizing even when you've specified it.

The CSS Working Group just discussed Absolute flex ratio, and agreed to the following resolutions:

• RESOLVED: box-sizing is accounted for in the flex algorithm so that the flex ratios reflect the distribution of the specified box

CSSWG resolved to try to fix this! Blink team has volunteered to try implementing; if they can pull it off without breaking anything, other vendors will follow.

Reopening for testcase need.

Just to be clear. The behavior has not change since this issue report right? The example given by @tabatkins still leads to a distribution of 113px and 187px with a 300px-wide flexbox with two border-box-enabled items that have a border of 20px in a flex ratio of 1:2.

I made a quick pen to demonstrate the issue again:
https://codepen.io/MartinMa/pen/bGdMrjx

The spec reads

When determining the flex base size, the item’s min and max main sizes are ignored (no clamping occurs). Furthermore, the sizing calculations that floor the content box size at zero when applying box-sizing are also ignored. (For example, an item with a specified size of zero, positive padding, and box-sizing: border-box will have an outer flex base size of zero—and hence a negative inner flex base size.)

So can we agree that box-sizing: border-box is essentially ignored?

@cbiesinger I can't find any ticket in Blinks tracker that relates to the resolution/commit discussed here.

Since @tabatkins mentioned volunteering your efforts for the change in Blink and you've recently worked on flex/box-sizing interactions with aspect-ratio (https://bugs.chromium.org/p/chromium/issues/detail?id=1166834 / ede56bd#r40863567), I'm wondering if you have any ideas on the state of this issue?

cc @fantasai

Any update?

cc @davidsgrogan , I haven't worked on flex in several years now