Bug 70754

Summary: implement flex-align for flex-flow: column
Product: WebKit Reporter: Tony Chang <tony>
Component: Layout and RenderingAssignee: Ojan Vafai <ojan>
Status: RESOLVED FIXED    
Severity: Normal CC: dglazkov, gustavo, ojan, webkit.review.bot, xan.lopez
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 71161    
Bug Blocks: 62048    
Attachments:
Description Flags
testcase
none
Patch
none
Patch
none
Patch hyatt: review+

Tony Chang
Reported 2011-10-24 13:28:51 PDT
flex-align landed before flex-flow: column, so there are probably some bugs here. We also need tests.
Attachments
testcase (206 bytes, text/html)
2011-10-26 16:40 PDT, Ojan Vafai 		no flags
Details
Patch (11.59 KB, patch)
2011-10-28 19:49 PDT, Ojan Vafai 		no flags
DetailsFormatted DiffDiff
Patch (11.63 KB, patch)
2011-10-29 14:16 PDT, Ojan Vafai 		no flags
DetailsFormatted DiffDiff
Patch (18.21 KB, patch)
2011-10-30 13:45 PDT, Ojan Vafai 		hyatt: review+
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Ojan Vafai
Comment 1 2011-10-26 16:40:11 PDT
*** Bug 70980 has been marked as a duplicate of this bug. ***
Ojan Vafai
Comment 2 2011-10-26 16:40:25 PDT
Created attachment 112618 [details] testcase
Ojan Vafai
Comment 3 2011-10-28 19:49:42 PDT
Created attachment 112963 [details] Patch
Ojan Vafai
Comment 4 2011-10-28 19:50:39 PDT
This patch needs on the patch in bug 71161 to pass the new tests.
WebKit Review Bot
Comment 5 2011-10-28 19:54:17 PDT
Comment on attachment 112963 [details] Patch Attachment 112963 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/10240240
Gyuyoung Kim
Comment 6 2011-10-28 19:54:21 PDT
Comment on attachment 112963 [details] Patch Attachment 112963 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/10237433
Early Warning System Bot
Comment 7 2011-10-28 19:57:29 PDT
Comment on attachment 112963 [details] Patch Attachment 112963 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/10244120
Gustavo Noronha (kov)
Comment 8 2011-10-28 21:27:40 PDT
Comment on attachment 112963 [details] Patch Attachment 112963 [details] did not pass gtk-ews (gtk): Output: http://queues.webkit.org/results/10238440
Daniel Bates
Comment 9 2011-10-29 06:18:13 PDT
Comment on attachment 112963 [details] Patch Attachment 112963 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/10238503
Ojan Vafai
Comment 10 2011-10-29 14:16:19 PDT
Created attachment 112977 [details] Patch
Ojan Vafai
Comment 11 2011-10-30 13:45:43 PDT
Created attachment 113001 [details] Patch
Ojan Vafai
Comment 12 2011-10-30 13:46:40 PDT
*** Bug 70774 has been marked as a duplicate of this bug. ***
Tony Chang
Comment 13 2011-10-31 10:18:54 PDT
Comment on attachment 113001 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=113001&action=review > Source/WebCore/ChangeLog:13 > + * rendering/RenderBox.cpp: > + (WebCore::RenderBox::sizesToIntrinsicLogicalWidth): > + When flexitems are column, they should size to the intrinsic width unless flex-flow is stretch. Nit: Maybe explain why this is different from the old flexbox code. Maybe we can get rid of the boxOrient and boxAlign checks on the old flexbox code? > Source/WebCore/rendering/RenderFlexibleBox.cpp:733 > else If we change the width, do we have to relayout the flexitem? Maybe not since it's only growing beyond the intrinsic size.
Tony Chang
Comment 14 2011-11-01 16:07:54 PDT
(In reply to comment #13) > (From update of attachment 113001 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=113001&action=review > > > Source/WebCore/ChangeLog:13 > > + * rendering/RenderBox.cpp: > > + (WebCore::RenderBox::sizesToIntrinsicLogicalWidth): > > + When flexitems are column, they should size to the intrinsic width unless flex-flow is stretch. > > Nit: Maybe explain why this is different from the old flexbox code. Maybe we can get rid of the boxOrient and boxAlign checks on the old flexbox code? I tried removing the boxOrient and boxAlign checks in the old flexbox codepath and it broke a bunch of tests. I think the old spec didn't require everything to be shrinkwrapped.
Ojan Vafai
Comment 15 2011-11-03 13:43:55 PDT
Comment on attachment 113001 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=113001&action=review >>> Source/WebCore/ChangeLog:13 >>> + When flexitems are column, they should size to the intrinsic width unless flex-flow is stretch. >> >> Nit: Maybe explain why this is different from the old flexbox code. Maybe we can get rid of the boxOrient and boxAlign checks on the old flexbox code? > > I tried removing the boxOrient and boxAlign checks in the old flexbox codepath and it broke a bunch of tests. I think the old spec didn't require everything to be shrinkwrapped. Yeah, I don't actually know the old code well enough to know why it doesn't require everything to be shrinkwrapped.
Ojan Vafai
Comment 16 2011-11-03 13:45:49 PDT
(In reply to comment #13) > (From update of attachment 113001 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=113001&action=review > > > Source/WebCore/rendering/RenderFlexibleBox.cpp:733 > > else > > If we change the width, do we have to relayout the flexitem? Maybe not since it's only growing beyond the intrinsic size. As discussed in person, there seem to definitely be cases where we need to do another layout: -when changing the width -if there are positioned items positioned wrt the bottom/right of the element Possibly others. Definitely a separate patch. Maybe this calls for making the default value for flex-align not being stretch.
Dave Hyatt
Comment 17 2011-11-15 12:49:49 PST
Comment on attachment 113001 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=113001&action=review r=me > Source/WebCore/rendering/RenderBox.cpp:1811 > +#if ENABLE(CSS3_FLEXBOX) > + if (parent()->isFlexibleBox()) > + return true; > +#endif Put a FIXME in here that the stretching children of vertical boxes will end up doing an extra layout with this approach.
Ojan Vafai
Comment 18 2011-11-15 16:29:24 PST
Committed r100365: <http://trac.webkit.org/changeset/100365>
Note You need to log in before you can comment on or make changes to this bug.