Slots don't respect nested component's fill values?

That would be wonderful. Im always bummed when I insert a preferred instance and its the default variant that doenst fit at all..

I think the key here is that the slot itself is treated as it’s own dom element. Ideally, slots would be more like React Fragment — they aren’t actually a layout element. This would allow children of the slot to inherit the parent component properties instead of inheriting the slot’s properties.

e.g.

(1) As of now slots are actually grandchildren of the component
(2) If slots where just an indication of where in the component’s immediate children elements can be placed, the elements would be positioned relative to the component instead of the slot
 

The problem is, this isn’t how the containers in code would work, so now we have to do hacky stuff to get it to work properly, like setting up a nested component that doesn’t exist in code. I’m trying to set up a two column checkbox group where the individual checkboxes should fill the parent container (aka the column). The slot ones are set to fill, but when you add new ones, they are inserted as the original checkbox size (bottom one), not the size in the group component (top one).
 

Cannot select a variant as a preferred instance. Kind of a drag as designers would only know there is a specific variant to be used by documenting it in written word. A preferred variant instance would clear up the communication without so much documentation.

This ⬆️ 

Adobe put another one nail into the Figma’s coffin by releasing the Slots feature which is an “Alpha” state. I have never seen such a failure of how to ruin a good idea by releasing such an unstable piece of software. Claude Design will shut down this circus quite soon. Great job!

-1 year ago - I have no words TBH.

I think the key here is that the slot itself is treated as it’s own dom element. Ideally, slots would be more like React Fragment — they aren’t actually a layout element. This would allow children of the slot to inherit the parent component properties instead of inheriting the slot’s properties.

e.g.

(1) As of now slots are actually grandchildren of the component
(2) If slots where just an indication of where in the component’s immediate children elements can be placed, the elements would be positioned relative to the component instead of the slot
 

 

I think too much depends on the slot and it has so many of its own features.

Maybe there’s something to what you are saying - you mean kind of a “logical” element rather than a real one? But then, if you have options on the slot, which element takes them over for actual production? What I mean - even if this isn’t really clear how it behaves - it might be a problem e.g. for AI or even a human developer (I am currently checking how Claude Code will treat it, probably as a div, just like that), will also check Figma Make.

A slot should be as simple as a frame in a component. It should have the ability to provide auto layout context. Without it, it’s a non-starter for the system. Our entire design system assumes responsive components – Basically, it should be be a flexbox container when autolayout is on. 

We should be able to apply any padding, fills, strokes, radius styles that you can apply to a frame. We use token studio, but I’d assume variables and manual controls all do the same thing. 

I understand all of this, but the lack of inheritance for `Fill` with the “+” slot causes OBVIOUS PROBLEMS... Essentially, this renders the slot function useless in most cases where it was actually needed.