Perché i siti web si rompono in silenzio negli altri browser

La segnalazione di errore suona familiare: «Da me la pagina sembra rotta.» La sviluppatrice apre la pagina, vede — niente. Tutto al suo posto. Solo la telefonata di ritorno chiarisce la situazione: il cliente usa Safari sull'iPhone, lei Chrome sul desktop. Tra i due stanno due motori di rendering, diverse larghezze di schermo e una serie di differenze silenziose, nessuna delle quali ha mai generato un messaggio di errore.

Che lo stesso sito web possa apparire diverso a seconda del browser non è un incidente di percorso, ma architettura. Nel cuore di ogni browser lavora un motore di rendering che traduce HTML e CSS in pixel. Tre famiglie si dividono oggi praticamente l'intero mercato: Blink alimenta Chrome, Edge e la maggior parte dei derivati minori di Chromium, Gecko il Firefox, WebKit il Safari — e sull'iPhone, ancora oggi, praticamente tutti i browser diffusi renderizzano con WebKit, anche se sull'icona c'è scritto Chrome o Firefox.

Questi motori sono implementazioni indipendenti degli stessi standard web. Gli standard descrivono che cosa deve fare una proprietà CSS — ma lasciano margini, vengono recepiti a velocità diverse e ogni tanto due team di sviluppo capiscono la stessa formulazione in modo diverso. Il risultato sono tre programmi che leggono lo stesso documento e arrivano a immagini leggermente diverse. Il più delle volte le differenze sono invisibilmente piccole. A volte no.

Il punto decisivo: queste differenze restano silenziose. Il CSS è progettato deliberatamente per tollerare gli errori. Una proprietà che un browser non conosce viene semplicemente ignorata — senza avviso, senza crash, senza traccia in alcun log. Ciò che nell'introduzione di nuove tecniche è una benedizione, perché i vecchi browser non rispondono ai fogli di stile moderni con un guasto totale, nella quotidianità diventa una trappola: la pagina non si rompe, ha soltanto un aspetto sbagliato. E nessuno lo viene a sapere, finché nessuno guarda.

I punti di rottura tipici si lasciano ordinare. Ci sono anzitutto le funzioni CSS giovani, che un motore già padroneggia e un altro non ancora, o in modo diverso nei dettagli. Ci sono le questioni interpretative del layout — come Flexbox e Grid gestiscono larghezze minime, ritorni a capo o container annidati, dove la specifica lascia margine di interpretazione. E ci sono i classici: gli elementi dei moduli come campi di selezione, checkbox e campi data, che ogni browser disegna a proprio gusto e che si lasciano ridisegnare solo fino a un certo punto.

Un esempio della prima categoria rende tangibile lo schema. La proprietà CSS gap, che regola le distanze tra elementi, era disponibile presto in tutti i motori per il layout Grid — nel contesto Flexbox, però, Safari l'ha supportata nettamente più tardi di Chrome e Firefox. Una barra di navigazione le cui voci di menu erano tenute a distanza con Flexbox e gap appariva impeccabile in due motori; nelle versioni più vecchie di Safari le voci stavano appiccicate. Nessun messaggio di errore, nessun crash, tecnicamente funzionava tutto — solo che la pagina, su una parte degli iPhone, risultava compressa e trasandata. In casi del genere rimedia una soluzione di ripiego con i classici margini esterni; ma per arrivarci bisogna prima sapere che la differenza esiste. Proprio questo è, nelle rotture silenziose, l'ostacolo vero: non stanno in nessuna lista di errori. Stanno solo nell'immagine.

A ciò si aggiungono differenze che nel foglio di stile non compaiono affatto. I caratteri vengono renderizzati diversamente su ogni sistema operativo e risultano di larghezza diversa; un titolo che in un ambiente resta su una riga, nell'altro va a capo e spinge verso il basso tutto ciò che segue. Le barre di scorrimento, a seconda del sistema, tolgono spazio al contenuto o vi si sovrappongono — e cambiano così la larghezza disponibile. Le unità viewport si comportano in modo diverso sui dispositivi mobili, a seconda di come il browser conteggia le barre degli indirizzi che appaiono e scompaiono.

