1234533 - FireFox ignores padding-top/padding-bottom for flex children

Status: RESOLVED DUPLICATE of bug 958714

(Core :: Layout, defect)

Description

[noel.abrahams]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36

Steps to reproduce:

Open the following fiddle in FireFox.

https://jsfiddle.net/3uqLapjs/2/

The padding-top/bottom values have no effect when set in percentage terms.

Open the same fiddle in Chrome and observe that the padding is being applied.


Actual results:

See above


Expected results:

See above

Comment 1

[noel.abrahams]

In fact margin top/bottom doesn't work either. See https://jsfiddle.net/nabog/3uqLapjs/3/

Comment 2

[Mats Palmgren (inactive)]

I believe this is a bug in Chrome.  Firefox is doing this correctly.
Vertical percentage padding is resolved against the containing block height
for Flexbox and Grid.
You have not specified a height on the containing block, the <ul>, and
percentage resolved against an indefinite percentage basis ('auto') is zero.
If you add 'ul { height:100px }' you'll see that it works correctly.

Comment 3

[noel.abrahams]

Yes, I understand that. The use-case is where there is a clear-fix applied as well, so in fact the <ul> should not collapse.

This is all the more inconsistent, because the horizontal percentage padding works.

I think that Chrome is right, because they have understood the use-case. I frequently see FireFox bugs not being fixed on the basis of not understanding the use-case, and rather having a tendency to reason in the abstract.

This IMO should be fixed.

Comment 4

[noel.abrahams]

Here's another reason. When the child elements are floated, then the padding works, irrespective of the container height not being set:

https://jsfiddle.net/nabog/3uqLapjs/4/

There should be no different treatment of float vs flex: the intention is the same.


@MatsPalmgren, does that make sense?

Comment 5

[Boris Zbarsky [:bzbarsky]]

> There should be no different treatment of float vs flex:

Per spec there should: for a normal block, vertical percentage padding is a percentage of containing block _width_.  For a flex item it's a percentage of containing block _height_.

That said, it's odd that Chrome is not following the flex spec here.  Daniel, do you know whether there's an issue filed on them for this?

Comment 6

[Daniel Holbert [:dholbert]]

Was about to type: "Yup, we're matching the spec here, and Chrome is not."

But then I checked the spec, and it looks like it's been recently updated to allow either behavior:
> 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)
> 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.

https://drafts.csswg.org/css-flexbox-1/#item-margins

Until recently, the spec required the behavior that we implement (and Chrome was non-conforming). https://code.google.com/p/chromium/issues/detail?id=333533 is filed on this for Chrome.

Comment 7

[Daniel Holbert [:dholbert]]

In any case, this is a duplicate of bug 958714 (which is invalid because we're doing what the spec recently required, & what it still allows).

Noel, if you're curious about why there's disagreement here, see this thread on the working group mailing list for some background: https://lists.w3.org/Archives/Public/www-style/2015Feb/0521.html

Comment 9

[noel.abrahams]

Daniel,

We see Flex as a replacement for float, to the extent that float is being used simply for layout reasons. I am pretty sure that is going to be the view of most people coming to flex. So I anticipate that most people will view this as a bug.

Incidentally, you should really consider moving your issue tracking to GitHub. This is the most awful and ancient system there is. I think it seriously affects people reporting issues and contributing to your project.

Comment 10

[Boris Zbarsky [:bzbarsky]]

It's been discussed.  Github issues are too limited to do things like "is this bug fixed for this release?" and "this fix depends on these other fixes being done first", unfortunately, and they've consistently refused to address these lacks in spite of us asking them for years to do so.  Hence here we are.  We need functionality for our bug tracker that Github explicitly chooses not to provide.

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to noel.abrahams from comment #9)
> We see Flex as a replacement for float, to the extent that float is being
> used simply for layout reasons. I am pretty sure that is going to be the
> view of most people coming to flex. So I anticipate that most people will
> view this as a bug.

Yeah, this is a known pain point (for traditional web developers).  Notice all the dupes of the bug that I duped you against. :)

The other side of the argument (from Microsoft, since they're the main advocate of the behavior that we implement & that the spec required up until recently):
People coming from the *non*-web developer world are going to expect vertical percentages to resolve against vertical sizes, because that's much more sane in general, and it's what they're used to from native UI toolkits. So, CSS Grid in particular needs to work this way. And there's an explicit goal to make CSS Flexbox & CSS Grid as consistent as possible (and a separate goal to make Flexbox as direction-agnostic as possible), so Flexbox needs to work that way too.

SO: it's either confusion for traditional web developers (who've come to expect this weird vertical-padding-resolves-against-width behavior), vs confusion for new web developers with native app toolkit experience.

(This has been argued to death in CSSWG mailing lists & meetings.  Hoping this summarized framing provides a little clarity about how we got here, at least.)

Comment 12

[noel.abrahams]

(In reply to Daniel Holbert [:dholbert] from comment #11)
> (This has been argued to death in CSSWG mailing lists & meetings.  Hoping
> this summarized framing provides a little clarity about how we got here, at
> least.)

Okay, thanks for the update. I'm going to go and take another look at this to see if I can get out of the "web developer" mode. I do remember finding this behaviour strange when I first started on CSS, but I can't say I've had complaints once I got used to it.

(In reply to Boris Zbarsky [:bz] from comment #10)
> We need functionality for our bug tracker that Github
> explicitly chooses not to provide.

The point about GitHub is that it encourages "social coding". They may be lacking in features that you guys are used to, but they more than make up for it with the collaboration that their design encourages. This would mean, for instance, that anti-social behaviour such as that by Mats Palmgren above, who couldn't be bothered to respond to my comment, would be more apparent and corrected in due course.

Comment 13

[Daniel Holbert [:dholbert]]

Please don't interpret Mats lack-of-a-response as "anti-social". We are a relatively small team of developers, following many many bugs, and it is easy to accidentally miss a bug comment here or there.

For future reference, if you have a question specifically directed at someone that you want to be sure they see, you can use the "Need more information from" checkbox at the bottom of the page -- then it ends up in a things-that-need-to-be-replied-to queue that Bugzilla manages for them.

Comment 14

[noel.abrahams]

Sorry, I should have said "non-social" because "anti" sounds nasty.

The point is on GitHub it's as simple as writing @MatsPalmgren to make sure they are notified. And if they don't respond (which is very rare on GitHub) then I can draw my own conclusions.

Also to be fair, this is not the first time I've experienced a complete lack of response, for instance 

https://bugzilla.mozilla.org/show_bug.cgi?id=687311

I just don't have any confidence that reporting an issue here will ever get it resolved.

Comment 15

[Daniel Holbert [:dholbert]]

(Yeah, that is one nice github feature. "needinfo" is our equivalent.  And I think we're getting better about responding to filed bugs, but it's not perfect.)

(RE responsiveness -- also keep in mind: if someone has already looked into the problem and determined that what we're doing is actually correct [as was the case here, as well as in bug 687311 -- see dbaron's comments earlier in the bug], people may be less likely to engage, to avoid going around in circles.)