Section 4.2 of the [css-flexbox] has the same wording, probably for the same reason. Maybe if the issue gets resolved, it should be resolved in both places?

@SelenIT Absolutely. Doing otherwise would be quite objectionable imho!

We've taken quite a bit of care to keep flexbox and grid aligned as much as we can and this is great. As far as this issue is concerned I'm not sure this is a hard requirement. In fact, this is one of the places where the two modules differ.

When we introduced grid it was our intention to provide two dimensional, symmetric layout behavior as much as possible. Since then the spec moved mostly in terms of syntax, thus, this behavior principle is something we still feel strong about.

Flexbox on the other hand is a single dimensional space distribution, thus keeping everything symmetric is not that necessary.

These were our hopes and intentions but reality is different. After releasing grid in all current browsers we are fragmented between webkit and blink supporting non-symmetric % resolution while gecko and edge have a symmetric resolution. At the end of the day this is pretty bad for interop and we already see some pages being broken due to this difference.

The following options should help us decide on a single, interoperable behavior.

1. Resolve flexbox % against inline axis (non-symmetric) and change grid to resolve all % in their own axis (symmetric)
2. Align with blink and webkit - both flexbox and grid to be asymmetric (resolve margins and padding % in their inline axis)
3. Align with gecko and edge - both flexbox and grid are symmetric (resolve all % in their own axis)

In addition to the above options, I'd like to add, since the stated reasoning by @tabatkins /Google of keeping this asymmetric was to allow the percentage padding hack for aspect ratio to work. I would like to submit that we should actually solve this problem in CSS. The hack alone proves developer need of this and I think a V1 shouldn't need to be overly complicated. This may allow us to have the best of both worlds and keep grid or flex (based on the above resolution) symmetric while providing authors with an actual aspect ratio solution. I have a few ideas in this space and I know others probably do as well.

I'd like it interoperable, I don't think (with my author hat on) that I have a very strong opinion as to whether it should or should not be symmetric, or whether we need to keep grid and flexbox the same. I could write this up as a blog post though with examples and see if i can get some author feedback if that would be helpful?

I would love to solve the padding hack issue though anyway, and agree with @gregwhitworth that there is clear developer need to do so.

@rachelandrew getting a blog post out is an awesome idea! Let's see what the rest of the community thinks and if they care enough about it.

There have been several discussions about this topic in the past, I'm linking the last one I found just for reference: https://lists.w3.org/Archives/Public/www-style/2015Feb/0521.html

Regarding this issue there are some use counters in Chrome to measure the usage of percentage vertical padding and margins in flexbox:

• Percentage vertical padding: https://www.chromestatus.com/metrics/feature/timeline/popularity/955
• Percentage vertical margin: https://www.chromestatus.com/metrics/feature/timeline/popularity/956

I guess one question is to know if people are using it for the aspect ratio trick, and if so if we're planning to remove that possibility without having a good alternative. Probably @rachelandrew's post could help to gather valuable feedback on that topic.

Adding @cbiesinger to the loop as he participated in previous discussions about this topic and is the flexbox maintainer on Chrome.

The issue was indeed discussed in the past (around 2015) and I even proposed a feature that would allow authors to chose which sizing applies to a given layout container such as grid, flexbox or block (see the NYC f2f minutes ). The jsbin I used seems to be alive as well and the property suggested was box-percent-sizing: symmetric | asymmetric; just so it is closer to box-sizing.

The aspect ratio argument was discussed at that time too with the obvious questions of "if we really need it, why isn't there a dedicated property for it?" etc.

In addition to the above options, I'd like to add, since the stated reasoning by @tabatkins /Google of keeping this asymmetric was to allow the percentage padding hack for aspect ratio to work.

This isn't quite right. Our stated reason was that the aspect-ratio hack was the only significant case (that is, the only case that showed up in non-trivial numbers in our use-counters) for using % padding in the first place. Virtually nobody was using % padding for anything else at all.

