RESOLVED FIXED 99923
margin-top/bottom has no effect for child nodes of flex items
https://bugs.webkit.org/show_bug.cgi?id=99923
Summary margin-top/bottom has no effect for child nodes of flex items
Shaofei Cheng
Reported 2012-10-21 01:16:05 PDT
When set margin property to a child node of flex item, it does not effect. See the test case here https://test.csswg.org/shepherd/repository/tip/contributors/ttwf_bj/winter/submitted/flex-flexitem-childmargin.html
Attachments
reduced testcase with webkit prefixes (440 bytes, text/html)
2012-10-21 09:30 PDT, Ojan Vafai
no flags
margin-collapsing without flexbox (393 bytes, text/html)
2012-10-21 09:36 PDT, Ojan Vafai
no flags
margin-collapsing without flexbox ('overflow: hidden') (635 bytes, text/html)
2012-10-21 16:55 PDT, Kang-Hao (Kenny) Lu
no flags
Patch (5.99 KB, patch)
2012-10-22 16:19 PDT, Tony Chang
no flags
Ojan Vafai
Comment 1 2012-10-21 09:30:25 PDT
Created attachment 169804 [details] reduced testcase with webkit prefixes
Ojan Vafai
Comment 2 2012-10-21 09:31:40 PDT
Presumably this is margin-collapsing doing the wrong thing. I'm not actually sure this is technically wrong though. margin-collapsing is just kind of crazy.
Ojan Vafai
Comment 3 2012-10-21 09:36:17 PDT
Created attachment 169805 [details] margin-collapsing without flexbox
Ojan Vafai
Comment 4 2012-10-21 09:37:42 PDT
This looks to me as working as intended. Please reopen if I'm wrong. margin-collapsing is just very confusing and complicated. Tab, didn't you have some idea for limiting margin-collapsing that might simplify some of the more confusing situations (like this one)?
Kang-Hao (Kenny) Lu
Comment 5 2012-10-21 16:55:59 PDT
Created attachment 169818 [details] margin-collapsing without flexbox ('overflow: hidden') The spec says a flex container establishes a block formatting context and so I attached a version of the test case with 'overflow: hidden;' set on the corresponding element. An earlier version (two months ago?) of spec says each flex item establishes a BFC so the first example in my test case is set with such, which I consider the expected behavior. But even without the reason above, setting the 'margin-top' of the element in question (the first child of a flex item) to, say, 20000em would not push the element out of the window. That is, I don't think the top margin of the element is collapsed with anything else. It is just always zero. For what it's worth, both Opera Next and Firefox nightly work as expected but I don't have IE10 at hands. So yes, I think this should be reopened. Unfortunately I don't have editbug.
Kang-Hao (Kenny) Lu
Comment 6 2012-10-21 16:57:25 PDT
(In reply to comment #5) > An earlier version (two months ago?) of spec says each flex item establishes a BFC so the first example in my test case is set with such, which I consider the expected behavior. the second, I mean.
Ojan Vafai
Comment 7 2012-10-21 21:27:52 PDT
I think you're right. Reopening.
Ojan Vafai
Comment 8 2012-10-21 21:32:26 PDT
I think we just need to update RenderBlock::MarginInfo::MarginInfo to know about flexboxes.
Tab Atkins
Comment 9 2012-10-22 11:03:18 PDT
(In reply to comment #5) > Created an attachment (id=169818) [details] > margin-collapsing without flexbox ('overflow: hidden') > > The spec says a flex container establishes a block formatting context and so I attached a version of the test case with 'overflow: hidden;' set on the corresponding element. An earlier version (two months ago?) of spec says each flex item establishes a BFC so the first example in my test case is set with such, which I consider the expected behavior. Hm, I didn't intend to lose that text about the flex items being BFCs. I'll bring it up on the list, I suspect it was an editting mistake.
Tab Atkins
Comment 10 2012-10-22 11:04:00 PDT
But yeah, Ojan, intention is definitely that children of a flex item do *not* collapse their margins with the flex item. Flex item margins are intended to be fully independent.
Tony Chang
Comment 11 2012-10-22 16:19:52 PDT
Tony Chang
Comment 12 2012-10-22 16:21:13 PDT
+julien, who may know other situations where a RenderObject doesn't have a parent.
Julien Chaffraix
Comment 13 2012-10-22 16:47:03 PDT
(In reply to comment #12) > +julien, who may know other situations where a RenderObject doesn't have a parent. Your check is right as the tree is stable and properly attached during layout.
WebKit Review Bot
Comment 14 2012-10-22 17:04:07 PDT
Comment on attachment 170016 [details] Patch Clearing flags on attachment: 170016 Committed r132164: <http://trac.webkit.org/changeset/132164>
WebKit Review Bot
Comment 15 2012-10-22 17:04:13 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.