Dal Web Fisso al Responsive
Nel 1996 uscì il film Space Jam. Il sito web creato per promuoverlo è ancora online, identico dopo quasi 30 anni — una testimonianza della retrocompatibilità del web.
A quei tempi era ragionevole assumere che tutti guardassero il vostro sito su un monitor desktop a 640×480 pixel. Le dimensioni erano fisse: il sito di Space Jam usava tabelle HTML larghe 500px. Era come stampare un volantino — nulla di dinamico o adattabile.
Poi arrivò l'iPhone.
Per la prima volta, i siti web dovevano funzionare anche su schermi piccoli. La prima soluzione fu il design adattivo (adaptive design): il server inviava pagine HTML diverse a seconda del dispositivo. Chi visitava facebook.com da telefono veniva reindirizzato a m.facebook.com, un sito completamente separato.
Costruire due versioni di ogni sito era un lavoro enorme. E quando Apple rilasciò l'iPad, a metà strada tra telefono e desktop, fu chiaro che serviva un nuovo approccio.
Il design responsive (responsive design) è l'idea che tutti i dispositivi ricevano lo stesso HTML, ma quel documento si adatti grazie al CSS. Un solo file HTML che funziona ovunque.
Adaptive vs Responsive
Adaptive = HTML separati per ogni dispositivo (più lavoro, meno complessità CSS). Responsive = stesso HTML, CSS flessibile (meno lavoro, più complessità CSS). Oggi il responsive è lo standard.
Pixel Hardware e Pixel CSS
Quasi tutti i telefoni moderni hanno display ad alta densità (High DPI o, nel marketing Apple, display "Retina"). Un iPhone 15 ha una risoluzione nativa di 1179×2556 pixel — più della maggior parte dei monitor desktop!
Se il browser usasse quella risoluzione letteralmente, il testo sarebbe illeggibile. Per questo esiste il device pixel ratio: il rapporto tra i pixel fisici del display (LED) e i pixel "teorici" che usiamo nel CSS.
Su un iPhone tipico, questo rapporto è 3. Significa che una lunghezza di 10px nel CSS corrisponde a 30 pixel fisici. Ogni pixel software corrisponde a 9 pixel hardware (3×3):
La conversione avviene "sotto il cofano". Nel CSS, lavorate solo con i pixel software — ed è tutto ciò che vi serve sapere.
Immagini ad alta densità
Questo è importante per le immagini: su display ad alta densità, un'immagine 200×200 pixel apparirà sfocata se visualizzata a 200×200 CSS pixel. Per immagini nitide servono file a risoluzione doppia o tripla. Vedremo come gestirlo più avanti nel corso.
px vs rem nelle Media Query
Quando create media query con min-width / max-width, dovreste usare pixel o rem?
La differenza: come avete imparato, l'unità rem equivale a 16px di default, ma può essere modificata — sia dallo sviluppatore, sia dall'utente.
Immaginate un utente con problemi di vista che ha aumentato la dimensione del font base del browser a 32px. Ora ogni rem equivale a 32px invece di 16.
La domanda è: le nostre media query dovrebbero rispettare questa scelta?
Con media query in pixel: il layout desktop rimane invariato anche con il font ingrandito. Il risultato è un layout stretto e affollato: la sidebar si espande e occupa metà schermo.
Con media query in rem: il browser passa automaticamente al layout mobile (anche se la finestra è di dimensioni desktop). Il testo grande ha più spazio per respirare, e l'esperienza è decisamente migliore.
Per questo motivo, si raccomanda di usare rem nelle media query nella maggior parte dei casi.
/* Conversione: dividi per 16 */
/* 768px / 16 = 48rem */
@media (min-width: 48rem) {
/* ... */
}rem o em?
Potete usare anche em al posto di rem: nelle media query, le due unità funzionano in modo pressoché identico.
I Breakpoint
Per dare struttura al mondo caotico delle dimensioni dei dispositivi, è utile definire una serie di breakpoint (punti di rottura).
Un breakpoint è una larghezza specifica del viewport che ci permette di raggruppare tutti i dispositivi in un piccolo numero di esperienze possibili. Ad esempio, con un breakpoint a 412px, tutti i dispositivi sotto quella soglia ricevono lo stesso layout — chi usa un telefono da 320px e chi ne usa uno da 375px vedranno la stessa cosa.
L'errore comune: inseguire i dispositivi
Molti sviluppatori scelgono breakpoint basandosi sulle risoluzioni dei dispositivi più famosi: "l'iPhone 12 è largo 375px, usiamo quello come breakpoint mobile."
Questo approccio è sbagliato. Le risoluzioni più comuni dovrebbero stare al centro di ogni gruppo, non ai bordi. Un iPhone da 375px dovrebbe essere nello stesso gruppo di un iPhone SE da 320px e di un Android da 390px.
La regola: mettete i breakpoint nelle "zone morte"
I breakpoint vanno posizionati il più lontano possibile dalle risoluzioni reali, in una sorta di terra di nessuno (no-device land). In questo modo, tutti i dispositivi simili condivideranno lo stesso layout.
Viewport Units — Attenzione alle Trappole
Le unità viewport hanno due problemi importanti che dovete conoscere:
Problema 1: 100vh su mobile non corrisponde all'area visibile
Quando caricate una pagina su un telefono, il browser mostra la barra degli indirizzi in alto e i pulsanti di navigazione in basso. Quando iniziate a scorrere, questa interfaccia scivola via, liberando più spazio.
Il valore 100vh si riferisce sempre all'altezza massima (con l'interfaccia del browser nascosta). Quando la pagina viene caricata e l'interfaccia è ancora visibile, un elemento 100vh sborda oltre lo schermo visibile.
Problema 2: 100vw su desktop include la scrollbar
L'unità vw misura la larghezza del viewport inclusa la scrollbar. Su mobile non è un problema (la scrollbar è trasparente e sovrapposta). Ma su desktop la scrollbar occupa spazio fisico (tipicamente 15–17px). Quindi width: 100vw causa un overflow orizzontale — la pagina diventa leggermente più larga del visibile.
Vedremo questo bug in dettaglio nella prossima slide.
Le alternative moderne: dvh, svh, lvh
I browser moderni supportano nuove unità viewport che risolvono il problema mobile:
| Unità | Significato |
|---|---|
dvh | Dynamic — cambia quando la barra del browser appare/scompare |
svh | Small — l'altezza minima (con tutta l'interfaccia browser visibile) |
lvh | Large — l'altezza massima (interfaccia nascosta) — equivale a vh |
.hero {
/* Usa l'altezza effettiva visibile, che si aggiorna dinamicamente */
min-height: 100dvh;
}Attenzione
In generale: per l'altezza piena su mobile usate 100dvh (o 100svh se non volete che l'elemento si ridimensioni durante lo scroll). Per larghezze a tutto schermo, non usate 100vw — usate width: 100% sul body o sul contenitore. Vedrete il motivo nella prossima slide.
Il Bug di 100vw
Esiste un fenomeno molto comune legato al valore 100vw: una pagina web acquisisce una scrollbar orizzontale indesiderata che permette di scorrere di pochi pixel a destra.
La causa più frequente: 100vw
Ecco cosa succede quando usate width: 100vw su desktop: il viewport è largo, diciamo, 1200px. La scrollbar verticale occupa 15px. Lo spazio effettivo per il contenuto è 1185px. Ma 100vw vale 1200px — include la scrollbar. Risultato: 15px di overflow orizzontale.
La soluzione è semplice:
Per elementi a larghezza piena, usate width: 100% (che si riferisce al contenitore, non al viewport) invece di width: 100vw:
/* PROBLEMA: causa overflow orizzontale */
.full-width {
width: 100vw;
}
/* SOLUZIONE: rispetta lo spazio disponibile */
.full-width {
width: 100%;
}Novità Chrome 145
Dalla versione 145 di Chrome (inizio 2026), 100vw sottrae automaticamente la larghezza della scrollbar in presenza di determinate condizioni.
Altre cause comuni di scrollbar orizzontale indesiderata:
- Un'immagine o un video senza
max-width: 100%che sborda dal contenitore - Una parola molto lunga che non va a capo (es. URL senza
word-break: break-all) - Un elemento posizionato con valori negativi di
leftoright - Un elemento con
marginnegativo che esce dal flusso
Come trovarle: nel DevTools del browser, ispezionate gli elementi partendo dal <body> e scendendo nell'albero — l'elemento che supera la larghezza del body è il colpevole.
Regola pratica
Come regola pratica: evitate 100vw per le larghezze. L'unità vw è utile per calcoli proporzionali (es. 50vw, 0.5vw per letter-spacing), ma per "larghezza piena" il buon vecchio 100% funziona meglio e non ha il bug della scrollbar.
L'Idea della Tipografia Fluida
La tipografia fluida (fluid typography) è un approccio in cui il font-size scala in modo continuo con la larghezza del viewport, invece di saltare tra valori fissi ai breakpoint.
Il primo tentativo potrebbe essere usare le unità viewport che già conoscete dalla Sezione 3:
h1 {
font-size: 5vw; /* 5% della larghezza del viewport */
}Su un viewport di 1000px, il titolo sarà 50px. Su 400px, sarà 20px. Il testo scala, ma ci sono due problemi:
Problema 1 — Nessun limite:
Su schermi molto grandi il testo diventa enorme, su schermi molto piccoli diventa illeggibile. A 320px il titolo sarebbe solo 16px — praticamente come il body text.
Problema 2 — Accessibilità:
Le unità viewport ignorano le preferenze dell'utente. Se un utente aumenta il font-size predefinito nel browser, il testo in vw non cambia. Questo viola le linee guida WCAG, che richiedono che il testo sia scalabile almeno al 200%.
La soluzione? Combinare unità viewport con unità relative come rem, e usare clamp() per imporre dei limiti. Vediamo come costruire la formula passo per passo.
Attenzione
Non usate vw da solo per il font-size. Funziona come demo, ma in produzione viola i requisiti di accessibilità. La formula completa che vedremo nella prossima slide risolve entrambi i problemi.
Create un Titolo con Tipografia Fluida
Aprite CodePen e create un heading con font-size fluido usando clamp(). Ridimensionate il pannello Result per vedere il testo scalare gradualmente!
Risultato atteso
- Il titolo scala gradualmente quando ridimensionate il pannello
- Il titolo non diventa mai più piccolo di 1.5rem né più grande di 3rem
- Il paragrafo sotto resta sempre alla stessa dimensione
Codice di partenza
<article class="contenuto">
<h1 class="titolo-fluido">Tipografia Fluida</h1>
<p class="corpo">
Questo paragrafo usa un font-size fisso in rem.
Non scala con il viewport — e va bene cosi'!
Il body text deve restare leggibile e stabile.
</p>
<h2 class="sottotitolo-fluido">Anche i sottotitoli possono essere fluidi</h2>
<p class="corpo">
Ridimensionate il pannello e osservate la differenza
tra i titoli (fluidi) e il testo del corpo (fisso).
</p>
</article>.contenuto {
max-width: 800px;
margin: 0 auto;
padding: 2rem;
}
/* Titolo: tipografia fluida con clamp() */
.titolo-fluido {
font-size: clamp(1.5rem, 1rem + 2.5vw, 3rem);
line-height: 1.2;
color: #1a1a2e;
}
/* Sottotitolo: anche questo fluido, ma con range diverso */
.sottotitolo-fluido {
font-size: clamp(1.2rem, 0.8rem + 1.5vw, 2rem);
line-height: 1.3;
color: #16213e;
}
/* Body text: fisso in rem, come deve essere */
.corpo {
font-size: 1rem;
line-height: 1.6;
color: #333;
}Cosa esplorare
- Ridimensionate il pannello da molto stretto a molto largo: i titoli scalano, il paragrafo no
- Cambiate i valori dentro
clamp(): provateclamp(1rem, 0.5rem + 4vw, 4rem)— che effetto ha? - Rimuovete il
1rem +dalla parte centrale (lasciate solo2.5vw): il testo diventa troppo piccolo su schermi stretti - Provate ad applicare
clamp()anche al body text: vedrete che non serve, il testo a 1rem è già perfetto - Confrontate con l'approccio a media query: sostituite clamp() con font-size fissi a breakpoint diversi — vedete la differenza tra "graduale" e "a scatti"?
Il Limite delle Media Query
Finora abbiamo usato le media query per adattare il layout alla larghezza del viewport (la finestra del browser). Funziona bene per i layout di pagina, ma ha un limite importante.
Immaginate una scheda profilo che compare in più punti della stessa pagina — una griglia che può avere 3 colonne strette o 2 colonne più larghe a seconda del contenuto:
Quando le schede sono 3 per riga, lo spazio è stretto: la foto va sopra, le informazioni sotto. Quando le schede sono 2 per riga, lo spazio è maggiore: la foto può andare a sinistra, i dettagli a destra.
Il problema: le due schede sono nella stessa pagina, allo stesso identico viewport. Una media query misura la finestra del browser — la stessa per entrambe. Non sa quanto spazio ha la singola scheda nel suo specifico contesto.
Quello che vorremmo è che ogni scheda potesse reagire allo spazio del proprio contenitore, non alla larghezza della finestra.
Esiste uno strumento CSS che fa esattamente questo: i container query.
Container query
I container query (query sul contenitore) sono supportati da tutti i browser moderni dal 2023. Funzionano in modo simile alle media query, ma invece di misurare il viewport misurano la larghezza dell'elemento contenitore.