Warum Figmas Auto Layout nach dem Import einer Webseite verrutscht

Eine Kartenreihe, die im Browser bündig saß, kommt in Figma mit einer Karte vier Pixel zu tief an. Nichts ist kaputt genug, um darauf zu zeigen. Hier steht, was tatsächlich passiert ist.

Du importierst eine Webseite nach Figma, das Ebenen-Panel füllt sich, und irgendetwas stimmt nicht. Eine Kartenreihe, die im Browser bündig saß, hat jetzt eine Karte, die vier Pixel zu tief hängt. Eine zentrierte Navigation ist ungefähr zentriert. Nichts davon ist kaputt genug, um darauf zu zeigen, aber die Datei passt nicht mehr zu dem Screenshot, den du daneben offen hast.

Fast immer steckt Auto Layout dahinter, angewendet an einer Stelle, wo es nicht hingehört. Es lohnt sich zu verstehen, warum das passiert, denn die Lösung heißt nicht „Auto Layout ausschalten". Sie heißt: erkennen, wann die beiden Layout-Systeme wirklich übereinstimmen und wann ein Werkzeug rät.

Zwei Layout-Engines, die nie zueinander passen sollten

Ein Browser setzt eine Seite mit CSS. Flexbox, Grid, Floats, Inline-Fluss, kollabierende Margins, line-height, das Text aus seiner eigenen Box drückt, Subpixel-Rundung, die je nach Plattform anders ausfällt. Jahrzehnte an Regeln, und die meisten davon sind Sonderfälle, die genau einmal wichtig werden.

Figma setzt einen Frame mit Auto Layout. Ein deutlich kleineres System, und zwar absichtlich: eine Richtung, ein Abstand, vier Padding-Werte, Ausrichtung auf zwei Achsen, pro Kind ein Grow und ein Stretch. Viel mehr ist es nicht.

Auto Layout ist keine Neuimplementierung von Flexbox. Es ähnelt Flexbox so, wie ein Fahrrad einem Motorrad ähnelt. Wenn ein Konverter also display: flex liest und layoutMode: "HORIZONTAL" setzt, stellt er eine Behauptung auf: Diese beiden Systeme werden jedes Kind an dieselbe Stelle setzen. Manchmal stimmt das. Oft stimmt es beinahe, und das ist schlimmer.

Wo die beiden still auseinandergehen

Ein paar konkrete Fälle, die alle nach Flexbox aussehen und die Auto Layout nicht reproduziert.

• Margins an Flex-Items. In CSS trägt ein Kind seine eigene Margin, bis hin zu margin-left: auto, um eine Gruppe nach rechts zu schieben. Auto Layout hat einen Abstand für den ganzen Frame und pro Kind gar keine Margin.
• space-around und space-evenly. Auto Layout kennt SPACE_BETWEEN. Die anderen beiden verteilen den übrigen Platz anders, und dafür gibt es keine Einstellung.
• align-items: baseline. Unterschiedlich große Schrift auf einer gemeinsamen Grundlinie, wie in Überschriften und Preiszeilen üblich. Auto Layout richtet an Boxkanten und Mitten aus, nicht an Grundlinien.
• Gebrochene flex-grow-Werte. flex: 1 landet auf layoutGrow: 1. Für flex: 2 und flex: 0.5 gibt es kein Ziel.
• flex-wrap. Eine umbrochene Reihe hat eine andere Geometrie als eine einzeilige, und wo sie umbricht, hängt an der Containerbreite im Moment der Aufnahme.
• Textneuvermessung. Daran scheitern Werkzeuge am häufigsten. Eine Textebene, die sich an ihren Inhalt anpasst, wird von Figma selbst vermessen, mit der Schrift, die Figma hat, in der Größe, die Figma berechnet. Weicht das auch nur um einen Pixel vom Browser ab, verschiebt sich jedes Geschwisterelement dahinter im Stapel.

Wegen des letzten Punktes taucht das Problem oft erst auf, nachdem du eine fehlende Schrift installiert hast, oder nur auf dem Rechner von jemand anderem.

Warum Konverter es trotzdem anwenden

Weil eine Datei voller Auto-Layout-Frames nach einem besseren Produkt aussieht als eine Datei voller absolut positionierter Rechtecke. Das macht sich in der Demo gut und ergibt einen Punkt auf der Funktionsliste. Im Normalfall, also bei einer schlichten Reihe oder einem Kartenraster mit gleichmäßigen Abständen, ist es auch wirklich besser: Du kannst den Frame skalieren, und er verhält sich vernünftig.

Der Haken ist, dass ein Werkzeug den Normalfall nicht vom knappen Danebenliegen unterscheiden kann, ohne nachzumessen. Und Nachmessen ist mehr Arbeit als Nichtmessen.

