Il pixel perfect non esiste più (ed è un bene)

Qualche mese fa un cliente mi ha mandato il mockup del suo nuovo sito.
Un PDF fatto bene, curato, con le quote segnate a lato: 24 px di margine qui, 32 di gap tra le card, titolo a 48 px.

Poi la domanda: «Il risultato sarà identico, vero?»

Gli ho risposto di no.
E gli ho spiegato che era una buona notizia.

Cosa vuol dire pixel perfect

Il termine indica la corrispondenza millimetrica tra il file grafico e la pagina costruita.

Allineamenti identici di testi, immagini e margini.

Coerenza tipografica assoluta, con gli stessi font, gli stessi pesi, le stesse interlinee e crenature.

Fedeltà cromatica al codice colore esatto, sfumature comprese.

In pratica: se sovrapponi uno screenshot del sito al mockup e li fai lampeggiare uno sull’altro, non deve muoversi niente.

Per anni è stato il metro con cui si giudicava il lavoro di un frontendista. E per anni ha avuto perfettamente senso.

Perché funzionava (e perché non funziona più)

Tra la fine degli anni Novanta e l’inizio degli anni Dieci il web era un posto molto più prevedibile.

Le risoluzioni erano poche e standardizzate.

Si progettava a 800x600, poi si è passati a 1024x768, infine a 1280x1024.

Tre numeri, non tremila. Un designer sapeva esattamente cosa avrebbe visto la persona dall’altra parte.

I siti avevano larghezza fissa, di solito 960 px, e lo spazio che avanzava ai lati veniva riempito con uno sfondo neutro.

Il layout non si adattava perché non doveva: era un francobollo incollato al centro dello schermo.

La struttura si costruiva con le tabelle HTML, tag nati per i dati tabellari e piegati a fare impaginazione.

Ogni elemento finiva dentro una cella con misure rigide, esattamente come un menabò tipografico.

Il web si comportava come la carta perché lo obbligavamo a farlo.

E i telefoni non c’entravano nulla.

Prima dell’iPhone i cellulari non navigavano sul web vero: mostravano pagine WAP, versioni testuali essenziali servite da un canale separato.

Nessuno si poneva il problema di come stesse un sito su uno schermo verticale, perché il problema non esisteva.

In quel contesto il pixel perfect non era una fissazione. Era una specifica realistica.

Il punto di rottura

Il 25 maggio 2010 Ethan Marcotte pubblica su A List Apart un articolo intitolato Responsive Web Design.

Poche pagine che cambiano il mestiere.

L’idea è controintuitiva per l’epoca: il web non è carta, e la sua natura non è la rigidità ma la fluidità.

Invece di costringere la pagina dentro una gabbia fissa, la si progetta perché si adatti allo spazio disponibile.

Marcotte mette insieme tre ingredienti: griglie fluide espresse in percentuali invece che in pixel,

immagini flessibili che non sfondano il contenitore,

e media query che permettono al CSS di cambiare regole a seconda della larghezza dello schermo.

Nel giro di pochi anni diventa lo standard. E il mercato ci mette del suo:

smartphone e tablet esplodono con centinaia di combinazioni di dimensioni e proporzioni,

e nel 2010 arriva anche il primo display Retina, dove un pixel CSS non corrisponde più a un pixel fisico ma a quattro.

Quest’ultimo punto merita una riga in più, perché è quello che smonta il concetto alla radice.

Se il pixel non è più un’unità di misura stabile, la perfezione misurata in pixel diventa una frase senza referente.

Stai promettendo precisione rispetto a un metro che cambia lunghezza da un dispositivo all’altro.

Nel 2018 Jen Simmons dà un nome alla fase successiva, l’intrinsic web design:

layout costruiti a partire dai bisogni intrinseci del contenuto e non da una griglia decisa a priori, mescolando parti fisse e parti fluide dove serve.

Cosa vuol dire fluid perfect

Va detto: fluid perfect non è un termine ufficiale, non c’è una specifica del W3C che lo definisce.

È il modo in cui lo spiego ai clienti, perché rende l’idea meglio di qualsiasi sigla tecnica.

Il senso è questo: la perfezione non sta più nella corrispondenza a uno screenshot, sta nel comportamento.

Un sito è fatto bene se resta leggibile, proporzionato e coerente su qualunque larghezza, non se combacia con un PDF a 1440 px.

Gli strumenti che lo rendono possibile oggi sono maturi e supportati ovunque:

