CSS Position in Figma: Static, Relative, Absolute, Fixed und Sticky

CSS kennt genau fünf Werte für die Eigenschaft position: static, relative, absolute, fixed und sticky. Figma kennt keinen davon. Was Figma stattdessen hat, ist auto layout, die Option, eine Ebene das auto layout ignorieren zu lassen, und ein Set von Resize-Constraints. Jedes davon deckt einen anderen Teil dessen ab, was position im Browser tut. Wer schon einmal eine Seite importiert hat und sich gefragt hat, warum eine sticky Sidebar als reine static Ebene gelandet ist, findet hier die Antwort.

Diese Lücke zeigt sich am häufigsten in drei Situationen: beim Redesign einer Seite, die nie eine Designdatei hatte, beim Zerlegen der Seite eines Wettbewerbers, um zu sehen, wie sie gebaut ist, und beim Nachbau einer alten Seite, deren ursprünglicher Quellcode nicht mehr existiert. In allen drei Fällen sind die Ebenen, die man zurückbekommt, nur so nützlich wie das eigene Verständnis davon, welches CSS-Verhalten jede einzelne einmal hatte. Figma hat keine Möglichkeit, diese Information auf der Zeichenfläche selbst zu speichern.

Diese Referenz geht alle fünf Werte durch, erklärt, was jeder davon laut MDN und der CSS Positioned Layout Spezifikation tatsächlich bewirkt, und welcher Figma-Mechanismus, falls vorhanden, dieselbe Rolle übernimmt. Am Ende steht eine Eigenschaft-für-Eigenschaft-Referenztabelle zum schnellen Nachschlagen, aktuell mit Stand 2026, während das CSS Positioned Layout Module Level 3 weiterhin die maßgebliche Definition für alle fünf Werte bleibt.

Static und Relative: Die Beiden, Die Layout-Platz Reservieren

position: static ist der Standardwert. Kein Element muss ihn deklarieren, und einmal deklariert, haben top, right, bottom, left und z-index überhaupt keine Wirkung. Das Element sitzt genau dort, wo der normale Dokumentenfluss es platziert.

position: relative bleibt ebenfalls im normalen Fluss, kann aber mit top, right, bottom und left verschoben werden. Die Verschiebung ist rein visuell. Der Platz, den das Element an seiner unverschobenen Position eingenommen hätte, bleibt im Layout reserviert, sodass kein anderes Element auf der Seite nachrückt, um die Lücke zu füllen.

Die nächstliegende Entsprechung in Figma für beide ist der Standardzustand einer Kind-Ebene innerhalb eines auto layout Frames. Eine Ebene, der nicht gesagt wurde, das auto layout zu ignorieren, folgt den Layout-Regeln ihres übergeordneten Frames genauso, wie ein static oder relative positioniertes Element dem normalen Fluss folgt, und behält dabei ebenso ihren reservierten Platz. Es gibt in Figma keinen eigenen "static"- oder "relative"-Schalter, weil auto layout dieses Verhalten bereits standardmäßig annimmt. Für die flex-spezifische Seite dieser Zuordnung geht CSS Flexbox to Figma Auto Layout justify-content, align-items und gap Eigenschaft für Eigenschaft durch.

Absolute Positioning: Containing Blocks in CSS vs. Ignore Auto Layout in Figma

position: absolute nimmt ein Element vollständig aus dem normalen Fluss heraus. Es wird relativ zum nächsten Vorfahren positioniert, dessen eigenes position nicht static ist, oder relativ zum initial containing block der Seite, falls kein solcher Vorfahre existiert. Für das Element wird nichts im Layout reserviert, und sofern kein width oder height gesetzt ist, richtet es sich in der Größe nach seinem Inhalt.

Die Figma-Entsprechung dafür ist eine Ebene, die das auto layout ignoriert, in der Plugin-API als layoutPositioning: ABSOLUTE ausgestellt. Die Ebene bleibt innerhalb ihres übergeordneten Frames verschachtelt, erhält aber explizite Werte für x, y, width und height, statt den Layout-Regeln des Elternteils zu folgen. Das ist derselbe Tausch, den auch CSS eingeht: weiterhin innerhalb einer umschließenden Struktur, aber nicht mehr von ihr gesteuert. Figmas eigenes Constraint-System (left, right, top, bottom, center, scale) steht erst zur Verfügung, sobald eine Ebene das auto layout ignoriert hat, was widerspiegelt, wie ein absolute positioniertes CSS-Element seine Offsets weiterhin relativ zu einem containing block misst, auch nachdem es den Fluss verlassen hat.

Nicht jeder importierte Frame lässt sich sauber in auto layout überführen. Wenn die erfasste Geometrie sich so nicht wiederherstellen lässt, etwa bei überlappenden Geschwisterelementen oder einem Layout, das von Skripten statt von CSS gesteuert wird, fällt UnHTML für diesen Frame von sich aus auf absolute positioning zurück. Das Ergebnis ist nie schlechter als eine einfache Ebene-für-Ebene-Kopie dessen, was die Seite gerendert hat.

