Miriam Suzanne è un'autrice, artista e sviluppatore web di Denver, in Colorado, che al momento sta lavorando a specifiche interessanti per il CSS, come le query container e i livelli Cascade.
Questo post fa parte di Designcember. Una celebrazione del web design, offerta da web.dev.
Miriam Suzanne è un'autrice, artista e sviluppatore web di Denver, in Colorado. È cofondatrice di OddBird (un'agenzia web), staff writer per CSS Tricks, membro del team principale di Sass e W3C Invite Expert nel CSS Working Group. Di recente si è concentrata sullo sviluppo di nuove funzionalità CSS come i livelli a cascata, le query container e l'ambito. Quando è offline, Miriam è una scrittrice, drammaturca e musicista pubblicata. Abbiamo parlato del suo lavoro con Sass e CSS.
Rachel: Ho scoperto il tuo lavoro per la prima volta grazie alla tua struttura a griglia Susy, cosa ti ha spinto a farlo?
Miriam: Nel 2008, il layout sul web era un'esperienza molto diversa. Gli sviluppatori erano passati dal layout delle tabelle a griglie fluttuanti più semantiche (ma comunque complicate). È stato registrato un boom dei "quadri griglia" a 12 colonne a dimensione unica, che hanno fornito una griglia predefinita (solitamente statica) con un insieme di classi CSS predefinite. Se avevi bisogno di qualcosa di più personalizzabile, eri da solo. Era chiaro che i siti web dovevano diventare più reattivi, ma le query multimediali non erano ancora disponibili e c'erano molti problemi di compatibilità dei browser riguardo ai fluttuanti fluidi.
Stavo usando l'approccio CSS Systems di Natalie Downe, che era molto intelligente nel rispondere alle dimensioni di entrambi i caratteri e aree visibili, ma ero deluso da tutte le operazioni matematiche ripetitive e di violazione del browser necessarie. Allo stesso tempo, Sass stava iniziando ad avere un po' di attenzione e si adattava perfettamente a ciò di cui avevo bisogno. La prima bozza di Susy è stata molto semplice: solo un paio di mix per fare il calcolo e aggiungere i trucchi di cui avevo bisogno. L'obiettivo era essere minimo e produrre solo il codice essenziale. Griglie completamente personalizzabili, senza classi predefinite.
Rachel: In che modo sei passato dal lavoro su un preprocessore CSS all'elaborazione delle specifiche CSS? Pensi che il lavoro sul preprocessore sia stato un buon background per scrivere le specifiche?
Miriam: Nella mia esperienza ci sono molte sovrapposizioni e sono ancora molto attivo su entrambi i lati di questo divario. Penso, tuttavia, che ciò sia in gran parte dovuto al team Sass, guidato in particolare da Natalie Weizenbaum, che ha una visione a lungo termine, cercando di sviluppare strumenti che si integrino facilmente con gli standard web in fase di sviluppo. Una soluzione che vada oltre l'approccio "omogeneo" e sviluppare soluzioni flessibili a lungo termine è essenziale quando si pensa al futuro dei principali standard web.
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: Ci sono molti elementi in arrivo in CSS che sostanzialmente sostituiscono le funzionalità tradizionalmente facenti parte di Sass. Ci sono valide ragioni per usare ancora qualcosa come Sass?
Miriam: Sì, per alcuni, ma non esiste una risposta universale in questo caso. Prendiamo come esempio le variabili. Le variabili Sass hanno un ambito didattico e vengono compilate sul server, con strutture di dati organizzate come elenchi e oggetti, manipolazione del colore e così via. Questo è ottimo per la logica del sistema di progettazione che non deve essere eseguita nel browser.
Le variabili CSS hanno una certa sovrapposizione; possono anche memorizzare i valori, ma forniscono un insieme completamente diverso di punti di forza e di debolezza basati a cascata. Sass non può gestire le proprietà personalizzate e il CSS non può gestire i dati strutturati. Entrambi sono utili ed entrambi sono potenti, ma le tue esigenze specifiche possono variare.
Penso che sia fantastico poter 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 supporre che siano identici e che uno si sostituisce semplicemente all'altro. Ci saranno sempre casi d'uso in cui una logica di progettazione avvenga sul lato server e altre sul lato client, anche se arriviamo al punto in cui i linguaggi forniscono sostanzialmente le stesse funzionalità. I pre-processori sono con noi per il lungo termine.
Rachel: C'è qualcosa che ti ha sorpreso dal momento che ti sei impegnato di più nella creazione di standard o qualcosa di cui pensi che la gente in generale potrebbe non essere a conoscenza del processo?
Miriam: Prima di essere coinvolta, il processo degli standard sembrava una scatola nera misteriosa e magica e non sapevo cosa aspettarmi. Temevo di non avere conoscenze interne del browser sufficienti per poter dare il mio contributo, ma in realtà non hanno bisogno di altri tecnici del browser. Hanno bisogno di più sviluppatori e designer che stiano creando siti web e applicazioni in circolazione.
Mi ha sorpreso scoprire che pochissime persone coinvolte si concentrano principalmente sugli standard, ma anche pochissime di loro sviluppano o progettano siti web principalmente. Il W3C è formato da "volontari" Organizzazioni che aderiscono (spesso retribuite da tali organizzazioni, ma non come loro lavoro principale) e l'adesione non è economica. Ciò allontana i partecipanti dai designer e dagli sviluppatori che usano tutti i giorni, in particolare quelli di noi che lavorano con i clienti in piccole agenzie o come freelance. Il mio ruolo di esperto invitato sarebbe stato del tutto volontario, un hobby costoso, se non avessi trovato finanziamenti esterni per questo lavoro.
In realtà, il processo è piuttosto aperto e pubblico e richiede l'intervento degli sviluppatori, ma ci sono sempre così tante conversazioni che si svolgono contemporaneamente e trovare una posizione può essere difficile. Soprattutto se non è il tuo lavoro abituale.
Rachel: le query container sono da molti anni un punto di riferimento per molti sviluppatori web. Sono davvero entusiasta del fatto che le stiamo ottenendo. Ho la sensazione che molte persone pensino all'utilità delle query container: ritieni che abbiano il potenziale per liberare anche più creatività?
Miriam: Assolutamente, anche se non li considero completamente separati. Abbiamo tutti poco tempo a disposizione e stiamo cercando di scrivere codice gestibile e dalle prestazioni elevate. Quando qualcosa è difficile da fare in pratica, è meno probabile che sia possibile dare libero sfogo alla creatività.
Tuttavia, il settore del web è ora dominato da grandi interessi aziendali, quindi queste preoccupazioni aziendali hanno sempre più tempo di trasmissione degli artisti web. Penso che si perderà molto se ignoriamo la creatività web come caso d'uso principale per le funzionalità. Sono molto entusiasta di vedere alcune delle persone che si occupano di CSS art giocando con il prototipo di query container. Jhey Tompkins ha realizzato una demo particolarmente intelligente e interattiva delle veneziane dei CSS come commento al vecchio meme anti-CSS. Penso che ci sia molto altro da esplorare in questo spazio e non vedo l'ora di scoprire cos'altro viene in mente.
La conversazione si è concentrata anche sulle query basate sulle dimensioni, come caso d'uso originale, ma sono entusiasta di vedere cosa fanno le persone con le query di stile, ovvero la capacità di scrivere stili condizionali in base al valore di una proprietà o variabile CSS. Si tratta di una funzionalità estremamente potente e finora per lo più inesplorata. Penso che possa aprire altre opportunità creative.
Rachel: C'è qualcosa che non possiamo fare (o che prevediamo di adottare in futuro) in CSS che ritieni possa essere utile?
Miriam: Sono molto entusiasta delle altre specifiche a cui sto lavorando. I livelli a cascata offrono agli autori un maggiore controllo sui problemi di specificità, mentre l'ambito dovrebbe aiutare con un targeting del selettore più preciso. Ma entrambi sono problemi architetturali di alto livello. L'artista in me è più entusiasta di elementi come le opzioni di attivazione/disattivazione CSS, un modo dichiarativo per creare stili interattivi o "sequenze temporali" dei container, che ci consentono di trasferire facilmente i valori tra i punti di interruzione dei contenuti multimediali o dei container. Ciò ha implicazioni molto pratiche per la tipografia adattabile, ma potrebbe anche aprire molte opportunità creative per l'arte e l'animazione adattabili.
Rachel: Chi altri sta facendo lavori davvero interessanti, divertenti o creativi sul web in questo momento?
Miriam: Oh, non sono nemmeno sicuro di come rispondere, ci sono così tante persone che svolgono il lavoro creativo in aree così diverse. Sono in corso numerosi standard entusiasmanti, sia da CSSWG che da Open-UI, tra cui alcuni lavori sulla frammentazione. Spesso, però, trovo più ispirazione degli artisti web e del modo in cui le persone mettono in produzione questi strumenti in modi non direttamente legati al commercio. Persone come Jhey, Lynn Fisher, Yuan Chuan o molte altre persone che si stanno spingendo oltre i limiti di ciò che le tecnologie web possono fare in modo visivo e interattivo. Persino le persone che svolgono un lavoro maggiormente orientato al business possono imparare molto dalle loro tecniche artistiche.
Apprezzo anche la web art più concettuale di persone come Ben Grosser, che continua a spingerci a riconsiderare ciò che vogliamo dal web e dai social media in particolare. Dai un'occhiata al suo nuovo minus.social, ad esempio.
Rachel: Stai al passo con il lavoro di Miriam in CSS all'indirizzo css.oddbird.net e scopri cos'altro sta facendo tramite il suo sito web all'indirizzo miriam.codes e Twitter @TerribleMia.