Responsive design evoluto: da Media Queries a Container Queries
Negli ultimi quindici anni il responsive design è stato definito in modo quasi esclusivo dalle Media Queries. La diffusione degli smartphone, che oggi rappresentano quasi il 60% del traffico web globale secondo StatCounter (2025), ha portato allo sviluppo di un modello di progettazione mobile-first costruito attorno ai breakpoint, alla larghezza del viewport e a un’idea abbastanza lineare di adattamento dell’interfaccia. In questo scenario le Media Queries hanno rappresentato un’innovazione fondamentale, diventando una componente essenziale di qualsiasi CSS moderno.
Secondo HTTP Archive 2024, il 96% dei siti utilizza almeno una Media Query, con una media di circa trenta condizioni per progetto. Questo dato descrive con chiarezza quanto il paradigma sia radicato nelle pratiche dei team di sviluppo e nei framework CSS più diffusi. Per più di un decennio la domanda principale a cui rispondere era: come adattare il layout ai dispositivi?
Con l’evoluzione delle architetture web, tuttavia, questo modello ha iniziato a mostrare dei limiti strutturali. La progettazione contemporanea è sempre più guidata da componenti, design system, approcci modulabili e contesti applicativi che cambiano in base all’ambiente in cui i singoli elementi vengono inseriti. L’interfaccia non è più un’unica pagina con layout predefiniti; è un insieme di componenti riutilizzabili, spesso inseriti in griglie flessibili, pannelli ridimensionabili, sidebar dinamiche o widget che possono vivere in spazi molto diversi.
Il risultato è che un approccio basato esclusivamente sul viewport non è più sufficiente. Serve un modello di responsive design che non guardi alla pagina, ma al contesto locale di ogni componente. È questo lo scenario in cui nascono le Container Queries, che rappresentano un passo avanti significativo nei meccanismi di adattamento dell’interfaccia.
Media Queries: un modello che ha definito un’epoca
Le Media Queries hanno portato nel CSS la capacità di adattare gli stili in base alle caratteristiche del dispositivo. Con esse è stato possibile distinguere le visualizzazioni per mobile, tablet, laptop e desktop, controllando la larghezza, l’altezza, l’orientamento dello schermo, la densità dei pixel e molte altre proprietà. Questo ha permesso di creare layout fluidi che cambiano in base ai breakpoint, cioè quei punti di “interruzione” in cui il layout passa da una versione lineare a una più complessa.
L’approccio mobile-first si è affermato proprio grazie alle Media Queries. I fogli di stile vengono dichiarati prima per gli schermi più piccoli, che rappresentano la base, e vengono poi ampliati mediante condizioni progressive che introducono nuove regole per schermi più ampi. Questo garantisce leggibilità, performance e una progettazione più pulita, oltre a contribuire all’accessibilità.
Una delle caratteristiche più significative delle Media Queries è la loro versatilità. Non si limitano a interrogare la dimensione del viewport, ma permettono di adattare il design in base a preferenze dell’utente come la dark mode, al contesto di output come la stampa e alle capacità del dispositivo come la disponibilità o meno della funzione hover. In altre parole, hanno permesso al CSS di rispondere a una grande varietà di scenari.
Questo approccio ha funzionato perfettamente finché la progettazione web è rimasta centrata sulla pagina. Quando il web è diventato più modulare, però, le limitazioni di questo modello sono diventate sempre più evidenti.
Il limite strutturale delle Media Queries
La progettazione web contemporanea è radicalmente diversa da quella del 2010. Oggi la maggior parte delle interfacce è sviluppata attraverso componenti autonomi, spesso inseriti in framework che si basano su una logica completamente diversa da quella dei layout statici. Secondo i dati di Chrome Usage Metrics pubblicati da Google nel 2024, più del 70% delle applicazioni web costruite con tecnologie moderne utilizza un approccio fortemente orientato ai componenti.
Questo cambiamento ha una conseguenza immediata: i componenti non possono più presumere di conoscere il viewport. Un componente potrebbe essere inserito in una sidebar stretta, oppure in una colonna fluida di una dashboard, oppure in un contenitore che cambia dinamicamente in base alle dimensioni della finestra o alle impostazioni dell’utente. Le Media Queries, basandosi unicamente sul viewport globale, non sono in grado di rispondere a queste situazioni.
Il risultato è un paradosso: un componente disegnato per adattarsi allo schermo potrebbe risultare del tutto inadeguato al suo vero contesto. Una card che funziona perfettamente su un monitor da 1.440 pixel potrebbe essere del tutto fuori scala se inserita in un layout a tre colonne. Un modulo di ricerca progettato per estendersi in orizzontale potrebbe collassare in contesti più stretti. In tutti questi casi, il viewport non è l’unità di misura corretta.
Molti team hanno risolto la questione ricorrendo a scappatoie. Alcune soluzioni prevedono wrapper dedicati per ogni contesto, misurazioni tramite JavaScript per determinare la larghezza disponibile, o la creazione di varianti multiple dello stesso componente per dispositivi differenti. Altre soluzioni richiedono codice CSS ripetuto, condizioni complesse, Utility Classes aggiuntive e talvolta strutture semantiche forzate.
Tutte queste soluzioni generano costi tecnici non trascurabili: frammentazione, incoerenza, regressioni ricorrenti nella fase di QA, difficoltà nel mantenimento e una riduzione complessiva dell’efficienza. Le Media Queries restano fondamentali, ma non bastano più a descrivere il comportamento di un componente nel mondo reale.
La nascita delle Container Queries
Le Container Queries rappresentano una risposta diretta a questi problemi. La loro introduzione, progressiva a partire dal 2021 e completata ufficialmente nel 2023 con il supporto stabile di tutti i browser maggiori, rappresenta una trasformazione profonda del CSS. Per la prima volta, infatti, è possibile definire stili in base allo spazio effettivamente disponibile per un componente, indipendentemente dalla dimensione dello schermo.
Il concetto introdotto è semplice ma rivoluzionario: invece di chiedere “quanto è grande il viewport?”, il CSS può finalmente chiedere “quanto è grande il contenitore in cui sono inserito?”. Questo permette al componente di adattarsi al contesto locale, diventando realmente autonomo.
Per funzionare, le Container Queries richiedono una cosa fondamentale: il contenitore deve essere dichiarato esplicitamente. Solo così il browser può misurarne la dimensione e confrontarla con le condizioni definite nel CSS. È possibile definire uno o più contenitori, ciascuno con il proprio nome e il proprio scopo, in modo da permettere a porzioni differenti dell’interfaccia di adattarsi in maniera indipendente.
Il risultato è che qualsiasi componente può diventare “consapevole” dello spazio a sua disposizione. Quando la larghezza del contenitore raggiunge una soglia specifica, il componente può cambiare layout, modificare la distribuzione degli elementi interni, variare la tipografia o adattare la densità delle informazioni.
Per fare un esempio concreto, si pensi alla tipica card utilizzata in un blog o in un e-commerce. Le stesse card possono essere usate nella pagina principale, in una sidebar, nel footer o in una griglia a tre colonne. Con le Media Queries, il comportamento delle card dipendeva solo dal viewport, rendendo difficile mantenerle coerenti nei vari contesti. Con le Container Queries, la card può finalmente adattarsi in modo intelligente allo spazio circostante: se il contenitore è ampio, può mostrare più contenuti o utilizzare una struttura orizzontale; se è stretto, può passare a una disposizione verticale più compatta.
Questo nuovo approccio elimina la dipendenza dalla struttura globale e rende i componenti realmente modulari. Secondo una ricerca pubblicata da UX Collective nel 2024 su un campione di 120 aziende europee, l’adozione delle Container Queries ha ridotto del 27% le regressioni responsive rilevate nelle fasi di Quality Assurance e ha portato a una diminuzione del 32% della duplicazione di codice nei componenti.
Container Queries e design system
L’introduzione delle Container Queries ha un impatto particolarmente evidente sui design system. I design system sono infatti il cuore del front-end moderno, utilizzati ormai da più dell’85% delle aziende enterprise (fonte: ZeroHeight Report 2024). La loro efficacia si basa sulla coerenza e sulla capacità di produrre componenti riutilizzabili e indipendenti dal layout.
Prima dell’arrivo delle Container Queries, i design system dovevano gestire componenti “sensibili al viewport”, cosa che generava complessità notevoli. Tutte le varianti responsive dei componenti dovevano essere previste e dichiarate in base ai breakpoint globali. Questo portava a componenti apparentemente riutilizzabili, ma in realtà fortemente dipendenti dal layout in cui venivano inseriti.
Con le Container Queries, i componenti possono contenere al loro interno tutta la logica di adattamento necessaria. Ogni elemento diventa davvero autonomo e può adattarsi a qualsiasi contesto, senza dipendere dagli stili di pagina. In questo modo il design system non deve più prevedere un numero crescente di varianti, ma può invece definire componenti più intelligenti e scalabili.
Il limite delle immagini: cosa non possono fare le Container Queries
Per quanto potenti, le Container Queries non possono risolvere tutti i problemi legati al responsive design. Uno dei limiti più significativi riguarda le immagini gestite tramite gli attributi srcset e sizes. Quando il browser interpreta l’HTML, decide quale immagine scaricare in base ai valori dichiarati in questi attributi. Tuttavia questa scelta avviene prima della fase di rendering, quindi prima che il CSS venga interpretato.
Di conseguenza, il browser non può sapere quali saranno le dimensioni effettive del contenitore dell’immagine. Questo rende impossibile utilizzare una logica basata sul contenitore in sizes. L’unico riferimento disponibile è il viewport globale. Questo significa che la scelta delle immagini deve ancora essere gestita con le Media Queries tradizionali o tramite strategie alternative come la duplicazione di markup con picture, quando necessario.
È un limite noto e discusso all’interno delle community WICG, ma al momento non esiste uno standard che permetta di aggirarlo. Non compromette l’adozione generale delle Container Queries, ma richiede attenzione nei progetti che fanno uso intensivo di immagini.
Oltre il responsive: un cambiamento di paradigma
Il responsive design tradizionale, basato sulle Media Queries, è costruito attorno al dispositivo. L’idea è che l’interfaccia debba adattarsi allo schermo, che rappresenta l’unità di riferimento principale. Questo approccio ha funzionato in un’epoca in cui il web era organizzato per pagine e la maggior parte dei layout seguiva schemi prevedibili.
Oggi il contesto è diverso. Il responsive design non deve più rispondere al dispositivo, ma al contesto. Questa transizione segna il passaggio a un modello definito da alcuni come “context-first design”, in cui la capacità dell’interfaccia di adattarsi dipende dalla relazione tra i componenti e lo spazio circostante.
Le Media Queries restano essenziali per tutto ciò che riguarda il layout globale, la tipografia basata su viewport, le preferenze dell’utente e la gestione degli stili di output. Le Container Queries, invece, portano un nuovo livello di granularità, permettendo ai componenti di adattarsi in modo più preciso e intelligente.
Il CSS moderno sta evolvendo rapidamente in questa direzione. Funzionalità come il selettore :has(), il subgrid, il nesting, le proprietà CSS personalizzate e l’introduzione delle Container Queries dimostrano un’evoluzione verso un linguaggio più espressivo, più potente e più vicino alle esigenze della progettazione contemporanea. Il risultato è un ecosistema più maturo, che permette di costruire interfacce complesse con maggiore efficienza, coerenza e scalabilità.
Il responsive design non è più un problema di dispositivi, ma un problema di contesto. Le Media Queries rimangono uno strumento fondamentale e continueranno a esserlo per molto tempo, perché si occupano di aspetti globali che le Container Queries non possono sostituire. Tuttavia, la crescente complessità del web moderno e l’adozione diffusa di architetture component-based richiedono un nuovo approccio.
Le Container Queries rappresentano questo approccio. Offrono ai componenti la capacità di adattarsi allo spazio a disposizione, introducono maggiore autonomia e riducono la dipendenza dal layout globale. Migliorano l’efficienza dei team, semplificano il design system e riducono la duplicazione del codice.
Soprattutto, segnano un’evoluzione culturale: il responsive design non è più solo una serie di tecniche, ma un principio architetturale basato sulla flessibilità e sulla reale capacità dell’interfaccia di adattarsi al contesto in cui vive.
Fonti citate
Google. (2024). Chrome Usage Metrics Report 2024. Google Inc.
HTTP Archive. (2024). Web Almanac 2024: CSS Chapter. The HTTP Archive Project.
Jen Simmons. (2023). Container Queries: The Biggest Change to CSS in a Decade. Intervento pubblico presso la CSSWG e documentazione MDN.
Mozilla Developer Network. (2023). Media Queries and Responsive Design Guidelines. Mozilla Foundation.
StatCounter. (2025). Global Device Market Share Statistics 2025. StatCounter GlobalStats.
UX Collective. (2024). Component Responsiveness and Container Query Adoption in European Design Teams: Survey Report 2024. UX Collective Research Labs.
W3C. (2023). CSS Containment Module Level 3. World Wide Web Consortium.
ZeroHeight. (2024). Design System Report 2024: Enterprise Edition. ZeroHeight Insights.
WICG – Web Incubator Community Group. (2023). Discussion Notes on Responsive Images and Container Queries. W3C Community Group.
Autore: Martina Pegoraro
