Miriam Suzanne è un'autrice, artista e sviluppatrice web di Denver, in Colorado, e attualmente sta lavorando a specifiche CSS entusiasmanti come le query sui contenitori e i livelli a cascata.
Questo post fa parte di Designcember. Una celebrazione del web design, offerta da web.dev.
Miriam Suzanne è un'autrice, artista e sviluppatrice web di Denver, Colorado. È cofondatrice di OddBird (un'agenzia web), autrice di articoli per CSS Tricks, membro del team principale di Sass ed esperta invitata del gruppo di lavoro CSS del W3C. Ultimamente si è concentrata sullo sviluppo di nuove funzionalità CSS come i livelli a cascata, le query sui contenitori e l'ambito. Nella vita reale, Miriam è una scrittrice, drammaturga e musicista. Abbiamo parlato del suo lavoro con Sass e CSS.
Rachel: ho scoperto il tuo lavoro grazie al framework a griglia Susy. Cosa ti ha spinto a crearlo?
Miriam: nel 2008, il layout sul web era un'esperienza molto diversa. Gli sviluppatori avevano abbandonato il layout a tabella per passare a griglie flottanti più semantiche (ma ancora approssimative). Si è verificato un boom dei "framework di griglia" a 12 colonne adatti a tutti, che forniscono una griglia predefinita (di solito statica) con un insieme di classi CSS predefinite. Se avevi bisogno di qualcosa di più personalizzabile, dovevi arrangiarti. Era chiaro che i siti web dovevano diventare più reattivi, ma le media query non erano ancora disponibili e c'erano molti problemi di compatibilità del browser con i float fluidi.
Utilizzavo l'approccio CSS Systems di Natalie Downe, che rispondeva in modo intelligente alle dimensioni del carattere e dell'area visibile, ma ero frustrato da tutti i calcoli ripetitivi e dagli hack del browser necessari. Allo stesso tempo, Sass stava iniziando a ricevere un po' di attenzione e si adattava perfettamente alle mie esigenze. La prima bozza di Susy era molto semplice: solo un paio di mixin per fare i calcoli e aggiungere gli hack di cui avevo bisogno. L'obiettivo era di essere minimali e di restituire solo il codice essenziale. Griglie totalmente personalizzabili, senza classi predefinite.
Rachel: come hai fatto a passare dal lavoro su un pre-processore CSS a quello sulle specifiche CSS? Pensi che lavorare sul preprocessor sia stato un buon background per la scrittura delle specifiche?
Miriam: nella mia esperienza c'è molta sovrapposizione e sono ancora molto attiva su entrambi i lati di questa divisione. Ma credo che questo sia dovuto in gran parte al team di Sass, in particolare a Natalie Weizenbaum, che adotta una visione a lungo termine, cercando di sviluppare strumenti che si integrino perfettamente con gli standard web in evoluzione. Superare le soluzioni "basate su opinioni" e creare soluzioni flessibili a lungo termine è essenziale quando pensi al futuro degli standard web di base.
Come possiamo creare strumenti che rispettino la diversità delle esigenze e degli approcci degli sviluppatori, incoraggiando e facilitando al contempo l'accessibilità e altre considerazioni importanti?
Rachel: Stiamo introducendo in CSS una serie di funzionalità che sostituiscono quelle tradizionalmente parte di Sass. Esistono validi motivi per utilizzare ancora qualcosa come Sass?
Miriam: sì, per alcune persone, ma non esiste una risposta universale. Prendiamo ad esempio le variabili. Le variabili Sass hanno ambito lessicale e vengono compilate sul server, con strutture di dati organizzate come elenchi e oggetti, manipolazione del colore e così via. Questo è ideale per la logica del sistema di progettazione che non deve essere eseguita nel browser.
Le variabili CSS si sovrappongono in parte, possono anche memorizzare valori, ma forniscono un insieme completamente diverso di punti di forza e debolezza basati sulla cascata. Sass non può gestire le proprietà personalizzate e CSS non può gestire i dati strutturati. Entrambi sono utili e potenti, ma le tue esigenze specifiche possono variare.
Penso che sia fantastico quando le persone possono eliminare gli strumenti di cui non hanno più bisogno e alcuni progetti potrebbero non richiedere variabili lato server e lato client. Fantastico! Ma è troppo semplice presumere che siano identici e che uno sostituisca semplicemente l'altro. Esisteranno sempre casi d'uso in cui alcune logiche di progettazione dovranno essere eseguite lato server e altre lato client, anche se arriveremo al punto in cui i linguaggi forniranno essenzialmente le stesse funzionalità. I pre-elaboratori rimarranno con noi a lungo termine.
Rachel: C'è qualcosa che ti ha sorpreso man mano che ti sei impegnata di più nel lavoro di creazione degli standard o qualcosa che pensi che le persone in generale potrebbero non conoscere della procedura?
Miriam: prima di partecipare, la procedura di definizione degli standard mi sembrava una scatola nera misteriosa e magica e non sapevo cosa aspettarmi. Avevo paura di non avere abbastanza conoscenze interne del browser per dare il mio contributo, ma la realtà è che non hanno bisogno di altri ingegneri del browser. Hanno bisogno di più sviluppatori e designer che creino siti web e applicazioni in natura.
Sono rimasto sorpreso di scoprire che pochissime delle persone coinvolte si concentrano principalmente sugli standard, ma anche che pochissime di loro si occupano principalmente di sviluppo o progettazione di siti web. Il W3C è composto da "volontari" delle organizzazioni membri (spesso pagati da queste organizzazioni, ma non come lavoro principale) e l'iscrizione non è economica. Questo allontana i partecipanti dai designer e dagli sviluppatori di tutti i giorni, soprattutto quelli di noi che lavorano per i clienti in piccole agenzie o come freelance. Il mio ruolo di Esperto invitato sarebbe totalmente volontario, un hobby costoso, se non avessi trovato finanziamenti esterni per questo lavoro.
In realtà, il processo è piuttosto aperto e pubblico e richiede il coinvolgimento degli sviluppatori, ma ci sono sempre così tante conversazioni in corso contemporaneamente che può essere difficile trovare il proprio spazio. Soprattutto se non è il tuo lavoro principale.
Rachel: le query sui contenitori sono state il Santo Graal per molti sviluppatori web per anni. Sono molto entusiasta del fatto che li stiamo ricevendo. Ho l'impressione che molte persone stiano pensando all'utilità delle query sui contenitori. Pensi che abbiano il potenziale per sbloccare anche più creatività?
Miriam: assolutamente, anche se non le vedo come cose completamente separate. Il tempo a nostra disposizione è limitato e cerchiamo di scrivere codice gestibile e performante. Quando qualcosa è difficile da fare praticamente, è meno probabile che si diventi creativi con ciò che è possibile.
Tuttavia, il settore del web è ora dominato da grandi interessi aziendali, quindi queste preoccupazioni commerciali hanno sempre più spazio rispetto agli artisti del web. Penso che perdiamo molto se ignoriamo la creatività web come caso d'uso principale delle funzionalità. Sono molto entusiasta di vedere alcuni artisti CSS che sperimentano il prototipo di query sul contenitore. Jhey Tompkins ha creato una demo particolarmente intelligente e interattiva di persiane CSS come commento al vecchio meme anti-CSS. Penso che ci sia ancora molto da esplorare in questo spazio e non vedo l'ora di scoprire cos'altro inventeranno le persone.
La conversazione si è concentrata anche sulle query basate sulle dimensioni, come caso d'uso originale, ma sono entusiasta di vedere cosa faranno le persone con le query di stile, ovvero la possibilità di scrivere stili condizionali in base al valore di una proprietà o variabile CSS. È una funzionalità estremamente potente e finora in gran parte inesplorata. Penso che offra ancora più opportunità creative.
Rachel: C'è qualcosa che non possiamo fare (o che potremo fare in futuro) in CSS che ritieni utile?
Miriam: sono molto entusiasta di alcune altre specifiche su cui ho lavorato. I livelli a cascata offrono agli autori un maggiore controllo sui problemi di specificità, mentre Scope dovrebbe contribuire a un targeting più preciso dei selettori. Ma entrambi riguardano l'architettura di alto livello. L'artista che è in me è più entusiasta di cose come i pulsanti di attivazione/disattivazione CSS, un modo dichiarativo per creare stili interattivi o le "timeline" dei contenitori, che ci consentono di eseguire la transizione dei valori in modo fluido tra i breakpoint dei media o dei contenitori. Ciò ha implicazioni molto pratiche per la tipografia adattabile, ma aprirebbe anche molte opportunità creative per l'arte e l'animazione adattabili.
Rachel: chi altro sta realizzando lavori davvero interessanti, divertenti o creativi sul web in questo momento?
Miriam: Non so nemmeno come rispondere, ci sono così tante persone che svolgono attività creative in ambiti così diversi. Il CSSWG e Open-UI stanno lavorando a molti standard entusiasmanti, tra cui alcuni dei tuoi lavori sulla frammentazione. Spesso, però, trovo la maggiore ispirazione negli artisti del web e nel modo in cui le persone utilizzano questi strumenti nella produzione, in modi non direttamente legati al commercio. Persone come Jhey, Lynn Fisher, Yuan Chuan o molte altre che stanno superando i limiti di ciò che le tecnologie web possono fare a livello visivo e interattivo. Anche le persone che svolgono un lavoro più orientato al business possono imparare molto dalle loro tecniche artistiche.
Apprezzo anche l'arte concettuale di persone come Ben Grosser, che ci spinge a riconsiderare ciò che vogliamo dal web e dai social media in particolare. Dai un'occhiata al suo nuovo minus.social, ad esempio.
Rachel: segui il lavoro di Miriam su CSS all'indirizzo css.oddbird.net e scopri le altre sue attività sul suo sito web miriam.codes e su Twitter @TerribleMia.