Da Figma a CSS: guida pratica alla conversione

Risposta rapida: convertire Figma in CSS puro significa tradurre l'Auto Layout in Flexbox, risolvere ogni valore di fill/spaziatura/tipografia nel suo numero reale invece che in un'approssimazione con classi utility, e mantenere l'output senza dipendenze. È la scelta giusta quando vuoi il controllo completo su ogni regola, senza un framework da imparare, installare o sovrascrivere in seguito.

Perché scegliere CSS puro invece di un framework

Ogni formato di output supportato da MarkupGen — CSS puro, Tailwind, Bootstrap, Bulma — parte dalla stessa fonte: la struttura e i valori reali del frame Figma. Il CSS puro è semplicemente il formato che non mette nulla tra il tuo file e il browser:

• Nessuna convenzione di naming delle classi da imparare. La scala di utility di Tailwind e le classi dei componenti di Bootstrap sono potenti, ma restano comunque un sistema da interiorizzare. Il CSS puro richiede solo di conoscere il CSS.
• Nessun peso da framework. Anche con la rimozione delle classi inutilizzate, un framework aggiunge un passaggio di build e una dipendenza da tenere aggiornata. Un export in CSS puro non ha né l'una né l'altra.
• Ogni regola è modificabile direttamente. Cambiare un valore di spaziatura significa modificare una singola dichiarazione, non andare a caccia della classe utility che corrisponde al valore in pixel desiderato.

Il compromesso è proprio quello che Tailwind esiste per risolvere: senza un framework che imponga una scala, i valori di spaziatura e colore possono diventare incoerenti in una codebase che cresce, se nessuno è disciplinato nel riutilizzare gli stessi numeri. Per una singola landing page o un piccolo sito, questo raramente è un problema. Per un prodotto di grandi dimensioni con molti contributor, vale la pena leggere Vanilla CSS vs Bootstrap vs Tailwind prima di decidere.

Cosa va effettivamente convertito

Un frame Figma porta con sé più struttura di quanto sembri a un primo sguardo, e ogni elemento si mappa su una parte specifica del CSS:

Niente di tutto questo è esotico: è la stessa mappatura che uno sviluppatore fa a mano quando ricostruisce un design pixel per pixel. La differenza è farlo a partire dalla struttura e dai valori reali del frame, invece che a occhio su uno screenshot.

Come MarkupGen genera il CSS

Il flusso di lavoro è sempre lo stesso, in quattro passaggi, indipendentemente dal formato di output: esporta il frame da Figma con il plugin MarkupGen, che cattura insieme struttura, stili e immagini; l'IA costruisce il markup a partire da quella struttura reale invece che approssimando un'immagine; rifinisci contenuti, font o layout nell'editor integrato se qualcosa richiede un aggiustamento; esporta il pacchetto finale.

Nel caso specifico del CSS puro, questo significa che il foglio di stile generato usa i valori reali di colore e spaziatura del frame, invece di forzarli sulla scala predefinita di un framework — un fill impostato su #3B82F6 viene generato esattamente così, non come il blu Tailwind più vicino. L'Auto Layout si mappa automaticamente su una struttura Flexbox (vedi Auto Layout to CSS per la scomposizione completa proprietà per proprietà), e il comportamento responsive viene generato a partire dai vincoli di ridimensionamento del frame invece di essere aggiunto come passaggio manuale separato. L'HTML in output privilegia elementi semantici rispetto a <div> annidati per impostazione predefinita, un aspetto importante tanto per la manutenibilità quanto per l'accessibilità e la SEO.

Trasformare le variabili di Figma in custom property CSS

Le variabili di Figma (colori, tipografia, spaziatura, raggio, effetti) sono la cosa più vicina a un design system che un file di design possa avere, e si mappano concettualmente sulle custom property CSS — un blocco :root di coppie --name: value che ogni regola del foglio di stile può richiamare. Come accennato sopra, oggi l'output CSS di MarkupGen risolve ogni proprietà nel suo valore letterale per ciascun elemento invece di generare automaticamente quel livello di variabili :root, quindi costruire questa mappatura è un passaggio manuale. È comunque un lavoro meccanico, una volta capito lo schema:

Una convenzione di naming che vale la pena seguire: rispecchia la struttura gruppo/nome della variabile Figma stessa (color/primary → --color-primary) invece di inventarne una parallela, così le due restano facili da confrontare man mano che il design evolve. Una volta che le variabili esistono come custom property, sostituisci i valori letterali generati con riferimenti var(--color-primary) nel CSS esportato.

Due limiti da conoscere prima di affidarti a questo approccio: non tutte le variabili Figma si mappano in modo pulito su una singola proprietà CSS — una variabile usata sia per il colore di un bordo sia per il colore di un testo in punti diversi del design non implica che debbano restare collegate nel codice, se i loro scopi sono realmente diversi. E le variabili responsive (un valore di spaziatura che cambia tra i breakpoint) vanno ridichiarate all'interno di ogni media query pertinente, dato che una singola custom property :root non può contenere più di un valore alla volta — i frame per breakpoint di Figma non si risolvono automaticamente negli override responsive basati sul cascade di CSS.

Rivedere il CSS generato prima di pubblicare

• Controlla eventuali derive nei valori. Senza una scala di utility che imponga coerenza, cerca valori quasi duplicati (padding: 15px accanto a padding: 16px altrove) che probabilmente dovrebbero essere lo stesso numero.
• Verifica il comportamento responsive su breakpoint reali, non solo sulla dimensione predefinita del frame — ridimensiona il browser invece di fidarti di un singolo screenshot.
• Controlla i nomi di classi/selettori se il progetto ha una propria convenzione di naming da seguire (BEM, CSS Modules, ecc.) e correggi prima del merge.
• Usa l'editor integrato per modifiche a contenuti o layout invece di editare a mano l'export, poi ri-esporta in modo che nulla resti disallineato.

Ogni export riceve anche un punteggio di qualità IA automatico, che confronta l'anteprima live con il design originale, così hai un segnale rapido su se è pronto per andare in produzione prima di una revisione manuale.

Domande frequenti

L'output CSS usa custom properties (variabili) CSS? L'output si concentra su regole standard, direttamente modificabili per ogni elemento, invece che su un livello di tema basato su variabili — se il tuo progetto usa un sistema di custom properties, prevedi di integrare i valori generati come passaggio manuale.

Il layout è responsive per impostazione predefinita? Sì — i breakpoint vengono generati a partire dai vincoli di ridimensionamento dell'Auto Layout del frame, non aggiunti in seguito. Vedi Design responsive in Figma: layout Mobile e Desktop spiegati per capire come funziona con layout mobile/desktop separati.

In cosa si differenzia dall'output Tailwind? Stessi dati di partenza, destinazione diversa: l'output Tailwind risolve i valori nella classe utility più vicina (con fallback a valori arbitrari per tutto ciò che è fuori scala); l'output CSS puro mantiene i valori esatti del design come dichiarazioni standard. La scelta dipende dal fatto che il tuo progetto standardizzi già o meno su un framework di utility.

Provalo sul tuo design

Se stai decidendo tra un export in CSS puro e uno basato su framework, il modo più veloce per capire quale si adatta meglio è vederli entrambi sullo stesso design. Prova MarkupGen gratis, oppure leggi la guida completa nella guida alla conversione da Figma a HTML. Preferisci prima una panoramica rapida? Vedi la pagina Figma to CSS converter.