Pourquoi l'Auto Layout de Figma se décale après l'import d'une page web

Une rangée de cartes bien alignée dans le navigateur arrive dans Figma avec une carte quatre pixels trop bas. Rien n'est assez cassé pour le pointer du doigt. Voici ce qui s'est passé.

Vous importez une page web dans Figma, le panneau des calques se remplit, et quelque chose cloche. Une rangée de cartes qui était bien alignée dans le navigateur a maintenant une carte quatre pixels trop bas. Une navigation centrée est à peu près centrée. Rien n'est assez cassé pour qu'on puisse le pointer du doigt, mais le fichier ne correspond plus à la capture que vous avez laissée ouverte à côté.

C'est presque toujours l'Auto Layout, appliqué là où il n'aurait pas dû l'être. Comprendre pourquoi vaut le détour, parce que la solution n'est pas « désactiver l'Auto Layout » : c'est savoir quand les deux systèmes de mise en page tombent vraiment d'accord et quand un outil devine.

Deux moteurs de mise en page qui n'étaient pas faits pour s'accorder

Un navigateur dispose une page avec CSS. Flexbox, grid, floats, flux en ligne, marges qui fusionnent, un line-height qui pousse le texte hors de sa propre boîte, des arrondis sous-pixel qui diffèrent selon la plateforme. Des décennies de règles, dont la plupart sont des cas particuliers qui ne comptent qu'une fois.

Figma dispose un frame avec l'Auto Layout. Un système bien plus petit, et volontairement : une direction, un espacement, quatre valeurs de padding, un alignement sur deux axes, et par enfant un grow et un stretch. C'est à peu près tout.

L'Auto Layout n'est pas une réimplémentation de flexbox. Il ressemble à flexbox comme un vélo ressemble à une moto. Alors quand un convertisseur lit display: flex et pose layoutMode: "HORIZONTAL", il avance une affirmation : ces deux systèmes placeront chaque enfant au même endroit. Parfois c'est vrai. Souvent c'est presque vrai, ce qui est pire.

Là où les deux divergent sans prévenir

Quelques cas concrets, qui ressemblent tous à du flexbox et qu'aucun Auto Layout ne reproduit.

• Les marges sur les items flex. En CSS un enfant porte sa propre marge, y compris margin-left: auto pour pousser un groupe à droite. L'Auto Layout a un seul espacement pour tout le frame et aucune marge par enfant.
• space-around et space-evenly. L'Auto Layout connaît SPACE_BETWEEN. Les deux autres répartissent l'espace restant autrement, et aucun réglage ne les reproduit.
• align-items: baseline. Des textes de tailles différentes posés sur une ligne de base commune, courant dans les titres et les lignes de prix. L'Auto Layout aligne sur les bords et les centres de boîte, pas sur les lignes de base.
• flex-grow fractionnaire. flex: 1 devient layoutGrow: 1. flex: 2 et flex: 0.5 ne deviennent rien.
• flex-wrap. Une rangée qui passe à la ligne est une autre géométrie qu'une rangée unique, et l'endroit du retour dépend de la largeur du conteneur au moment de la capture.
• La remesure du texte. C'est celle qui piège les outils. Un calque de texte ajusté à son contenu est mesuré par Figma, avec la police que Figma possède, à la taille que Figma calcule. Si cette mesure diffère de celle du navigateur ne serait-ce que d'un pixel, tous les frères suivants dans la pile se décalent.

À cause de ce dernier point, le problème n'apparaît souvent qu'après avoir installé une police manquante, ou seulement sur la machine de quelqu'un d'autre.

Pourquoi les convertisseurs l'appliquent quand même

Parce qu'un fichier plein de frames en Auto Layout a l'air d'un meilleur produit qu'un fichier plein de rectangles positionnés en absolu. Ça se démontre bien et ça fait une ligne sur la liste des fonctionnalités. Et dans le cas courant, une rangée simple ou une grille de cartes aux espacements réguliers, c'est réellement mieux : vous redimensionnez le frame et il se comporte correctement.

