MS Edge: top/bottom:auto don't work properly on absolutely-positioned elements in relatively-positioned flex container

[RwwL]

When an absolutely positioned element uses the value "auto" with the properties "top" or "bottom" then the element's vertical position is determined by its position in the source order and the natural flow within the element's offsetParent.

In MS Edge, however, top:auto and bottom:auto are both rendered more like they were explicitly set to top:0 if the offsetParent also contains "display:flex."

The following test case renders as expected in IE10, IE11, Chrome, Firefox, Safari, and Opera: red gradient at the top of the scrollable area, orange gradient at the bottom. MS Edge positions both gradients from top of the outer container:

http://codepen.io/RwwL/pen/rORQVQ

Issue reported to MSFT:
https://connect.microsoft.com/IE/feedbackdetail/view/2035044/top-auto-and-bottom-auto-dont-work-correctly-in-ms-edge-in-relatively-positioned-flexbox-container

[gregwhitworth]

This is actually per spec, the static position of a flex item that is absolutely positioned is to be as though it was the sole item in the flex container (in default settings this would be 0,0).

The static position of an absolutely-positioned child of a flex container is determined such that the child is positioned as if it were the sole flex item in the flex container, assuming both the child and the flex container were fixed-size boxes of their used size.

The reason you're seeing this issue is due to us being the only one at the moment who has updated to the latest spec language.

[RwwL]

Aha, thanks for letting me know about that, Greg. Is it just me thinking that the new spec language is kind of counterintuitive? I'm not sure why devs shouldn't be able to presume positioning will work similarly to other contexts.

[gregwhitworth]

I agree with you when you first look at it, but let's say that you want to use the new alignment properties from the alignment spec on an abspos flex item? You would need to remove the offset introduced by the static position in order to center an item, which is messy and continues the old adage of "Why can't I center something in CSS". When we introduced grid it allowed you to have this capability to easily center any element, whether it be an abspos or not; taking its siblings into account of course if it is in flow. To align flex and grid (since they are both modern layouts) it was decided that it makes sense to allow for the new alignment capabilities to work in both. Thus the change, if you're curious what this enabled - see this testcase (the two boxes should be in the same place): http://jsbin.com/xowulasica/edit?html,css,output

Basically the question is this, do you hold back future layout types due to limitations of older ones for consistency, or do you enable new layout types with more capabilities that introduces some inconsistency with other layout types. We're betting on the latter because hopefully as these technologies are adopted block layout is used only where it was designed for, documents, not application layout. If we succeed in that, there is far less inconsistency due to most abspos use cases are for application layout which would use Grid or Flex and they would be consistent with one another. Feel free to let me know if you have any other questions.

[RwwL]

Thanks for that thoughtful and detailed response, Greg, it helps a lot.

[jlukic]

@gregwhitworth The issue is there are several ways to center things in css transform: translateX(-50%) translateY(-50%);, margin: auto in a flex container, negative margins etc.

There are now exactly zero ways to position a content using its calculated flex position, but outside of normal layout. This will prevent people from being able to accomplish many very standard designs within flex containers that were previously possible.

It's also important to realize that because there is no way to determine whether content is inside a flex container this introduces new behavior that elements cannot anticipate without somehow knowing whether its parent container is flex. This makes developing components that work reasonably in all situations very difficult. (Flex elements missing margin collapse is another example of this).