La seconda grande fonte di rotture silenziose sono le larghezze di schermo. Il design responsivo definisce punti di commutazione — i breakpoint — in corrispondenza dei quali il layout si ristruttura: la navigazione si ripiega nell'icona del menu, le colonne si impilano una sull'altra, le spaziature si riducono. I test, per esperienza, si fanno alle larghezze standard dei dispositivi più diffusi. Le rotture avvengono in mezzo: con dimensioni di finestra insolite, sui tablet in orizzontale, con le finestre dimezzate sui monitor desktop larghi.

Le pagine in lingua tedesca sono colpite in modo particolarmente duro da una peculiarità: le parole composte lunghe. Dove in inglese stanno tre parole brevi, in tedesco sta la «Datenschutzgrundverordnung» — una parola che si rifiuta di andare a capo, sporge dal suo container o fa saltare una barra di navigazione non appena lo spazio scarseggia. Le interfacce tradotte, che nell'originale inglese apparivano impeccabili, sono perciò tra i candidati più affidabili ai problemi di ritorno a capo.

Persino una pagina che oggi appare corretta ovunque, del resto, non lo resta da sola. I browser si aggiornano da sé a ritmi brevi, i motori di rendering cambiano dettagli del loro comportamento — e il sito web cambia aspetto senza che nessuno abbia fatto alcun deploy. Il test accurato al lancio è perciò un'istantanea, non uno stato permanente. Lo stesso vale nella direzione opposta: ogni aggiornamento del CMS, ogni nuovo plugin, ogni modifica di testo può innescare spostamenti.

Dietro a tutto questo c'è un problema psicologico di fondo che chiunque conosce dalla quotidianità dello sviluppo: «works on my machine». Chi costruisce una pagina la vede centinaia di volte nel proprio browser sul proprio monitor — e inconsciamente considera questa vista la verità. Le visitatrici e i visitatori, però, si distribuiscono su motori, classi di dispositivi e dimensioni di finestra, e nessuna di queste si fa viva da sola quando qualcosa si sposta. Pochissime persone scrivono un'e-mail quando un menu si sovrappone. Semplicemente se ne vanno.

Tanto più prezioso è il raro caso in cui qualcuno si fa sentire davvero — a condizione che la segnalazione venga elaborata con metodo. Un procedimento collaudato ha quattro passi. Primo, chiedere l'ambiente: quale browser, quale dispositivo, quale larghezza approssimativa della finestra? Senza queste indicazioni ogni ricerca è un tirare a indovinare. Secondo, riprodurre nel motore giusto, non in una simulazione — al limite tramite un servizio di screenshot, se al momento non c'è a portata di mano un dispositivo con il motore giusto; come si svolge un simile ciclo di verifica lo descrive ScanU passo dopo passo. Terzo, circoscrivere quale meccanismo è coinvolto: il layout si rompe a un breakpoint, manca una funzione CSS, un carattere risulta più largo? La risposta determina la riparazione — i problemi di breakpoint li risolve il proprio foglio di stile, le funzioni mancanti richiedono una soluzione di ripiego, i problemi di font spesso solo container più generosi. E quarto, il passo che salta più spesso: dopo la correzione, riguardare tutti i motori. Chi controlla solo il punto segnalato rischia di non accorgersi che la riparazione ha spostato qualcosa altrove.

A questo punto sarebbe ovvia l'obiezione che gli strumenti per sviluppatori dei browser abbiano risolto il problema da tempo: ogni browser moderno include una modalità dispositivo che simula le dimensioni di schermo di telefoni e tablet. L'obiezione trascura che cosa faccia davvero questa modalità. Chi in Chrome sceglie la vista iPhone ottiene una finestra stretta con risoluzione adattata e identificativo mobile — ma il rendering avviene sempre con Blink, il motore di Chrome. Le peculiarità WebKit del vero browser dell'iPhone questa simulazione non le mostra, e nemmeno le peculiarità Gecko del Firefox. Per il lavoro sui breakpoint la modalità dispositivo è uno strumento eccellente; come prova di compatibilità tra browser non serve. Un motore non si può simulare, solo cambiare.

