User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.87 Safari/537.36 Steps to reproduce: I'm on v.49.0.2 (latest stable at time of this writing). I created a codepen illustrating the issue: http://codepen.io/threecleartones/pen/ZBOQoJ?editors=1100#0 Here is a description: I created a simple flexbox div with three children spans and an ::after pseudo-element, with `justify-content: space-between`. I then toggled the `position` property of one of the children to `absolute` to see the behavior. Actual results: When I toggled the `position` property of the third span, or the `::after`, to `absolute`, it is positioned correctly within the parent container, but the it still occupies space in its original flex-item location. In other words, even though the item is positioned absolutely, it does not appear to be taken "out of the flow" as is required by the spec (I think?). This is apparent by the placement of the other flex-items before and after the `position` property is changed. Expected results: I believe webkit is handling this correctly, so you can compare the codepen link above in each browser. In Chrome, the absolutely positioned item is positioned correctly, as it is in Firefox, but it is also take out of the flow, so it no longer occupies space inside the flex box, and the other flex items adjust their positioning accordingly. I believe Chrome's behavior is correct and Firefox's is not. An example of the adverse nature of this behavior is when you want to use an absolutely positioned pseudo element to create a bottom border on the flex box - the border is displayed correctly, but the remaining flex items behave as if the pseudo-element is still a flex item and place themselves around the empty whitespace accordingly.
OS: Unspecified → All
Hardware: Unspecified → All
Thanks for the bug report! Our implementation here is actually correct per an older version of the spec, but the spec did change (so your expectations about the testcase are correct) -- and we've recently implemented the updated spec, in Firefox 52. I've verified that Firefox Nightly (version 53) matches Chrome here -- so this is already fixed in our trunk. That change happened in bug 1269045 (in support of the general bug 874718). --> Marking as a duplicate.
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1269045
You need to log in before you can comment on or make changes to this bug.