When a node is both a flex container and a flex item, we show two accordion items: "Flex Container" and "Flex Item of …".

By default the order is:

1. Flex Item
2. Flex Container

But when users select a node from the Markup view, we reverse this order and show "Flex Container" first, as explained in this code comment:

If the node was selected from the markup-view, then show this accordion after the container accordion. Otherwise show it first.
The reason is that if the user selects an item-container in the markup view, it is assumed that they want to primarily see that element as a container, so the container info should be at the top.

I'm not sure this assumption checks out. In my experience, actions like selecting an element with the "Pick an element" tool (or right-click and Inspect Element), and selecting another element from the markup view, do not carry a difference in intent. They are both navigation tool:

• Pick an element: often the entry point to the code, to go from something you see in the page to the corresponding DOM nodes and styles.
• Select an element in Markup: often used in a second step, when you want to check out the styles for an element's children, siblings, parent, sibling-of-parent, etc.

In both navigation scenarios, users may want to see the "Flex Container" section first, or the "Flex Item" section first, or maybe they don't care about the Flex sections and just want to look at the "Box Model". It's hard to divine those intentions based on the selection or navigation tool used. :/

I'm also worried that this behavior looks random to users, since it uses an internal rule that is not communicated to users; and that this "randomness" may give an impression that the Layout tool is unreliable (or at least that it's hard to find what you want in it). Since we already have a few bugs that may contribute to this impression (bug 1576604, bug 1578097), I'd like to avoid that.

I suggest using a fixed order all the time.
My preference would be for Container -> Item, because it follows a "general to particular" direction that I'm used to, but the opposite works too.

Screenshots showing the current behavior.

Thanks for your attention to this. Wow. I just realized that this doesn't work the way I expected it to :)

My opinion was based on these two types of navigation:

1. Selecting a flex element from within the Flex Container panel's list of children
   —> Should see item first

2. Selecting a flex element from anywhere else
   —> Should see container first

Maybe this is still confusing, but, I'd think, more sensible than how it works now.

Thanks Victoria and Florens. I feel like we need to consolidated the requirements here. Martin and Victoria, I'm going to needinfo both of you to trigger some discussions and request a final decision on this.
What's defined in comment 2 makes sense to me. I don't have a strong opinion. Are we ok with this? Are there other points worth discussing about with respect to what Florens mentioned?

I think the way it currently works is very unpredictable and unintuitive. I dislike that it requires explanation, so I'm much more in favor of :fvsch suggestion: A layout/order that is always the same, regardless of how you navigate to it.

Now, in terms of order, I agree in general with the "general to specific" approach. In this particular case however I feel that the flex container panel offers way less value than the flex item panel, so I would actually move it to the second position. (I, personally, have the flex container panel hidden)

FYI: I think this bug is a duplicate

Indeed this was discussed already in bug 1513502. (I'd looked in the "Inspector: Layout" component but not in the bigger "Inspector" component.) Let's reach a decision, then dupe one way or the other. :)

Thanks all. I'll concede on this one, as my idea seems too confusing to even properly communicate for the purposes of implementation 😅 - it tells me there must be a better other solution!

I want to upgrade parts of the Flexbox flow anyway for my Unified Layout schemes, so that would be a good context in which to revisit this issue. There is probably a way to merge the two in a way that makes sense, and we can make the Flex Container section more useful.

(attached quick hideous mockup of what a merge could mean)

But for now I'd say we should change it as Martin describes.