Come si trovano le rotture che non si annunciano? La via tradizionale è il lavoro manuale: un armadio pieno di dispositivi di test o una lista di browser che qualcuno clicca da cima a fondo dopo ogni modifica. Funziona, ma scala male — già tre browser per tre classi di dispositivi fanno nove viste per pagina, e la cura, per esperienza, cala a ogni ripetizione. La via più sistematica sono i servizi di screenshot, che parallelizzano questo controllo visivo. ScanU, per esempio, crea dopo l'inserimento di un URL, in circa 30 secondi, screenshot in Chrome, Firefox e Safari, ciascuno in vista mobile, tablet e desktop; quali combinazioni di dispositivi siano disponibili lo elenca la panoramica delle funzioni di ScanU. Invece di aprire nove finestre una dopo l'altra, si vede una griglia di immagini — e i valori anomali saltano all'occhio.

Davvero interessante diventa nella ripetizione. I servizi di questo tipo confrontano lo stato attuale con uno stato di riferimento salvato e marcano gli scostamenti nell'affiancamento diretto. Così dalla vaga domanda «la pagina sta bene ovunque?» nasce la domanda nettamente più affilata «è cambiato qualcosa dall'ultimo stato verificato?» — una domanda a cui si può rispondere anche quando nessuno ricorda più che aspetto avesse la pagina la settimana scorsa.

Anche qui l'onestà è d'obbligo: gli screenshot mostrano stati, non processi. Che cosa succede al passaggio del mouse, se un menu si apre in modo pulito, come si comporta la pagina allo scorrimento o con una connessione lenta — tutto questo un'immagine statica non lo rappresenta. Allo stesso modo una finestra di browser renderizzata non sostituisce la sensazione dell'hardware vero: i comandi touch, le prestazioni dei dispositivi più vecchi, le peculiarità delle singole versioni di sistema. Prima di un lancio importante, prendere in mano il telefono vero resta una buona idea, e i test funzionali uno screenshot non li sostituisce comunque.

Quanto impegno sia adeguato al tema non deve deciderlo nessuno in astratto — la direzione la danno le proprie statistiche di accesso. Mostrano attraverso quali browser, classi di dispositivi e larghezze di schermo arrivano le visitatrici e i visitatori reali, e con ciò quali combinazioni meritano priorità nella lista di verifica. Due riserve, però, ne fanno parte. Primo, la statistica misura solo chi arriva — non chi, a causa di una vista rotta, non resta nemmeno; un motore debolmente rappresentato può quindi essere anche la conseguenza di un problema, non solo il segno di scarsa rilevanza. Secondo, le quote variano notevolmente a seconda del pubblico e della situazione d'uso: un'offerta che si legge la sera sul divano ha una distribuzione di dispositivi diversa da un portale specialistico per la giornata d'ufficio. La propria lista di verifica dovrebbe perciò seguire i propri numeri, non le panoramiche generali di mercato.

Per la quotidianità basta spesso una routine semplice: dopo ogni modifica a stili o template, verificare le pagine più importanti su tutte e tre le famiglie di motori; dopo le release più grandi dei browser, controllare una volta l'esistente; nei redesign, guardare consapevolmente anche le larghezze intermedie, non solo i formati standard. Chi teme lo sforzo comincia in piccolo — la pagina italiana di ScanU introduce al servizio, il cui livello gratuito, con un progetto e 500 crediti al mese, basta per i primi passi.

Il nucleo del problema, intanto, resta — e questa è forse la vera lezione: i browser saranno anche in futuro programmi indipendenti con motori propri, gli standard continueranno a lasciare margini e il CSS continuerà a tacere invece di avvertire. Le rotture silenziose non sono un segno di lavoro trascurato, ma una proprietà di sistema del web. Il modo di conviverci è perciò soprattutto una questione di visibilità: chi guarda regolarmente la propria pagina con gli occhi di tutti e tre i motori — non importa con quale strumento — toglie al silenzio il suo effetto.