Thus, there was no argument for making %s relative to each axis, besides a weak sense of theoretical purity ("what it should have been to start with"). And, since we can't change the behavior for block layout, that's directly clashing with the other theoretical-purity argument, that %s on padding should work the same in all display modes.

I agree that we should add an actual aspect-ratio feature; I have a (flawed) proposal for this in my blog from 2010. But that has no bearing on this issue; we'll still be stuck with the weird % behavior in block layout for compat reasons, and there's no strong argument for making other layout modes have different behavior than this.

Percentage vertical padding: https://www.chromestatus.com/metrics/feature/timeline/popularity/955
Percentage vertical margin: https://www.chromestatus.com/metrics/feature/timeline/popularity/956

Looking at your use counters it's clear that introducing grid raised the numbers immediately... seems like another great opportunity missed to rid the web of wacky patterns.

As to this being "theoretical purity" - you can make that argument for block and table layout where heights are results of widths. Before introducing grid however, we worked hard to make sure % values actually work.

% heights have nothing to do with width, let's not get sidetracked.

@tabatkins - the reference was to all % values. Heights do behave much better and agree that we shouldn't be pulling these in the discussion - wasn't my intention.

Hi,

I wrote a blog post about this issue back in 2015: http://www.radiumvinteractive.com/flexbox-percentage-margins-and-paddings/

I think my original suggested idea to add a new property would definitely be overkill, but the interop situation is definitely still confusing for authors like me.

I think there's still a preference to keep this symmetrical for actual use-cases, like similar features in native-app UI frameworks. Either way I agree with finding an actual solution to the hack use-case that doesn't involve polluting/abusing this feature.

Percentage vertical padding: https://www.chromestatus.com/metrics/feature/timeline/popularity/955
Percentage vertical margin: https://www.chromestatus.com/metrics/feature/timeline/popularity/956

Looking at your use counters it's clear that introducing grid raised the numbers immediately... seems like another great opportunity missed to rid the web of wacky patterns.

The big jump on the usage is related to a change on how counters are measure in Chromium to get more realistic values, so not directly related to Grid. See the note:

Note: on 2017-10-26 the underlying metrics were switched over to a newer collection system which is more accurate. This is also the reason for the abrupt spike around 2017-10-26.

The Working Group just discussed [css-flexbox][css-grid] Choose a single option for resolving padding and margin percent values of grid/flex items.

I wrote this up as a post on the CSS WG blog, also cross-posted to my blog. I'll tweet about it and see if we can get any author feedback.

(Posting my thoughts here as @rachelandrew asked on her blog.)

If I understand correctly, the question is how to resolve top/bottom margins and paddings. Left/right margins and paddings obviously resolve against width.

My first intuitive response was that it's most logical when margins and paddings resolve against their own axis. You could compare it to how other percentage values work: height: 50% obviously means "50% of the container height", not "50% of the container width".

However, thinking about this a bit longer, I cannot imagine why I would actually need a margin-bottom that is a percentage of the element's height. Would a designer ever say "If the editor enters more text in this area, I want it to have a bigger bottom margin"? I don't think that is very likely.

On the other hand, I come across fluid-width designs on a daily basis. Rachel's code pen uses fixed-width grid columns, but they might as well be 25% wide. I think it is very likely that a designer wants the column margins to scale with the column width, while keeping the margin bottom identical to the margin right.

Conclusion: I would choose to resolve top/bottom margins and paddings against width, because I think it has more practical use.

PS. Has it been considered to leave the choice to the programmer? Eg. introduce syntax like margin-bottom: 20%w and margin-bottom: 20%h?

Oooh margin-bottom: 20%w and margin-bottom: 20%h sounds like an awesome idea. It lets us have more fine tuned control over how we want the percentages calculated.

Making %w and %h actual generic unit types would also solve the aspect ratio issue. You could do something like height: 50%w to create a 2/1 ratio container :)

As for what % would equal in flex and grid, I'm not really sure :/

From a logical sense, I like the idea of basing it off the same axis. From a practical sense though, if I say padding: 10%; I would expect equal padding around all sides of the container :/