Was du tun kannst

Wenn schon importiert ist

Nimm den Frame, der falsch aussieht, und setze seinen Layout-Modus auf keinen. In Figma steht das im Layout-Bereich der rechten Leiste. Die Kinder behalten ihre aktuellen Positionen — wenn die Verschiebung also schon passiert ist, frierst du sie damit ein, statt sie rückgängig zu machen. Deshalb ist neu importieren meist der bessere Weg als reparieren.

Prüf vorher eine Sache: Sind die Schriften, die die Seite verwendet hat, auf deinem Rechner überhaupt installiert? Eine ersetzte Schrift vermisst jede Textebene neu, und keine Layout-Fummelei rettet eine Datei, deren Text die falsche Breite hat. Figma sagt dir beim Öffnen, welche Schriften fehlen.

Wenn du noch ein Werkzeug aussuchst

Frag, was es tut, wenn die beiden Systeme auseinandergehen. Es gibt drei mögliche Antworten, und nur eine davon taugt.

1. Überall Auto Layout setzen, wo Flexbox erkannt wird. Schnell, gut für die Demo, und du bekommst eine Datei, die sich still verschoben hat.
2. Nie setzen. Immer korrekt, nie brauchbar. Du bekommst einen Haufen absolut positionierter Ebenen, exakt und mühsam zu bearbeiten.
3. Nur dort setzen, wo es das Original reproduziert. Korrekt und brauchbar, verlangt aber, dass das Werkzeug tatsächlich vorhersagt, was Figma tun wird, und vergleicht.

Wie Snapture entscheidet

Snapture nimmt die dritte Variante, und der Mechanismus lässt sich in einem Absatz beschreiben.

Zum Zeitpunkt der Aufnahme weiß es bereits, wo jedes Element sitzt, denn es hat die gerenderte Seite gelesen und besitzt für jedes Kind das echte, vom Browser berechnete Rechteck. Bevor ein Layout gesetzt wird, simuliert es, was Figmas Engine mit demselben Frame täte: Padding, Abstand, Ausrichtung, Verteilung des Grow. Daraus entsteht pro Kind ein vorhergesagtes Rechteck. Dann werden beide Mengen verglichen. Landet jedes Kind innerhalb von einem halben Pixel dort, wo der Browser es hatte, wird das Layout gesetzt. Weicht auch nur eines ab, behält der ganze Frame exakte absolute Koordinaten.

Auf der anderen Seite steht eine zweite Prüfung. Nachdem das Figma-Plugin das Layout angewendet hat, misst es die Kinder erneut, diesmal gegen die echte Engine statt gegen eine Vorhersage. Hat sich etwas über denselben halben Pixel hinaus bewegt, fällt der Frame auf die aufgenommenen Koordinaten zurück. Diese Prüfung gibt es, weil eine Textebene beim Import auf eine Weise neu vermessen werden kann, die keine Simulation vorhersieht.

Wie das in der Praxis aussieht

Lässt man den Konverter auf echte Seiten los, bekommt man ein Gefühl dafür, wie wählerisch er ist. Die Zahlen stammen aus derselben Messreihe wie auf der Messseite.

Interessant ist die MDN-Zeile. Fünf Auto-Layout-Frames auf 253 Knoten sieht nach einem Versagen des Werkzeugs aus. Es ist das Werkzeug bei der Arbeit: MDNs Artikel-Layout besteht größtenteils aus Dokumentfluss und Floats, was Auto Layout überhaupt nicht abbildet. Also hat die Schranke fast alles abgelehnt und exakte Positionen behalten. Für diese Seite ist das der richtige Handel.

Linear dagegen ist fast vollständig aus Flex-Reihen mit gleichmäßigen Abständen gebaut. 261 seiner Frames überstehen den Vergleich wirklich, und die verhalten sich in Figma richtig, wenn du sie skalierst.

Kurz gesagt

Auto Layout nach einem Import ist nur dann vertrauenswürdig, wenn etwas es überprüft hat. Flexbox und Auto Layout überschneiden sich genug, um einen Konverter zu täuschen, und unterscheiden sich genug, um deine Datei zu verschieben. Der Unterschied zeigt sich meist als ein paar Pixel statt als offensichtlicher Bruch, und das ist genau die Sorte Fehler, die am meisten Zeit kostet.

Kann ein Werkzeug nicht sagen, was es tut, wenn die beiden auseinandergehen, dann prüft es nicht.

English · 한국어 · 日本語 · 简体中文 · 繁體中文 · Español · Português · Français · Deutsch · Русский · Italiano · Bahasa Indonesia