Absolute positioning in CSS ist auch der Mechanismus hinter den meisten Badges, Tooltips und modalen Overlays, da keines dieser Elemente beim Erscheinen umliegenden Inhalt verdrängen sollte. Dasselbe gilt in Figma, sobald eine Ebene das auto layout ignoriert: Sie kann über ihrem übergeordneten Frame oder teilweise außerhalb davon liegen, ohne die Position irgendeiner Geschwister-Ebene zu verändern. Der Unterschied ist, dass ein CSS-Element, das nur nach seinem Inhalt bemessen wird, je nach Inhalt jede beliebige Breite annehmen kann, während eine Figma-Ebene in dem Moment, in dem sie platziert wird, immer eine explizite width und height trägt, mit oder ohne auto layout. Das ist eine der kleinen, aber realen Lücken, die ein Importbericht aufdecken soll: Ein Element mit width: auto auf der Ursprungsseite wird in Figma zu einer einzigen festen Zahl, gültig zum Zeitpunkt der Erfassung, nicht zu einer Regel, die sich laufend neu berechnet.

Fixed Positioning: Verankerung am Viewport und Warum Figma Scrollen Nicht Simulieren Kann

position: fixed verhält sich wie absolute, mit einem Unterschied. Sein containing block ist das Viewport selbst, oder ein Vorfahre mit einer transform-, perspective- oder filter-Eigenschaft, die etwas anderes als none ist. Ein fixed Element bewegt sich nicht, wenn die Seite gescrollt wird, und in paginierten Medien wiederholt es sich identisch auf jeder Seite.

Figma hat dafür keine Entsprechung, weil ein Figma-Frame kein scrollbares Viewport ist. Es gibt nichts, woran man sich verankern könnte, da unter der Ebene ohnehin nichts scrollt. In der Praxis ist es am saubersten, eine fixed Navigationsleiste oder eine dauerhaft sichtbare Fußzeile nach dem Import als eigenen Frame auf oberster Ebene zu behandeln, statt zu erwarten, dass sie in den Haupt-Stack des auto layout der Seite passt, und das Scrollverhalten anschließend im Code wiederherzustellen.

Die zwei häufigsten fixed positionierten Elemente auf einer echten Seite sind eine obere Navigationsleiste und ein Cookie- oder Einwilligungsbanner. Beide werden meist an einer visuell korrekten Stelle importiert, obwohl das zugrunde liegende CSS-Verhalten verloren geht. Es lohnt sich, das gegenüber wem auch immer den endgültigen Nachbau übernimmt anzumerken: Die Ebene sieht an der Scroll-Position, an der die Seite erfasst wurde, richtig aus, aber nichts in der Figma-Datei hält fest, dass sie eigentlich an jeder anderen Scroll-Position ebenfalls dort bleiben sollte.

Sticky Positioning: Der Wert Ohne Figma-Entsprechung

position: sticky ist der kniffligste der fünf Werte. Es verhält sich wie relative, bis der Nutzer über eine definierte Schwelle hinaus scrollt, und fixiert sich dann an einer Position innerhalb des nächsten scrollbaren Vorfahren. Es braucht mindestens einen nicht-auto-Wert bei top, right, bottom oder left auf einer gegebenen Achse, um überhaupt aktiv zu werden. Laut der CSS Positioned Layout Spezifikation verschiebt sich das Element, wenn nur top gesetzt ist und bottom auf auto bleibt, immer nur nach unten, nie nach oben. Wie relative reserviert es seinen Layout-Platz, anders als absolute und fixed, die das nicht tun.

Auf einer Figma-Zeichenfläche gibt es keine Scroll-Simulation, sodass ein sticky positioniertes Element jedes Mal als static Ebene importiert wird. Das ist kein Fehler in der Konvertierung. Es ist eine strukturelle Lücke: Figma-Frames scrollen nicht so, wie es ein Browser-Viewport tut, also gibt es nichts, woran eine "bleib hier"-Anweisung andocken könnte. Der Importbericht ist die Stelle, an der man nach position: sticky-Deklarationen suchen sollte, die neu verdrahtet werden müssen, sobald das Design zurück in den Code geht.

Sticky Tabellenköpfe und sticky Abschnittsnavigation auf langen Dokumentationsseiten sind die zwei Fälle, in denen das am häufigsten auftaucht, da beide darauf angewiesen sind, dass das Element erst sichtbar bleibt, nachdem der Nutzer eine bestimmte Strecke gescrollt hat, und nicht schon vom Seitenanfang an. Wer nur die importierte Figma-Datei durchsieht, kann allein anhand des Aussehens nicht erkennen, dass der Tabellenkopf eigentlich dafür gedacht war, sich von seiner Zeile zu lösen und oben im Viewport zu schweben. Der Abgleich des Importberichts mit der Live-Seite, oder mit dem ursprünglichen CSS, sofern noch verfügbar, ist die einzig verlässliche Methode, um jede sticky-Deklaration vor dem Launch des Nachbaus zu erfassen.

CSS Position zu Figma: Eine Eigenschaftsreferenztabelle

Grid-basierte Layouts werfen eine verwandte, aber eigenständige Frage auf. CSS-Grid-Eigenschaften wie grid-template-columns und grid-area haben mit position überhaupt nichts zu tun. CSS Grid to Figma: What Survives the Conversion to Layers behandelt diese Zuordnung im selben Eigenschaft-für-Eigenschaft-Format.

Fazit

Figma hat keine position-Eigenschaft, aber vier der fünf CSS-Werte haben trotzdem eine funktionierende Entsprechung. Auto layout deckt static und relative ab, das Ignorieren von auto layout deckt absolute ab, und ein eigener Frame auf oberster Ebene ist die praktische Antwort für fixed. Sticky ist die einzige echte Lücke, weil nichts in Figma auf ein Scroll-Ereignis reagiert. Wenn sich eine Konvertierung nicht sauber durchführen lässt, ist es richtig, auf absolute positioning zurückzufallen statt zu raten, und das im Importbericht festzuhalten, damit nichts stillschweigend verloren geht.