Thread by @skuwamoto

A lot of people have been asking why the items in an Auto Layout frame go backwards in @figmadesign.

I usually hesitate to answer seemingly simple questions that end up requiring super long answers, but... here we go!
1/n

For starters, let's consider normal everyday layers. If you select a layer and then duplicate it, do you expect it to go above or below the original item in z-index?

If it goes below, you can't see it, since it's under the original, so it has to above.
2/n

Meanwhile, the layers panel traditionally shows things in an order where higher z-index items go above things with lower z-index. Things have been this way as far back as I can remember.

That means the second layer is shown above the first layer in the layers panel.
3/n

Now, let's consider auto-numbering of layer names. If the original layer was called "item 4", what should the new layer be called? "item 5" maybe?

That means that "item 5" ends up above "item 4" in the layers panel.
4/n

Finally, let's consider the order that the plugin API sees. If a frame has four children, named ["item 1", "item 2", "item 3", and "item 4"], and you select "item 4" and duplicate it, does "item 5" go before or after that item in the array?

People expect it to go after.
5/n

So to recap... when you duplicate a layer, it
1) goes above the original in z-index
2) is above (before) the original in the layers panel
3) is after the original (item 4 -> item 5) in terms of naming
4) is after the original in the JS API.

It's always been this way.
6/n

These decisions are arbitrary. They're pretty much what you'd expect, but they're arbitrary.

And even before Auto Layout, they caused problems.

For example, people who use Figma for slides don't like the fact that Slide 7 shows up above Slide 6 in the layers panel.
7/n

Now bring in Auto Layout. The conventions above are already decided. The only new rule we added is:

5) Frames lay out their first child first (left/top) and their last child last, according to the order in the JS API.
8/n

This is especially frustrating because Auto Layout is the first time that (x, y) ordering in canvas space is tied to layer order in the layers panel.

And that order is the reverse of what everyone wants.
9/n

There are lots of ways we could "fix" this, with various tradeoffs.
1) For Auto Layout frames, we could display the layers in reverse order, which would "fix" the problem visually.

But the cost would be that the order of children in the JS API wouldn't match.
10/n

2) We could make it so that Auto Layout frames lay out their last child at the first position (left, top) and then work backwards through their children.

This (a) makes plugin authoring weird, and (b) introduces lots of internal headaches in our code.
11/n

I'm sure there are other ways to "fix" it for children of Auto Layout frames, but I think they all have weird compromises.

And even then... things are still weird for the non-Auto Layout case of people who want to use Figma to create slides.
12/n

So my favorite solution (just personal opinion... we haven't agreed to this yet as a team) is to introduce a new concept, which is that maybe we should reconsider the traditional ordering of items in the layers panel.
13/n

It seems crazy that something higher in z-order would be lower in the layers panel, but what if we reconceptualized what this panel is?

What if we called the two orders

* Traditional ordering
* DOM ordering
14/n

Traditional ordering is what is used by traditional design tools. Highest z-index goes on top.

DOM ordering is what is used by browser tools. The first child of an element (which is usually the lowest z-index) is displayed first.
15/n

If you chose to see the layers panel in DOM order, then duplicating "item 4" would create an "item 5" which was below the original item in the layers panel (and above the item in z-order on the canvas).

This would fix both Auto Layout and non-Auto Layout cases.
16/n

But because this is such a big change from traditional design tooling, it would have to be a preference. And we all know that introducing new preferences comes at a cost.

Which is just one of the reasons we haven't added this (yet).
17/n

P.S. It is entirely possible that Marcin or someone will think of a brilliant solution I haven't thought of yet. :-)
18/18