Ero ancora alle superiori quando l’accesso ad internet era per pochi fortunati e quando, per curiosità, ho iniziato ad immergermi nel mondo del web realizzando e pubblicando le prime pagine. Ne è passata di acqua sotto i ponti da allora e il modo di proporre i contenuti agli utenti è cambiato radicalmente. Certo, graficamente, è sempre possibile realizzare un sito “old style”, cioè pulito, essenziale, senza fronzoli. Il lato nascosto di quelle pagine, il codice, sarà comunque diverso. Dalla struttura tabellare degli anni ’90, siamo passati all’uso incrociato di diversi tag, ognuno dei quali definisce una tipologia di contenuto.
Parallelamente, è cambiato anche il modo di gestire gli stili grafici. Dalle semplici regole per modificare colori e allineamenti, il CSS è diventato un linguaggio sofisticato, permettendoci di costruire layout complessi e responsivi, aggiungere animazioni fluide e, più di recente, migliorare l’esperienza utente. Che dire invece di JavaScript? Questo linguaggio di sviluppo era inizialmente uno strumento utile per aggiungere piccole interazioni, come la validazione di un modulo. Oggi è diventato una vera e propria colonna portante del web moderno.
Questa evoluzione è casuale? No, per nulla. Dietro ogni miglioramento o nuova funzionalità c’è un percorso articolato e complesso, che parte dalle esigenze degli sviluppatori e dei designer e approda alla definizione e all’implementazione degli standard web. Uno standard, però, non è un punto di arrivo conclusivo. L’iter è continuo: la tecnologia si evolve, così come le necessità, i linguaggi di sviluppo e le metodologie.
Prendiamo come esempio il Responsive Web Design (RWD). Sebbene il termine sia stato coniato nel 2010 da Ethan Marcotte (Responsive Web Design), ho trovato tracce delle basi tecniche del RWD, e in particolare delle media queries, già in documenti che risalgono al lontano 2001.
Ripercorrendo la storia delle Media Queries, cercherò di spiegare in che modo un’idea o un’esigenza si trasforma in uno standard adottato infine dai browser.
Dalla concezione alla standardizzazione delle nuove funzionalità
Chi sviluppava a cavallo tra gli anni ’90 e i primi 2000 ricorda che le risoluzioni degli schermi dei PC erano poche ma diversificate. Un sito web veniva progettato per una risoluzione specifica e aveva dimensioni fisse. Ciò rappresentava un evidente limite e l’idea di creare siti web “flessibili” iniziò a farsi largo.
L’esigenza di adattare i contenuti allo schermo, indipendentemente dalla sua risoluzione, spinse il W3C a lavorare sulle Media Queries. Vi ricorda qualcosa il codice che segue?
@media screen and (min-width: 400px) and (max-width: 700px) { ... }Ho trovato questo esempio in un Working Draft pubblicato il 4 aprile 2001. No! Non si tratta di un errore di battitura, era proprio il 2001. Per i più curiosi, ecco il link al Working Draft originale.
Creazione delle specifiche e standardizzazione
Cos’è un Working Draft?
Nel mondo dello sviluppo web, un Working Draft è una bozza di lavoro che delinea nuove funzionalità. Questo documento, pur non essendo definitivo, raccoglie idee innovative proposte da sviluppatori e designer desiderosi di spingere il web oltre i limiti conosciuti. Un Working Draft descrive in dettaglio il comportamento previsto, i possibili usi e le condizioni d’uso, ed è condiviso pubblicamente per raccogliere feedback da esperti e dalla community. Le revisioni successive hanno il compito di:
- Definire la sintassi e i parametri da utilizzare.
- Comprendere quali algoritmi scegliere.
- Garantire che la nuova funzionalità si comporti in modo coerente su tutti i browser e dispositivi.
- Valutare l’impatto sulle performance.
- Verificare la corretta integrazione con il modello di rendering esistente.
- Gestire i casi limite e le eccezioni.
I principali enti coinvolti in questo processo sono il W3C (per CSS, SVG e altri standard), il WHATWG (per HTML e DOM) e il TC39 (per JavaScript). È importante ricordare che chiunque può proporre nuove idee o miglioramenti attraverso la partecipazione a mailing list, forum, blog e piattaforme come GitHub.
Le media queries: un percorso lungo
Nonostante l’idea delle media queries sia nata nel 2001, la loro adozione ufficiale è avvenuta solo molti anni dopo, con il CSS3. Perché questo ritardo? I passaggi intermedi sono stati numerosi:
Prototipazione e test iniziali (2001 - anni 2000)
Con i primi Working Draft si iniziava a sperimentare già la sintassi delle media queries. Tuttavia, l’ambiente dei dispositivi era limitato e la necessità di un web adattabile non era ancora impellente. Le implementazioni iniziali venivano testate in ambienti sperimentali o in browser di nicchia, spesso utilizzando prototipi e strumenti interni.
Evoluzione del contesto tecnologico
Durante gli anni 2000, l’adozione dei dispositivi mobili e la diversificazione delle risoluzioni degli schermi aumentarono notevolmente la domanda di soluzioni flessibili. Questo cambiamento spinse il W3C e la community a rivedere e raffinare il concetto iniziale delle media queries.
Iterazioni e raffinamenti
Attraverso il continuo feedback della community e numerosi test, il draft delle media queries venne iterato per includere nuove funzionalità, gestire casi limite e garantire interoperabilità. Durante questa fase, le specifiche furono progressivamente aggiornate fino a diventare parte integrante del CSS3.
Test e implementazioni nei browser
Durante questo periodo, i browser iniziarono a supportare le media queries in maniera sperimentale – spesso tramite l’uso di vendor prefix (come -webkit- o -moz-) e versioni beta/canary. Strumenti come i Web Platform Tests e prototipi sviluppati dalla community furono fondamentali per identificare e correggere anomalie.
Formalizzazione nel CSS3 (circa 2012)
Intorno al 2012, le media queries raggiunsero uno stadio di maturità sufficiente da essere integrate ufficialmente nello standard CSS3. Questo passaggio fu possibile grazie alla crescente domanda di design responsive e al consolidamento delle esperienze di test raccolte negli anni precedenti.
Dalla Candidate Recommendation alla Recommendation
Dopo il lungo percorso di raffinamento di una specifica, si arriva alla fase di Candidate Recommendation. In questo stadio, le nuove funzionalità – come le media queries – vengono implementate nelle versioni di sviluppo dei browser (canary, nightly o beta). Gli sviluppatori possono testare la funzionalità, fornendo feedback essenziali attraverso:
- Versioni sperimentali dei browser: per verificare il comportamento in condizioni reali.
- Suite di test automatizzate: come i Web Platform Tests, che assicurano l’interoperabilità tra browser.
- Prototipi e casi studio: che dimostrano l’applicazione pratica della funzionalità in progetti reali.
Durante questa fase, potrebbero essere necessari dei prefissi (ad esempio -webkit- o -moz-) o l’abilitazione manuale di opzioni sperimentali (come quelle accessibili da chrome://flags in Chrome).
Una volta completati i test e raccolto un feedback positivo, la funzionalità viene formalmente approvata nella fase di Recommendation. A questo punto, viene integrata nelle versioni stabili dei browser, senza la necessità di prefissi o flag sperimentali, e diventa uno standard documentato e adottato a livello globale. Naturalmente, la raccolta continua di feedback può portare a futuri aggiornamenti o revisioni, mantenendo lo standard sempre in evoluzione.
L'evoluzione continua
Lo status di Recommendation non è un punto di arrivo definitivo, ma una tappa “intermedia”. Il percorso di una funzionalità web, infatti, non si ferma. Riprendendo il caso delle Media Queries, dal 2012 ad oggi, lo standard CSS3 ha continuato ad evolversi per poter rispondere alle nuove esigenze e alle tendenze tecnologiche.
Grazie all'adozione ufficiale delle Media Queries, il Responsive Web Design è riuscito a diffondersi e a stabilire il primo grande traguardo di adattabilità dei siti web. Sono nate però nuove necessità che a loro volta hanno richiesto aggiornamenti e nuove soluzioni. Tra queste abbiamo assistito all'emergere delle Container Queries, una novità che permette di applicare stili non solo in base alle dimensioni della finestra del browser, ma anche in relazione allo spazio disponibile in un determinato contenitore.
Un esempio pratico di Container Query potrebbe essere il seguente:
@container (min-width: 300px) {
.card {
grid-template-columns: 1fr 1fr;
}
}In questo esempio, il layout della classe .card si adatta in due colonne solo se il contenitore raggiunge almeno 300px di larghezza, permettendo una gestione più modulare e contestuale del design.
Oltre alle Container Queries, vi sono stati altri aggiornamenti rilevanti che hanno arricchito il mondo del CSS, come:
- Flexbox: Introdotto per gestire layout in una dimensione, Flexbox ha rivoluzionato la disposizione degli elementi, rendendo più semplice l'allineamento e la distribuzione dello spazio in modo dinamico. La sua capacità di adattarsi a contenitori di dimensioni variabili ha contribuito notevolmente alla realizzazione di design responsive.
- CSS Grid Layout e Subgrid: Questi strumenti hanno permesso di gestire layout complessi in due dimensioni, offrendo una maggiore flessibilità e controllo sulla disposizione degli elementi.
- Variabili CSS (Custom Properties): Hanno aperto la strada a stili dinamici e facilmente manutenibili, favorendo la creazione di design tematici e responsive.
- Nuove unità e funzioni matematiche: La loro introduzione ha reso possibile eseguire calcoli direttamente nei fogli di stile, migliorando ulteriormente la responsività e l'adattabilità dei layout.
Una volta standardizzata, una funzionalità non diventa un punto fermo nel tempo. Continua con un processo di raffinamento e aggiornamento. Si adatta in linea con le nuove tecnologie, le tendenze emergenti e le necessità sempre più sofisticate degli sviluppatori e degli utenti. Il web, infatti, è sempre stato un “organismo” in continua evoluzione, dove ogni standard serve da base per nuove innovazioni e migliorie.
L’utilizzo nei progetti
Da sviluppatore front-end, è essenziale verificare la diffusione del nuovo standard a livello globale prima di adottarlo in produzione. Al rilascio ufficiale, la capillarità del supporto può variare – per me, una diffusione accettabile si aggira tra il 90 e il 95%, a seconda della funzionalità e del target di utenti. Le cause di una diffusione inferiore possono essere molteplici: dall’utilizzo di dispositivi datati alla mancata attivazione degli aggiornamenti automatici, fino ai ritardi nei rilasci da parte dei produttori di browser.
A volte, però, è possibile implementare funzionalità sperimentali senza compromettere il rendering o l'usabilità, anche se alcuni browser non le supportano ancora. Prendiamo ad esempio la recente regola @view-transition: questa permette di applicare transizioni tra le pagine all’interno di uno stesso sito. Al momento, Firefox non la supporta ancora, ma è già possibile implementarla per gli utenti di altri browser, garantendo una progressiva adozione dello standard.
Conclusioni
Abbiamo visto come il percorso che porta dalla concezione di una nuova funzionalità fino alla sua implementazione nei browser è lungo e articolato. In questo articolo, lo abbiamo fatto prendendo come esempio quello delle Media Queries: dall’idea iniziale del 2001, passando per decenni di iterazioni, test sperimentali e feedback della community, fino alla formalizzazione nel CSS3 nel 2012. Ogni fase è stata essenziale per garantire che un’evoluzione coerente, affidabile e accessibile. Questo processo iterativo è la chiave dell’innovazione: ogni standard, una volta raggiunta la fase di Recommendation, continua a evolversi per rispondere alle nuove esigenze tecnologiche e alle sfide future.