Improve the New Position Sticky Implementation

Am I the only one who’s left wanting by the new position sticky feature?

In my opinion, there are three main problems with the new sticky feature:

  1. It’s not compatible with auto layout
    • SolutionMake the sticky elements always appear on top of other elements (and later add a z-index feature so we can fine tune the behavior)
  2. The sticky element has to be an immediate child of the scrolling container
    • SolutionMake the sticky behavior relative to the closest scroll container instead, so the sticky element can be a grand child, great grand child etc.
  3. Only works for vertical scrolling and can only stick to the top of the container
    • SolutionAdd an offset property (top/right/bottom/left) - like the CSS implementation - super simple, but pretty flexible (only problem with the CSS implementation is the overflow: hidden limitation)

What I want to be able to make

None of which is possible with the new sticky feature unfortunately

HTML prototype

  • Note the sticky footer inside the container
  • Note that the elements stick relative to the window’s scroll position - it doesn’t care that the sticky element is far down the DOM tree
  • Check out the Codepen here

Figma prototype

  • This, only with auto layout

Sticky on larger screens (multiple columns etc + support for sticky in components)

  • I actually am working on a layout a bit like this (two columns with multiple sections in each). Being able to more accurately prototype it would be gold!
  • I would like to be able to create one component for each section. Within that component, I would then like to set the section heading to sticky

Edit: I initially just wanted to start a discussion and rant about how the new position sticky feature was implemented, but as the post was moved from “general discussions” → “share an idea” section, I felt the need to amend my post. I hid the rant below :stuck_out_tongue:

Just me ranting about how I'm disappointed by the way Figma implemented position sticky

Figma, why do you mock us so? (Position sticky discussion)

Yesterday Figma announced a lot of really nice quality of life improvements in their Little Big Things update. All good stuff, but the only thing that got me personally (very) exited was the position sticky feature.

Am I the only one who’s left utterly disappointed?

I thought Figma were committed to the auto layout feature, so why do they mock us so? Position sticky is in no way compatible with auto layout! (1)

The best I could do with position sticky:

  • Notice the oversized containers (colorized). They have to be that tall to make the element stick beneath the sticky tabs
  • The first element sticks nicely, but it will overlay any other sticky layer below it

They can probably fix this issue by just rendering sticky elements above the rest or something, but there is also another, bigger problem.

Problem 2

The biggest problem with the new sticky feature is a more fundamental implementation detail, which I suspect they won’t fix - thus, making me very pessimistic as to the usefulness of the feature (and it’s future). The problem:

You can only set position sticky if the immediate parent container is a scrolling container

This means that if you want to take advantage of position sticky, you have to have a totally flat layer structure - which again, is not compatible with auto layout! Or even components for that matter! (3)

The fact that the direct parent has to be a scrolling container, has always been the case for fixed elements, which has been an ok limitation (3) since fixed elements are detached from the layout flow.

Sticky elements on the other hand is a part of the layout flow, and is only detached from the flow just before it is scrolled out of the viewport. Them being a part of the layout also means that they has to be part of the auto layout, which is probably several layers deep due to how auto layout works.

Foot notes

(1) This is a bit of an over exaggeration. I know position sticky technically is compatible with auto layout, but due to auto layout’s strict z-index hierarchy everything will overlap the sticky element. “Just switch the canvas stacking”, you say? Then the next sticky element will be overlapped by the first element…

(2) When using auto layout you will end up with a deeper layer structure than you would without. This is because you have to the paddings and gaps on the auto layout containers, and in order to have different spacings, you need more and nested auto layout containers. This is perfectly reasonable and a boon to the structure and organization of files. It also makes the mental model of designing within Figma more like the mental model when writing the code.

(You can maybe get away with a flat auto layout structure on mobile mockups sometimes, but on desktop mockups it’s almost never the case).

(3) It’s been an ok limitation, at least after the position absolute feature was released and we could combine position fixed with auto layout.


Notes

I know that implementing position sticky is probably very tricky. But I think this is one of the cases where doing it right or not doing it at all would have served you better.

Figma has again and again spent the time to do it right, which makes me all the more disappointed this time around. It’s been so exiting to read the Figma blog on why seemingly easy to implement features are anything but.

I suspect there won’t be any such blog posts about position sticky :frowning:

Anyhow; I just wanted to put this rant out there. Please drop a comment if you agree/disagree. Would be nice to have a discussion about this.

Either way, have a good one! :smiley:

5 Likes

I agree that it must also work with the auto layout, but it is one giant step forward. Finally, I can stick element after scroll! I love you, Figma!

1 Like

Thanks for the feedback @Viktors!

We’ll pass this feedback along to the team and merge your reply with another similar topic, so the community can continue to add their feedback and vote for improvements.

1 Like

With the much anticipated release of sticky elements in prototyping, one improvement stands out as being needed to really make this a game changing feature.

If you have a fixed header with sticky elements underneath it, that fixed header will overlap on top of any sticky elements, but it would be great if sticky elements would stick below any fixed items inside a frame rather than at the top of the frame.

In the below example, the grey bar represents something like a top bar within a native application, and the coloured bars could be section headers, content blocks, etc.

The workaround is to artificially increase the height of the sticky component to include the ‘dead space’ where any fixed element will overlap with it, but this is clunky and adds a lot of extra overhead when creating prototypes, especially when using auto layout.