• clamp() per la tipografia fluida: definisci un minimo, un massimo e una regola di crescita,
• e il testo scala con continuità invece di saltare a scatti tra un breakpoint e l’altro
• CSS Grid e Flexbox, che distribuiscono lo spazio in base a quanto ce n’è invece di imporre misure decise a tavolino
• le container query, che permettono a un componente di adattarsi alla larghezza del contenitore in cui si trova e non a quella della finestra:
• la stessa card funziona in una sidebar stretta e in una griglia larga senza duplicare codice
• i variable font, che regolano peso e larghezza dei caratteri in modo continuo

Il risultato pratico è che smetti di progettare tre versioni di una pagina

e inizi a progettare un sistema che si comporta bene in mezzo,

agli estremi e nei casi che non avevi previsto.

Perché i casi che non avevi previsto arrivano sempre: schermi pieghevoli, finestre affiancate a metà monitor,

cruscotti d’auto, un utente che ha alzato la dimensione del testo di sistema perché ci vede poco.

Quando il mockup conta ancora

Attenzione a non ribaltare il discorso e buttare via il bambino con l’acqua sporca.

Il mockup resta uno strumento fondamentale.

Definisce la gerarchia visiva, la palette, il carattere del progetto, il tono.

Quello che non è più è un contratto misurato al millimetro.

E ci sono ambiti dove la precisione assoluta continua a servire: un logo, l’esportazione di un’icona,

un template per newsletter (dove i client di posta sono fermi a vent’anni fa e le tabelle si usano ancora),

un PDF destinato alla stampa.

Lì il pixel torna a essere un’unità affidabile.

La differenza sta nel capire di cosa stiamo parlando. Su un artefatto statico la misura esatta ha senso.

Su un’interfaccia che vive dentro un contenitore di dimensioni ignote, no.

Cosa cambia in pratica

Se stai per commissionare un sito, la domanda giusta da fare non è «sarà identico al mockup?».

Sono queste:

come si comporta a 320 px di larghezza?

E su un monitor ultrawide?

Cosa succede al titolo se il testo è lungo il doppio del previsto?

E se un utente ingrandisce i caratteri del 200%, la pagina regge o si accartoccia?

Chiedi al designer di consegnare non una tavola sola ma almeno tre stati, e di indicare quali elementi devono restare fissi e quali possono respirare.

Chiedi allo sviluppatore di mostrarti il sito mentre lo ridimensiona in diretta, trascinando il bordo della finestra:

quello è il vero collaudo, molto più onesto di uno screenshot affiancato al mockup.

Nella mia esperienza il momento in cui un cliente capisce davvero il punto è sempre lo stesso:

quando gli faccio vedere il suo sito su tre dispositivi diversi, e nessuno dei tre è identico al PDF, ma tutti e tre funzionano.

Domande frequenti

Il mio designer lavora in Figma con una griglia fissa. È sbagliato?
No. La griglia serve a ragionare sulle proporzioni. Il problema nasce solo se quelle misure vengono lette come vincoli assoluti invece che come punto di partenza.

Se il sito non è identico al mockup, come faccio a capire se il lavoro è fatto bene?
Guardando il comportamento: leggibilità a ogni larghezza, coerenza degli spazi, nessun elemento che esce dallo schermo o che si sovrappone. Un sito che tiene bene su cinque dispositivi diversi vale più di uno che combacia con un PDF su uno solo.

Costa di più un sito fluido rispetto a uno a misure fisse?
In genere no, e spesso costa meno in manutenzione: un sistema che si adatta da solo richiede meno interventi ogni volta che esce un formato di schermo nuovo.

I breakpoint sono superati?
Non sono spariti, hanno cambiato ruolo. Servono ancora per riorganizzare la struttura generale della pagina, mentre l’adattamento fine dei singoli componenti oggi si fa con le container query e le unità fluide.

Il passo successivo

Prendi il tuo sito e fai una prova che richiede dieci secondi:

afferra il bordo della finestra del browser e trascinalo lentamente da tutta larghezza fino a un terzo di schermo,

guardando cosa succede ai titoli e alle immagini.

Se vedi testi che si spezzano male, elementi che si accavallano o spazi che si sfasciano in certi punti, il sito non è costruito come sistema.

Se vuoi che quella prova la faccia io, e che ti dica dove il tuo sito si rompe e cosa serve per sistemarlo,

scrivimi e ci guardiamo insieme il tuo layout.

E se hai avuto una discussione con un cliente o con un designer proprio su questo tema, raccontamela: come è andata a finire?

Scrivilo nei commenti.