Position CSS dans Figma : Static, Relative, Absolute, Fixed et Sticky
CSS compte cinq valeurs de position : static, relative, absolute, fixed, sticky. Cette référence les associe à l'auto layout et aux constraints de Figma.
CSS compte exactement cinq valeurs pour la propriété position : static, relative, absolute, fixed et sticky. Figma n'en a aucune. Ce qu'il propose à la place, c'est l'auto layout, la possibilité de faire ignorer l'auto layout à un calque, et un ensemble de constraints de redimensionnement. Chacun couvre une partie différente de ce que fait position dans le navigateur. Si vous avez déjà importé une page en vous demandant pourquoi une barre latérale sticky s'est retrouvée en simple calque static, voici pourquoi.
Cet écart apparaît surtout dans trois situations : refondre un site qui n'a jamais eu de fichier de design, démonter la page d'un concurrent pour comprendre comment elle est construite, et reconstruire une page ancienne dont le code source d'origine n'existe plus. Dans les trois cas, les calques récupérés ne sont utiles qu'à la mesure de votre compréhension du comportement CSS que chacun avait auparavant. Figma n'a aucun moyen de conserver cette information sur le canevas lui-même.
Cette référence parcourt les cinq valeurs, ce que chacune fait réellement selon MDN et la spécification CSS Positioned Layout, et quel mécanisme Figma, s'il existe, joue le même rôle. Elle se termine par un tableau de référence propriété par propriété à consulter rapidement, à jour en 2026, tandis que le CSS Positioned Layout Module Level 3 reste la définition de référence pour les cinq valeurs.
Static et Relative : Les Deux Qui Réservent de l'Espace de Layout
position: static est la valeur par défaut. Aucun élément n'a besoin de la déclarer, et une fois déclarée, top, right, bottom, left et z-index n'ont strictement aucun effet sur lui. L'élément se place exactement là où le flux normal du document le positionne.
position: relative reste lui aussi dans le flux normal, mais peut être déplacé avec top, right, bottom et left. Le déplacement est purement visuel. L'espace que l'élément aurait occupé à sa position non déplacée reste réservé dans le layout, si bien qu'aucun autre élément de la page ne se repositionne pour combler l'écart.
L'équivalent le plus proche dans Figma pour les deux est l'état par défaut d'un calque enfant à l'intérieur d'un frame en auto layout. Un calque auquel on n'a pas demandé d'ignorer l'auto layout suit les règles de layout de son parent de la même façon qu'un élément en position static ou relative suit le flux normal, et conserve de la même manière son espace réservé. Il n'existe pas d'interrupteur "static" ou "relative" séparé dans Figma, parce que l'auto layout suppose déjà ce comportement par défaut. Pour le volet spécifique à flex de cette correspondance, CSS Flexbox to Figma Auto Layout détaille justify-content, align-items et gap propriété par propriété.
Absolute Positioning : Containing Blocks en CSS vs Ignore Auto Layout dans Figma
position: absolute sort complètement un élément du flux normal. Il est positionné par rapport à l'ancêtre le plus proche dont le position n'est pas static, ou par rapport à l'initial containing block de la page si aucun ancêtre de ce type n'existe. Rien n'est réservé pour lui dans le layout, et à moins qu'un width ou un height ne soit défini, il se dimensionne selon son contenu.
L'équivalent Figma pour cela est un calque réglé pour ignorer l'auto layout, exposé dans l'API des plugins sous layoutPositioning: ABSOLUTE. Le calque reste imbriqué dans son frame parent, mais reçoit des valeurs explicites de x, y, width et height au lieu de suivre les règles de layout du parent. C'est le même compromis que fait CSS : toujours à l'intérieur d'une structure englobante, mais plus régi par elle. Le système de constraints propre à Figma (left, right, top, bottom, center, scale) ne devient disponible qu'une fois qu'un calque a ignoré l'auto layout, ce qui reflète la façon dont un élément CSS en position absolute continue de mesurer ses offsets par rapport à un containing block même après avoir quitté le flux.
Tous les frames importés ne se convertissent pas proprement en auto layout. Quand la géométrie capturée ne peut pas être reproduite ainsi, par exemple des éléments frères superposés ou un layout piloté par un script plutôt que par CSS, UnHTML bascule de lui-même vers l'absolute positioning pour ce frame. Le résultat n'est jamais pire qu'une simple copie calque par calque de ce que la page affichait.
L'absolute positioning en CSS est aussi le mécanisme derrière la plupart des badges, tooltips et overlays modaux, puisqu'aucun de ces éléments ne devrait repousser le contenu environnant à son apparition. C'est également vrai dans Figma une fois qu'un calque ignore l'auto layout : il peut se placer au-dessus, ou partiellement en dehors, de son frame parent sans perturber la position d'aucun calque frère. La différence est qu'un élément CSS dimensionné uniquement selon son contenu peut se retrouver avec n'importe quelle largeur selon ce qu'il contient, tandis qu'un calque Figma porte toujours un width et un height explicites dès qu'il est placé, avec ou sans auto layout. C'est l'un des petits écarts bien réels qu'un import report sert à révéler : un élément avec width: auto sur la page d'origine devient un unique nombre fixe dans Figma, valable au moment de la capture, et non une règle qui continue de se recalculer.
Fixed Positioning : Ancrage au Viewport et Pourquoi Figma Ne Peut Pas Simuler le Scroll
position: fixed se comporte comme absolute, à une différence près. Son containing block est le viewport lui-même, ou un ancêtre doté d'une propriété transform, perspective ou filter différente de none. Un élément fixed ne bouge pas quand la page défile, et en médias paginés il se répète à l'identique sur chaque page.
Figma n'a aucun équivalent, parce qu'un frame Figma n'est pas un viewport qui défile. Il n'y a rien par rapport à quoi s'ancrer, puisque rien ne défile sous le calque en premier lieu. En pratique, la façon la plus propre de gérer une barre de navigation fixed ou un pied de page persistant après l'import est de le traiter comme son propre frame de premier niveau plutôt que d'attendre qu'il s'insère dans la pile principale d'auto layout de la page, puis de reconnecter le comportement de scroll dans le code.
Les deux éléments fixed les plus courants sur une page réelle sont une barre de navigation supérieure et une bannière de cookies ou de consentement. Les deux s'importent généralement à un endroit visuellement correct même si le comportement CSS sous-jacent a disparu. Cela vaut la peine de le signaler à quiconque prendra en charge la reconstruction finale : le calque semble juste à la position de scroll où la page a été capturée, mais rien dans le fichier Figma n'indique qu'il était censé rester à cet endroit à n'importe quelle autre position de scroll.
Sticky Positioning : La Valeur Sans Équivalent Figma
position: sticky est la plus délicate des cinq. Elle se comporte comme relative jusqu'à ce que l'utilisateur défile au-delà d'un seuil défini, puis se fixe à une position à l'intérieur de son ancêtre défilant le plus proche. Elle nécessite qu'au moins l'une des propriétés top, right, bottom ou left ait une valeur autre que auto sur un axe donné pour s'activer. Selon la spécification CSS Positioned Layout, si seul top est défini et que bottom reste en auto, l'élément ne pourra se déplacer que vers le bas, jamais vers le haut. Comme relative, elle réserve son espace de layout, contrairement à absolute et fixed, qui ne le font pas.
Il n'existe aucune simulation de scroll sur un canevas Figma, si bien qu'un élément en position sticky s'importe toujours en calque static. Ce n'est pas un défaut de la conversion. C'est un écart structurel : les frames Figma ne défilent pas comme le fait le viewport d'un navigateur, donc il n'y a rien auquel une instruction "reste ici" puisse s'accrocher. L'import report est l'endroit où vérifier toute déclaration position: sticky qui devra être reconnectée une fois le design revenu dans le code.
Les en-têtes sticky sur les tableaux de données et la navigation de section sticky sur les longues pages de documentation sont les deux cas où cela revient le plus souvent, puisque les deux reposent sur le fait que l'élément ne reste visible qu'après que l'utilisateur a défilé sur une distance précise, et non depuis le tout début de la page. Quelqu'un qui ne consulte que le fichier Figma importé n'a aucun moyen de savoir, rien qu'en le regardant, que l'en-tête du tableau était censé se détacher de sa ligne et flotter en haut du viewport. Comparer l'import report à la page en ligne, ou au CSS d'origine s'il est encore disponible, reste le seul moyen fiable de repérer chaque déclaration sticky avant la mise en production de la reconstruction.
De CSS Position à Figma : Un Tableau de Référence par Propriété
| Valeur CSS | Reste dans le flux normal | Espace de layout réservé | Équivalent Figma |
|---|---|---|---|
| static | Oui | Oui | Calque enfant en auto layout par défaut |
| relative | Oui | Oui | Calque enfant en auto layout par défaut, offset noté à part |
| absolute | Non | Non | Ignore auto layout / layoutPositioning: ABSOLUTE |
| fixed | Non | Non | Frame de premier niveau séparé, reconnecté dans le code |
| sticky | Oui, jusqu'au seuil | Oui | Calque static, aucune simulation de scroll |
Les layouts basés sur grid soulèvent une question voisine mais distincte. Les propriétés CSS Grid comme grid-template-columns et grid-area n'ont aucun rapport avec position. CSS Grid to Figma: What Survives the Conversion to Layers traite cette correspondance dans le même format propriété par propriété.
Conclusion
Figma n'a pas de propriété position, mais quatre des cinq valeurs CSS ont malgré tout un équivalent qui fonctionne. L'auto layout couvre static et relative, ignorer l'auto layout couvre absolute, et un frame de premier niveau séparé est la réponse pratique pour fixed. Sticky est le seul véritable écart, puisque rien dans Figma ne réagit à un événement de scroll. Quand une conversion ne peut pas se faire proprement, la bonne approche est de basculer vers l'absolute positioning plutôt que de deviner, et de le consigner dans un import report pour que rien ne se perde en silence.