977263 - Padding-top is ignored in vertical flexboxes

Status: RESOLVED DUPLICATE of bug 958714

(Core :: Layout, defect)

Description

[Maël Nison]

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

Steps to reproduce:

I created the following two fiddles :
 - http://jsfiddle.net/VwW2k/5/
 - http://jsfiddle.net/VwW2k/6/

Basically, a verticaly-aligned flexbox model, whose one of the elements (flex: none) has its height set using padding-top:%.


Actual results:

 - A 200x200 blue box appear.



Expected results:

- http://jsfiddle.net/VwW2k/7/

A 200x200 yellow box in front of a 200x200 red box (hiding it), and a 200x200 blue box below them.

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to Maël Nison from comment #0)
> I created the following two fiddles :
>  - http://jsfiddle.net/VwW2k/5/
>  - http://jsfiddle.net/VwW2k/6/

These are actually two different issues.

The /5/ issue is a real bug, and is fixed in Firefox 28 by bug 903880. Basically, what's happening there was technically correct, per the flexbox spec at the time -- what's happening is this:
 - [setup: there's a % padding on a child of a (block) flex item, which is supposed to resolve against the width of the block.]
 - Before establishing the width of that block, we first measure its height (since this is a vertical flex container, which means we lock in the heights before we lock in the widths).  To measure its height, we tentatively give it its intrinsic width, which is 0.  So when we measure the height, the % padding resolves against that 0-width and produces 0. Since that's the only thing contributing to the height, the flex item ends up having a height of 0.
 - Then, later on, we apply the [default] "align-self:stretch" to the flex item, and give it a larger width. But at that point it's too late -- we've already locked in its height, which is 0.

The CSSWG has fixed this in the spec (editor's draft) and in our implementation, in Firefox 28. See bug 903880 for more details.

For your /6/ fiddle, we're actually doing the right thing -- see bug 958714 comment 3. Chrome gets this wrong currently (I assume you're comparing Firefox to Chrome) -- I filed https://code.google.com/p/chromium/issues/detail?id=333533 earlier this year to report this to them. Feel free to encourage them to fix this. :)


SO: Fiddle /5/ is a duplicate of bug 903880, and /6/ is a duplicate of bug 958714. Duping to bug 958714, since I can't dupe to two targets.

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #1)
> The CSSWG has fixed this in the spec (editor's draft) and in our
> implementation, in Firefox 28. See bug 903880 for more details.

er, meant to say "and _we've fixed this_ in our implementation" :)

Comment 3

[Maël Nison]

Thanks for the explanation, Daniel ! :)

In the meantime I have discovered that I was using flex-direction:column where it wasn't needed. I guess that I should be more careful about this property use cases !

Comment 4

[Daniel Holbert [:dholbert]]

You're welcome! Thanks for taking the time to file a bug.