Bug 87068 - Replaced items in a flexbox should be coerced to display:block
Summary: Replaced items in a flexbox should be coerced to display:block
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Tony Chang
URL:
Keywords:
Depends on: 88963
Blocks: 62048
  Show dependency treegraph
 
Reported: 2012-05-21 18:45 PDT by Ojan Vafai
Modified: 2012-06-12 22:58 PDT (History)
7 users (show)

See Also:


Attachments
Patch (11.17 KB, patch)
2012-06-12 13:26 PDT, Tony Chang
no flags Details | Formatted Diff | Diff
Patch (11.23 KB, patch)
2012-06-12 13:27 PDT, Tony Chang
no flags Details | Formatted Diff | Diff
Patch (11.46 KB, patch)
2012-06-12 13:33 PDT, Tony Chang
no flags Details | Formatted Diff | Diff
Patch for landing (11.77 KB, patch)
2012-06-12 13:58 PDT, Tony Chang
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ojan Vafai 2012-05-21 18:45:45 PDT
As per the new spec. It actually hardcodes tagnames that should be coerced to display:block when they are in a flexbox.

It also says "An atomic inline-level child of a flex container" should be a flex-item. I'm not really sure what that refers to since it's a different item than the replaced items and the spec refers to button as an atomic inline-level child. Tab, can you clarify?
Comment 1 Tab Atkins Jr. 2012-05-22 13:20:46 PDT
"atomic inline" refers to things that are inline-level, but lay out as a single thing: inline-block, inline-table, inline replaced, etc.

All the hardcoded tag names should have already been flexbox items, since they all fall under the "replaced element" umbrella - the new entry with hardcoded names is just meant to cover the odd case where an element can be replaced or not depending on whether a link resolves.
Comment 2 Tony Chang 2012-06-12 13:26:38 PDT
Created attachment 147141 [details]
Patch
Comment 3 Tony Chang 2012-06-12 13:27:19 PDT
Created attachment 147142 [details]
Patch
Comment 4 Tony Chang 2012-06-12 13:27:43 PDT
Comment on attachment 147142 [details]
Patch

Added a link to the spec in the ChangeLog.
Comment 5 Gyuyoung Kim 2012-06-12 13:31:49 PDT
Comment on attachment 147142 [details]
Patch

Attachment 147142 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/12944649
Comment 6 Tony Chang 2012-06-12 13:33:58 PDT
Created attachment 147143 [details]
Patch
Comment 7 Ojan Vafai 2012-06-12 13:45:47 PDT
Comment on attachment 147143 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=147143&action=review

> Source/WebCore/css/StyleResolver.cpp:1923
> +static bool shouldBecomeBlockWhenParentIsFlexbox(const Element* element)

This should probably include a link to the spec.

> LayoutTests/css3/flexbox/resources/flexbox.js:69
> +    var expectedDisplay = node.getAttribute && node.getAttribute("data-display");

Nit: should the attribute name be data-expected-display?
Comment 8 Tony Chang 2012-06-12 13:58:50 PDT
Created attachment 147152 [details]
Patch for landing
Comment 9 Tony Chang 2012-06-12 13:59:11 PDT
Comment on attachment 147143 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=147143&action=review

>> Source/WebCore/css/StyleResolver.cpp:1923
>> +static bool shouldBecomeBlockWhenParentIsFlexbox(const Element* element)
> 
> This should probably include a link to the spec.

I didn't want to include a link to the working draft in code. Once it's finalized or CR stage, it would probably be OK.

>> LayoutTests/css3/flexbox/resources/flexbox.js:69
>> +    var expectedDisplay = node.getAttribute && node.getAttribute("data-display");
> 
> Nit: should the attribute name be data-expected-display?

Renamed.
Comment 10 WebKit Review Bot 2012-06-12 15:39:18 PDT
Comment on attachment 147152 [details]
Patch for landing

Clearing flags on attachment: 147152

Committed r120132: <http://trac.webkit.org/changeset/120132>
Comment 11 WebKit Review Bot 2012-06-12 15:39:23 PDT
All reviewed patches have been landed.  Closing bug.