New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 13 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Feb 2018
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

issue 79180

Sign in to add a comment

Issue 229568: for flex/grid items, percent margins and paddings should resolve against their respective dimension

Reported by, Apr 9 2013 Project Member

Issue description

Migrated from WebKit Bugzilla:
Originally reported 2013-03-28 10:49 PST by Tony Chang (

Normally, margin top and margin bottom resolve against the width of the containing block, but the working group decided that for flex items, we should resolve against the height of the containing block.

This should be an easy change to make. See RenderFlexibleBox::computeChildMarginValue.

Comment 1 by, May 20 2013

Project Member
Labels: -WebKit-ID-113519 WebKit-ID-113519-NEW

Comment 2 by, Aug 22 2013

 Issue 275327  has been merged into this issue.

Comment 3 by, Jan 17 2014

 Issue 333533  has been merged into this issue.

Comment 4 by, Jan 17 2014

 Issue 333533  has been merged into this issue.

Comment 5 by, Mar 3 2014

What's the status of this? It's seriously unexpected that Firefox & Chrome can have completely incompatible meaning of sth so basic as percent paddings/margins. Our team has just hit the issue hard, seeing layout completely broken. :(

The longer it's not fixed, the bigger mess we'll have with this issue.

Comment 6 by, Mar 5 2014

m.goleb, just curious what are you trying to do with percentage margins/padding?

Comment 7 by, Apr 15 2014

Re #6: I was mostly trying to set the "height" relative to the element width using the padding trick only to discover it to be broken in Firefox.

In the long run, what matters most is that browsers agree on it, especially that it's extremely easy to reproduce. So far everyone does sth different than Fx & the standard. Either the standard should be changed back to reflect reality or every browser should fix it. Current situation leads to bugs.

What do you think?

Comment 8 by, Apr 15 2014

@tabatkins: Do you think there's a chance of getting the spec to change here? I don't think there's any benefit from flexbox/grid being special for these. Comment #7 is a perfect example of someone trying to do something that works on non-flexboxes and breaks unnecessarily with flexboxes. There's just no reasonable use-case for percentage margins/padding, so adding complexity for them isn't worth it.

I know the CSSWG talked about this and decided on this, but it still seems like the wrong choice to me.

Comment 9 by, Apr 16 2014

Tab - we just discovered that IE 11 doesn't follow the spec here either, using this testcase:

(if the two divs look the same, the spec is not being followed)

So two out of three rendering engines don't implement this... maybe time to reconsider changing the spec? I'll email www-style in a second.

Comment 10 by, Apr 16 2014

Labels: Cr-Blink-Rendering-Flexbox

Comment 11 by, Apr 29 2014

Word from last telcon is that the WG wants to keep the specced behavior, and IE will change its Flexbox behavior to match the spec.

The logic is that the behavior of percentage vertical padding in existing layout modes is document-focused, where width is *always* the dominant measurement; height is nearly never an input to anything.  The newer layout modes (Flexbox and Grid) are different - in them, height and width are on a more equal playing field, and code written that uses percentage padding in the main axis of a flexbox should work equally well for row and column flexboxes.  Similar arguments apply for Grid.

This does mean losing some functionality, like the percentage-vertical-padding-to-make-aspect-ratios hack, but we should be solving those properly with a real aspect-ratio property anyway.  It also means breaking theoretical consistency with the older layout models, but the other implementors in the CSSWG (Rossen from IE, dbaron from Moz) are okay with this.

Comment 12 by, Apr 29 2014


Comment 13 by, Jun 24 2014

 Issue 333533  has been merged into this issue.

Comment 14 by, Jul 9 2014

Status: Available
harpreet, thanks for fixing flexbox issues! How would you feel about trying to fix this next? I think a relatively large number of developers are hitting this issue, e.g. see

Comment 15 by, Jul 9 2014

Oh, sorry, I thought this was the percentages resolving against stretch-aligned items bug (which we should fix soon if we haven't already).

I'm less convinced that we should spend the time to fix this now. Fixing this is hard and all the bugs I've seen filed about this are developers expecting the Chrome/Safari behavior.

Comment 16 by, Jul 9 2014

> I'm less convinced that we should spend the time to fix this now.


> all the bugs I've seen filed about this
> are developers expecting the Chrome/Safari behavior.

This implies that developers are writing content that depends on the Chrome/Safari behavior, which means it'll be progressively more painful to fix this the longer you wait, correct? (i.e. a fix will break progressively more content on the web, the longer you wait)

(And in the meantime, content coded to depend on this behavior will be broken in other rendering engines that do match the spec on this point, which is unfortunate.)

I understand it being hard to fix; I'm just concerned about explicitly de-prioritizing this to a "no one's going to work on this anytime soon" status, given these interop/progressively-harder-to-fix-as-time-passes concerns.

Comment 17 by, Jul 11 2014

Started working on this issue

Comment 18 by, Jan 9 2015

Labels: -Cr-Blink-Rendering-Flexbox Cr-Blink-Layout-Flexbox
Migrate from Cr-Blink-Rendering-Flexbox to Cr-Blink-Layout-Flexbox

Comment 19 by, Jan 9 2015

Labels: -Cr-Blink-Rendering Cr-Blink-Layout
Migrate from Cr-Blink-Rendering to Cr-Blink-Layout

Comment 20 Deleted

Comment 21 Deleted

Comment 22 by, Mar 18 2015

[I just deleted my response to a now-deleted advocacy comment; but I'll leave in this relevant bit, for reference/linkability -- there's an ongoing thread about this at the CSSWG mailing list:

Comment 23 by, Jul 3 2015

Note: the CSSWG considered some alternative proposals to this behavior in May, and (once and for all, I think) they decided to keep this chunk of spec-text as-is: 
>  RESOLVED: Flexbox top/bottom margins and padding resolve against height.

So, this bug is still valid.

If I understand correctly, I think Tab also indicated that Chrome would match the CSSWG's decision in that meeting ("worst case, we would change").  Any timeline on fixing this? I'd really rather have this not be an interop-is-broken-forever type issue. :-/

Comment 24 by, Sep 8 2015

Seems standards are only worth following when you've got less than 50% market share, after that its "well we are broken regarding the actual standard, but we are the quasi standard due to people looking to us for reference behaviour, so lets not bother fixing these types of issues."

I for one welcome our new Chrome overlords. Flexbox is useless without interop, as you are better off resorting to the layout hacks that made moving to flexbox so attractive.

Comment 25 by, Sep 8 2015

We are still actively discussing this with the CSS working group at the W3C to try to change the specification. That discussion is ongoing and very contentious though.

Do you have a use-case where you want the specced behavior? Part of the reason we're arguing to change the spec is that all the developers we've heard from want the Blink/WebKit behavior because they want to do the aspect ratio hack. We've had no developers asking for the specced behavior.

Comment 26 by, Sep 9 2015

I have a design where everything inside the flex box layout needs to be in percentages , which includes any padding. Specifically, I have column and row flex boxes that have text labels inside their item box children that needs padding. It doesn't really matter for my use case whether the current standard is implemented or the method that more closely matches the existing calculations. I admit I wasn't fully aware of the underlying behaviour for % padding before now, and found it confusing that I needed very different padding ranges for my column and row based flex boxes, but that is as much about my own ignorance as anything. 

What is important is that I can avoid conditional layout for different browsers. Given everyone but Firefox seems to have avoided implementing the spec here, I can see it might be easier from a practical point of view to change the spec, but I can also the argument of the WG that the existing pre-spec convention for padding calculations are not particularly intuitive either. For now, I've avoided the current cross-evergreen-browser padding issue in my own layout by using SVG text which gives me other ways of controlling the padding of my text , with the added benefit of auto-scaling the text as the container changes which was going to require JS without using SVG.

Comment 27 by, Sep 9 2015

I'm sorry this is causing you problems. We really do care about getting interoperable behavior here and are prioritizing addressing this. It's just a surprisingly complicated problem.

Comment 28 by, Sep 9 2015

I'm curious - are your width/height in percentages, too?  Since you weren't aware that the current behavior was "different" for row and column flexboxes, this suggests that the percentages themselves aren't actually important.

That is, if you had a bunch of percentages that needed to add up to 100% or something, okay, that can be reasonable.  But that's currently impossible for column flexboxes in Chrome, and it seems like you didn't even notice that.  What were you actually using the percentages for?

Comment 29 by, Sep 11 2015

To be a bit more specific my use case is a chess board where the squares themselves are fairly vanilla layout, but I use flexbox to provide layout for column and row labels placed around the board. There are a few options for label layout
- left and bottom column/row
- left/right/bottom/top (i.e. labels duplicated on top/bottom , left/right).
- Internal which is similar to left/bottom but labels shown internally on the board instead of surrounding it.

All sizing is in % so that everything magically resizes when the outer most size of the container changes. The padding issue I ran into was when trying to pad the labels in the internal layout. I was able to use centering via the appropriate flexbox directives in the other cases, but for internal case the labels need to be at the edge of the board squares to be visible on squares holding chess pieces, and this required padding in my original version. Testing on Chrome it worked fine once I worked out the columns needed very different padding to the rows, but the padding broke badly when using Firefox due to their flexbox specific layout. Note that I think what I'd initially tried before fiddling to fit the more standard non-flex box behaviour that Chrome is using probably would have worked on Firefox, so I can see the WG argument on what the default behaviour should be, but I can also see that more experienced web devs who are used to the non-flex box behaviour will probably not have the same experience I had.

As mentioned, I ended up going with SVG for the labels which provided me more flexibility and a nicer scaling of the labels as the container grows (current lack of ability to easily choose font sizes relative to the container without SVG meant I would have needed to use JS to scale the labels as the container size changed). I probably could have stuck with the same design, and avoided SVG by enclosing my labels in another wrapper, but I'd still have to use JS for the auto-scaling of the text, so what I've arrived at is probably a better solution, and sees to work well across all current browser versions.

For reference the current version of the internal coordinates style board is here:

(still a work in progress, but the resizing and co-ordinate scaling should work, the edges of the board have (hard to see) resize handles).

Apologies for the tone in my first response, was made at the end of a frustrating debug session surrounding interop issues :-)

Comment 30 by, Nov 27 2015

Labels: Cr-Blink-Layout-Grid

Comment 31 by, Nov 27 2015

Summary: for flex/grid items, percent margins and paddings should resolve against their respective dimension (was: for flex items, percent margins and paddings should resolve against their respective dimension)

Comment 32 by, Nov 27 2015

Blocking: chromium:79180

Comment 33 by, Dec 1 2016

Project Member
Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit - Your friendly Sheriffbot

Comment 34 by, Dec 1 2016

Status: Available (was: Untriaged)
Note that the spec allows either behavior now. Still, it is unfortunate that browsers disagree on this.

Comment 35 by, Dec 1 2016

Labels: Hotlist-Interop
This is a very well known issue that happens in both Flexbox and Grid,
where the behavior is different to the one in Firefox and Edge (that has been already modified).

It's clearely reproducible with a simple example like the one attached.

There are actually metrics to check the usage of percentage in paddings and margins on flexboxes:

But I don't know if there are plans to fix this in the short term though.
383 bytes View Download
1.9 KB View Download
1.9 KB View Download

Comment 36 by, Dec 1 2016


Comment 37 by, Mar 7 2017


Comment 38 by, May 25 2017

Yes! We should be solving those properly with a real aspect-ratio property anyway.

Comment 39 by, Nov 16 2017

This has created a couple of webcompat issues for Firefox and probably Edge.
and probably

Comment 40 by, Nov 17 2017

The spec now says (
> 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), or,
> * the inline axis (left/right/top/bottom percentages all resolve against width)

It also has a note:
> 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.

And also has a recommendation to avoid using them:
> Authors should avoid using percentages in paddings or margins on flex items entirely,
> as they will get different behavior in different browsers.

This applies to both Flexbox and Grid (

Comment 41 by, Feb 9 2018

Both Edge & Firefox teams have committed to change to align with the Chrome/Safari behavior. The spec also got an update to mandate this behavior:

It sounds that this issue should be closed as "Won't Fix".

Comment 42 by, Feb 12 2018

Status: WontFix (was: Available)
Yeah this was resolved by the CSS WG and Firefox and Edge are changing their behavior.

Check the following issue for more details:

Sign in to add a comment