Miriam Suzanne è autrice, artista e sviluppatrice web a Denver, in Colorado, e sta attualmente lavorando a specifiche interessanti per CSS come Container Queries e Cascade Livelli.
Questo post fa parte di Designcember, Una celebrazione del web design, offerta da web.dev.
Miriam Suzanne è autrice, artista e sviluppatrice web a Denver, in Colorado. È cofondatrice di OddBird (un'agenzia web), writer per CSS Tricks, membro del team principale di Sass ed esperto invitato di W3C nel CSS Working Group. Di recente si è concentrata sullo sviluppo di nuove funzionalità CSS come i livelli Cascade, le query del container e l'ambito. Offline, Miriam è una scrittrice, drammaturga e musicista pubblicata. Abbiamo parlato del suo lavoro con Sass e CSS.
Rachel: Ho scoperto il tuo lavoro grazie alla struttura della griglia Susy. Cosa ti ha spinto a crearlo?
Miriam: Nel 2008, il layout sul web era un'esperienza molto diversa. Gli sviluppatori sono passati dal layout delle tabelle a griglie mobili più semantiche (ma ancora al centro). C'è stato un boom in "framework griglia" a 12 colonne a dimensione unica, a fornire una griglia predefinita (solitamente statica) con un set di classi CSS predefinite. Se avessi bisogno di qualcosa di più personalizzabile, eri in autonomia. Era chiaro che i siti web dovevano diventare più reattivi, ma le query multimediali non erano ancora disponibili e c'erano numerosi problemi di compatibilità del browser in merito ai flussi in virgola mobile.
Usavo l'approccio CSS Systems di Natalie Downe, che era abile nel rispondere a entrambe le dimensioni dei caratteri e delle aree visibili, ma ero frustrato da tutte le ripetitive operazioni matematiche e di pirateria informatica necessarie. Allo stesso tempo, Sass stava iniziando a ricevere 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 i conti e aggiungere i trucchi di cui avevo bisogno. L'obiettivo era essere minimo e restituire solo il codice essenziale. Griglie completamente personalizzabili, senza classi predefinite.
Rachel: Come hai potuto passare dal lavoro su un preprocessore CSS a quello sulle specifiche CSS? Pensi che lavorare sul preprocessore sia stato un buon background per scrivere le specifiche?
Miriam: In base alla mia esperienza, le sovrapposizioni sono molte e sono ancora molto attiva a favore di entrambe le parti. Il merito, però, dipende in gran parte dal team di Sass, guidato da Natalie Weizenbaum, che ha una visione a lungo termine per cercare di sviluppare strumenti che si integrino senza problemi con gli standard web in fase di sviluppo. Spingerci oltre le soluzioni "opinionate" per tutti e creare una flessibilità a lungo termine è essenziale quando si pensa al futuro degli standard web fondamentali.
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: Abbiamo una serie di elementi in CSS che sostanzialmente sostituiscono le funzionalità che in genere facevano parte di Sass. Ci sono validi motivi per utilizzare ancora qualcosa come Sass?
Miriam: Sì, per alcune persone, ma qui non c'è una risposta universale. Prendiamo come esempio le variabili. Le variabili SASS hanno un ambito lessico e sono compilate sul server, con strutture di dati organizzate come elenchi e oggetti, manipolazione del colore e così via. È un'ottima soluzione per la logica del sistema di progettazione che non deve essere eseguita nel browser.
Le variabili CSS hanno alcune sovrapposizioni, possono anche memorizzare valori, ma forniscono un insieme completamente diverso di punti di forza e punti deboli basati a cascata. Sass non può gestire le proprietà personalizzate e il CSS non può davvero gestire i dati strutturati. Sono entrambi utili ed entrambi potenti, ma le tue esigenze specifiche possono variare.
Penso che sia fantastico quando le persone possano eliminare gli strumenti di cui non hanno più bisogno, e alcuni progetti potrebbero non richiedere entrambe le variabili lato server e lato client. Ottimo. Tuttavia, è troppo semplice dare per scontato che siano identici e che uno sostituisca semplicemente l'altro. Ci saranno sempre casi d'uso in cui alcune logiche di progettazione avvengono lato server e altri sul lato client, anche se arriviamo al punto in cui i linguaggi forniscono sostanzialmente le stesse funzionalità. I pre-responsabili sono con noi a lungo termine.
Rachel: C'è qualcosa che ti ha sorpreso perché hai deciso di dedicarti di più al lavoro di creazione degli standard o qualcosa di cui pensi che la gente in generale potrebbe non essere a conoscenza?
Miriam: Prima di mettermi in gioco, il processo relativo agli standard sembrava una scatola nera misteriosa e magica e non sapevo cosa aspettarmi. Temevo di non avere abbastanza conoscenze degli interni del browser per contribuire, ma la realtà è che non hanno bisogno di altri tecnici del browser. Hanno bisogno di più sviluppatori e designer che creino siti web e applicazioni in natura.
È stato sorpreso di scoprire che pochissime delle persone coinvolte si concentrano principalmente sugli standard, ma anche pochissime di loro sviluppano o progettano siti web. Il W3C è composto da "volontari" delle organizzazioni che ne fanno parte (spesso retribuite da queste organizzazioni, ma non come impiego principale) e l'adesione non è economica. Questo allontana i partecipanti dai designer e dagli sviluppatori quotidiani, soprattutto quelli che lavorano con i clienti presso piccole agenzie o freelance. Il mio ruolo di Esperto in invito sarei completamente volontario, un hobby costoso, se non avessi trovato finanziamenti esterni per quel lavoro.
In realtà, la procedura è piuttosto aperta e pubblica e richiede l'intervento degli sviluppatori, ma ci sono sempre così tante conversazioni in corso contemporaneamente che può essere difficile trovare la tua soluzione. Soprattutto se non è il tuo lavoro quotidiano.
Rachel: le query sui container sono da molti anni l'aspirazione massima per molti sviluppatori web. Sono entusiasta del fatto che le stiamo ottenendo. Penso che molte persone pensino all'utilità delle query container. Pensi che abbiano il potenziale per sbloccare anche una maggiore creatività?
Miriam: Assolutamente, anche se non le vedo completamente separate. Tutti abbiamo un tempo limitato e stiamo cercando di scrivere codice gestibile ed efficiente. Quando qualcosa è difficile da fare in pratica, si è meno propensi a dare libero sfogo alla creatività.
Eppure, il settore del web è ora dominato da grandi interessi aziendali, quindi queste preoccupazioni commerciali hanno sempre più tempo di trasmissione rispetto agli artisti web. Penso che perderemo molto se ignoriamo la creatività sul web come caso d'uso principale per le funzionalità. Non vedo l'ora di vedere alcuni creativi del CSS giocare con il prototipo di query container. Jhey Tompkins ha realizzato una demo particolarmente intelligente e interattiva delle veneziane CSS come commento al vecchio meme anti-CSS. Penso che ci siano molte altre cose da esplorare in questo spazio e non vedo l'ora di vedere cos'altro hanno a disposizione le persone.
La conversazione si è concentrata anche sulle query basate sulle dimensioni, come il caso d'uso originale, ma non vedo l'ora di vedere che cosa fanno le persone con le query di stile: la possibilità di scrivere stili condizionali in base al valore di una proprietà o di una variabile CSS. Si tratta di una funzionalità estremamente potente, finora per lo più inesplorata. Penso che offra ancora più opportunità creative.
Rachel: c'è qualcosa che non possiamo fare (o che abbiamo in programma di fare in programma) in CSS che ritieni possa essere utile?
Miriam: Sono entusiasta di alcune altre specifiche a cui sto lavorando. I livelli a cascata offrono agli autori un maggiore controllo sui problemi di specificità e l'ambito dovrebbe consentire un targeting del selettore più preciso. Ma entrambe sono preoccupazioni architettoniche di alto livello. L'artista che c'è in me è più entusiasta di utilizzare i pulsanti di attivazione/disattivazione CSS, un modo dichiarativo per creare stili interattivi, o "sequenze temporali" dei container, che consentono di trasferire in modo fluido i valori tra i punti di interruzione dei contenuti multimediali o del contenitore. Ciò ha implicazioni molto pratiche per la tipografia reattiva, ma aprirebbe anche molte opportunità creative per l'arte reattiva e l'animazione.
Rachel: Chi altri sta svolgendo lavori davvero interessanti, divertenti o creativi sul web in questo momento?
Miriam: Ah, non so nemmeno come rispondere, ci sono così tante persone che svolgono lavori creativi in aree così diverse. Sono in corso molti standard entusiasmanti sia dal CSSWG sia dall'interfaccia utente aperta, incluso parte del tuo lavoro sulla frammentazione. Ma spesso traggo l'ispirazione dai web artist e dal modo in cui le persone mettono questi strumenti nella produzione, in modi non direttamente legati al commercio. Persone come Jhey, Lynn Fisher o Yuan Chuan o molte altre persone che si stanno spingendo oltre i confini delle tecnologie web in grado di fare visivamente e in modo interattivo. Anche 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: resta al passo con il lavoro di Miriam sul CSS all'indirizzo css.oddbird.net e scopri cos'altro sta facendo tramite il suo sito web all'indirizzo miriam.codes e Twitter @TerribleMia.