As we all know, as of today, the “Fix position when scrolling” option is available only for (A) direct children layers of main frames in Figma, as long as (B) they’re not auto-layout frames and (C) they’re not main components or components instances.
Here’s a quick video to make sure we’re all on the same page.
While A & B requirements are easy for me to accept and understand (though it’s a pity that we don’t have “fix position” in auto-layout frames), the last one, C, is not so much. Let me explain why.
Sadly, an important and currently unsupported use case for having the “Fix position when scrolling” option inside components instances used as top-level frames in Figma is creating components out of entire pages or app views containing fixed elements.
Why would I want to turn entire pages or app views into components? Because thanks to this approach, when building an extensive prototype operating within the same app view, I can rest assured that when I need to introduce subtle changes to the core app view design, I don’t have to go through all the frames I already laid out for my prototype and apply the same changes for each of them, one-by-one. Which, as I’m sure we can all imagine, can be a very tedious and time-consuming process, potentially leading to making tons of errors along the way.
However, the current tradeoff is giving up on having elements with a fixed position when scrolling. Because it’s not supported in components. This, in turn, comes with a significant loss to the prototype fidelity. And that’s why I’m here today.
I’m creating this thread hoping to:
- See if there’s anyone else feeling this way and, if so, raise the awareness or shed more light on the significance of this issue,
- If I’m lucky, get some behind-the-scenes explanation on why this has to be this way,
- Perhaps some exchange some tips with the community on potential workarounds.
Looking forward to hearing your thoughts on this!
Yikes. Really hard to believe this is a constraint. This is a real problem inside more complex components (yet still much smaller than patterns or whole screens). For example, in my Bottom Sheet component, there’s no way to maintain a fixed header, a fixed footer, and a scrollable content area in the middle (because of the extensive autolayout + nested components structure).
I have just encountered exactly the same problem and now I have some very practical and fast wireframes made with autolayout but I can’t make a working prototype with them.
Same thing is happening to me also. There is no way to have a fixed position for headers or other elements and that means there’s no way to prototype the design to clients, I have to start explaining the concept.
I think I just solved the problem.
@Adam_Przewoski @ziad_ismail @Filipp @Greg_Smith @Eli_Capdevila @Paul43 Try this:
“Set the Component on Figma right tool bar / Prototype / Overflow scrolling to Vertical scrolling (Which with the Top Navbar. Or with Bottom Tabbar together)”
It works! My Top Navbar fix on top and Bottom Tabbar fix on bottom when I scrolling my instance on prototype mode!
That’s a lot of restrictions. I tend to autolayout everything, and if I remove it it breaks a lot of things, especially autolayout instances. I thought it would be a very basic and obvious functionality.
Same boat here. I am creating a large DS library for web components, and I set one “sticky nav bar” variant set to “fix position when scrolling”, and the constraints to top/left. When I insert the component instance in to a prototype (auto layout frame containing a series of web components to create a web page), the sticky nav bar loses it’s fix position.
I can not for the life of me figure out why this is, or how to solve it, but after reading other posts, it seems to be an issue.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.