1 Like

I agree that this is a problem, that’s why I proposed adding an offset attribute (problem 3 → solution).

[…] it would be great if sticky elements would stick below any fixed items […]

I think we might need a manual solution to this. If they just made items stick beneath the fixed elements, what would happen if you had a fixed element in the middle of the screen? Or a fixed bottom app bar?

Do you think an offset value would solve your problem?

1 Like

It is a giant step forward indeed, and I’m really happy that they have taken the time to work on it!

I’m just concerned that they have implemented it with a too narrow use case, and that they are digging a hole - implementation wise - that will keep the use case too narrow (without major rewriting) :frowning:

I was so excited about this feature, but especially for stacked content and lists (which is where I imagine most people are using the sticky feature) I don’t know how you could not use auto-layout. I had to look through the forums to realise that the reason it was doing funny things for me was because I was using auto layout :sweat_smile:

In other words, +1 from me!!

2 Likes

Nice feature! However when I make my frame that has a horizontal scrolling in it, stick to the top, somehow the horizontal scrolling doesn’t work anymore.

2 Likes

would love to see this feature evolve
maybe adding “sticky to parent” or “choose element to stick to”

2 Likes

It’s a step in the right direction but still not quite there to make it integral to my workflow, in my opinion.

Two things I feel would give this feature more parity with the CSS ‘position: sticky’ property:

  1. The ability to enable this for any element to stick to its parent regardless of frame overflow (this would make it useful for compositions using auto layout)

  2. The ability to specify an offset amount from the top of the viewport (not dissimilar to the properties found in the ‘Scroll To’ prototype interaction).

2 Likes

Interactions inside a group that is sticky do not get sticky. They scroll with the parent. While the whole group (in my case, a component for a navigation menu) gets sticky, the “interactive areas” scroll with the parent, making my navbar unusable.

The new sticky/fixed features are really useful - however it would be great if you could limit these features to within a certain frame.

Because you can’t control the end point you just have your fixed content overlapping content below it…

Thank you all for the feedback!

We passed this thread onto the team who will be working on a few improvements for the near future.

+1 !!!
I feel exactly the same way.

  1. Relies on all elements being on the same level. Which is contrary to Figma telling us to use auto layouts and frames. WTF
  2. The Sticky elements naturally fall underneath the ones that scroll. Another WTF. Why not z-index the sticky elements to stay on top. This is CSS 101.

I like and appreciate the updates but they are simply useless in 99% of all professional use cases. It’s like the figma is run by people that haven’t worked in corporations or large companies where speed, robust design systems and user empowering prototypes are the way to communicate ideas and iterate from user feedback. (We don’t all have the privilege of having a dedicated front end dev on hand.) Axure kicked so much ass with variables and dynamic panels. If Figma could simply educate their staff on Axure mechanics, they could avoid these launch feature problems they keep having. Axure, Principle, Framer…please learn these first!!! We need some old school veteran designers up in there.

I totally agree with all this. I build everything with Auto Layout and immediately ran into issues with ‘sticky’, needing to extract the component from the flow of elements, and then needed to modify it to add some dead space on top for it to hit below the fixed header.

Excited for the feature(s), but not implemented well.

Please add the function to make the sticky item stop being sticky on a certain level after scrolling.

2 Likes

Hey @Teodor_Gatu,

We’ve moved your comment to a more relevant feature request topic. Our team is already monitoring this thread for future improvements.

1 Like

I’m a 100% with you on that one. It’s why I’m so frustrated about the fact that the sticky element has to be an immediate child of the scrolling container.

If we could have sticky elements that’s not immediate children of the scrolling container, the elements could stop sticking when the parent container is scrolled past the viewport. (Just like the CSS implementation).

And I think Figma messed it up…

Let’s go through some pains:

  • sticky behaviour doesn’t work with AutoLayout
  • in order to create it you need to:
  1. Create a Frame
  2. Reduce the height
  3. Apply Content clip
  4. change scroll behaviour to “Scroll (vertically)”
  5. place elements on the Frame (no auto layout)
  6. select some and apply Sticky to them

I was waiting for sticky elements for such a long time and it’s a complete fail.
Everything in my projects is Auto Layout, I’ve mastered it, and know how to nest and work with it to get almost 100% results as if it was implemented with HTML/CSS

Let’s imagine that I have something like this: Figma sticky elements doesn't work with Auto Layout - YouTube (video might still processing)

There’s no way to do it. And it my video above you can see how to set up a mobile view which is 100% auto layout and it scrolls nicely with a fixed header and footer.

There’s a room next to “Clip content”, or, what I just saw, you moved “Fix(ed) position” below the Auto Layout to the Prototype tab. Ugly surprise. Sticky is either true/false, and can be top/left/right/bottom.

Sorry Figma people, sticky headers are unfortunately trash :slight_smile: but lots of hugs and kisses for other updates.

Still waiting for navigating between pages in prototyping! :heart:

1 Like

and if you make an update related to prototyping, answer these questions:

  • will it work with components (and variants)
  • will it work with auto layout
  • will it work with multiple ways of setting up a scrolled view (fixed header/footer as it usually works in mobile apps)
  • how deep I can nest it?
  • how it will affect the Figma interface that people are used to?
2 Likes