Le hic, c'est que l'outil ne peut pas distinguer le cas courant du presque-juste sans vérifier, et vérifier coûte plus cher que ne pas vérifier.

Que faire

Si l'import est déjà fait

Prenez le frame qui paraît faux et mettez son mode de mise en page sur aucun, dans la section layout du panneau de droite. Les enfants gardent leur position actuelle : si le décalage a déjà eu lieu, cela le fige au lieu de l'annuler. C'est pour ça que le geste utile est presque toujours de réimporter plutôt que de réparer.

Avant, vérifiez une chose : les polices utilisées par la page sont-elles installées sur votre machine ? Une police substituée remesure chaque calque de texte, et aucun réglage de mise en page ne sauve un fichier dont le texte a la mauvaise largeur. Figma vous dit quelles polices manquent à l'ouverture.

Si vous êtes en train de choisir un outil

Demandez ce qu'il fait quand les deux systèmes divergent. Il n'y a que trois réponses possibles, et une seule qui tienne.

1. Appliquer l'Auto Layout partout où il voit du flexbox. Rapide, joli en démo, et vous repartez avec un fichier qui a bougé sans le dire.
2. Ne jamais l'appliquer. Toujours juste, jamais utile. Vous récupérez un tas de calques absolus, exacts et pénibles à modifier.
3. Ne l'appliquer que là où il reproduit l'original. Juste et utile, mais il faut que l'outil prédise réellement ce que fera Figma et compare.

Comment Snapture tranche

Snapture prend la troisième option, et le mécanisme tient en un paragraphe.

Au moment de la capture, il sait déjà où se trouve chaque élément, puisqu'il a lu la page rendue : il dispose du rectangle réel, calculé par le navigateur, pour chaque enfant. Avant de poser une mise en page, il simule ce que le moteur de Figma ferait du même frame — le padding, l'espacement, l'alignement, la répartition du grow — et produit un rectangle prédit par enfant. Puis il compare les deux ensembles. Si chaque enfant tombe à moins d'un demi-pixel de l'endroit où le navigateur l'avait mis, la mise en page est posée. Si un seul manque, tout le frame conserve des coordonnées absolues exactes.

Il y a une seconde vérification de l'autre côté. Une fois que le plugin Figma a appliqué la mise en page, il remesure les enfants, cette fois contre le vrai moteur et non contre une prédiction, et si quoi que ce soit a bougé au-delà de ce même demi-pixel, il rend au frame ses coordonnées capturées. Cette vérification existe parce qu'un calque de texte peut se remesurer à l'import d'une manière qu'aucune simulation ne prévoit.

Ce que ça donne en pratique

Passer le convertisseur sur de vraies pages donne une idée de sa sélectivité. Ce sont les chiffres de la même série de mesures publiée sur la page de mesures.

La ligne intéressante est celle de MDN. Cinq frames en Auto Layout sur 253 nœuds, on dirait un échec de l'outil. C'est l'outil qui travaille : la mise en page des articles MDN repose surtout sur le flux de document et les floats, que l'Auto Layout ne modélise pas du tout. Le filtre a donc presque tout refusé et gardé des positions exactes. Pour cette page, c'est le bon arbitrage.

Linear, à l'inverse, est presque entièrement construit en rangées flex à espacement uniforme. 261 de ses frames passent réellement la comparaison, et ceux-là se comportent correctement quand vous les redimensionnez dans Figma.

En bref

L'Auto Layout après un import n'est fiable que si quelque chose l'a vérifié. Flexbox et l'Auto Layout se recoupent assez pour tromper un convertisseur et diffèrent assez pour décaler votre fichier, et l'écart se manifeste généralement par quelques pixels plutôt que par une casse évidente : exactement le genre d'erreur qui coûte le plus de temps à trouver.

Si un outil ne sait pas vous dire ce qu'il fait quand les deux divergent, partez du principe qu'il ne vérifie pas.

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