• their own axis (left/right percentages resolve against width, top/bottom resolve against height),

It makes sense (user perspective) over the second option.

As per the spec, currently sucks rather a lot.

%s on padding should work the same in all display modes.

This is the most important factor for me as a web developer. I vote for asymmetric, keep the behaviour of percentage heights in grid and flex to be the same as block mode.

The ability to get width-relative vertical margins already exists: it's block formatting. If you really need this, you can always get it by using a block wrapper or ::before/::after pseudo-elements as block placeholders. I guess this is what developers already have to do for this because of this "variance" in the implementations.

The ability to get height-relative vertical margins didn't exist at all in CSS before flex/grid layout (except absolute positioning which is a very different case). This ability also looks very natural to flex/grid items where we have different options to align them vertically relatively to the row/line height, which is not the common case for block layout. If we drop this ability, we would lose it forever and would have to resort to absolute positioning when the need for it occurs.

Considering this and in order to keep things simple (as @CyberAP said), I'd prefer @atanassov's option 3 (symmetric resolution for both Grid and Flexbox by deafult). And the ability to explicitly specify width or height percentages (the exact syntax TBD) would be the extremely useful addition too, of course.

The Working Group just discussed Issue #2085.

As I stated during the WG discussion, our intention in Edge is to implement the blink and webkit behavior, i.e. resolve padding/margin-top/bottom values against the available inline size (width). Our decision is driven solely due to the compatibility issues experienced by our users.

@dholbert @MatsPalmgren it would be good to hear from gecko on this issue since your implementation will be the only one that has the symmetric behavior.

No discussion about %h and %w units?

There are quite a lot of people in favour of having units like that.

@Dan503 this is a separate feature request that isn't specific to flex or grid item vertical padding, hence the lack of discussion. We're not opposed to it, simply have to fork and continue as a separate topic at [css-values] or [css-sizing].

@dpawson "Blink" is the name of the engine which is used by Chrome, Chromium, and Opera. It does not mean the HTML <blink> tag.

What @atanassov meant is that the Edge team is choosing to use Chrome's and Safari's behavior, which means Firefox is the only major browser with a different behavior.

@dholbert @MatsPalmgren it would be good to hear from gecko on this issue since your implementation will be the only one that has the symmetric behavior.

We're going to change as well (away from the symmetric behavior, to the inline-axis behavior). (I'm speaking for Mats based on his thoughts at the end of https://bugzilla.mozilla.org/show_bug.cgi?id=958714#c41 , & given that Edge is now changing.)

I've posted patches in https://bugzilla.mozilla.org/show_bug.cgi?id=958714 to make the change in Firefox.

@atanassov @dholbert @MatsPalmgren I don't understand why you chose to go blink and webkit behavior if the almost whole part of us that commented here prefer that axis resolve against their own? So our opinion count nothing?

@malix0 the feedback here is more mixed than you're representing. And no one's particularly happy with this result.

There apparently is enough web content that depends on the blink/webkit behavior that the other engines have to match it. We still might be able to figure out some other way of supporting grid layouts with entirely independent axis measurements, but it can't be the default.

Agenda+ since we didn't actually resolve yet.

@astearns, may be this is necessary to not break things, but we developer need a logical way to do things and to me this don't looks really logical. But now it is. I hope so that something like %w and %h will be supported. I don't think this will be much difficult because Edge (@atanassov) and Firefox (@dholbert) developers just changed things in a day

Just in case, about the ratio problem...

In Sciter I've introduced width and height functions.

height: width(75%);
line-height: height(100%);
width: height(50%)

benefits are clear I think: no need for special units - the feature can be added without changing existing grammar definitions and parsers.

The Working Group just discussed [css-flexbox][css-grid] Choose a single option for resolving padding and margin percent values of grid/flex items, and agreed to the following resolutions:

• RESOLVED: Both flexbox and grid items top and bottom margin and padding percent resolves against the available inline direction.