Miriam Suzanne ist Autorin, Künstlerin und Webentwicklerin in Denver, Colorado. Sie arbeitet derzeit an spannenden CSS-Spezifikationen wie Container Queries und Cascade Layers.
Dieser Beitrag ist Teil von Designcember. Eine Hommage an das Webdesign von web.dev.
Miriam Suzanne ist Autorin, Künstlerin und Webentwicklerin in Denver, Colorado. Sie ist Mitbegründerin von OddBird (einer Webagentur), Mitarbeiterin von CSS Tricks, Mitglied des Sass-Kernteams und W3C Invited Expert in der CSS Working Group. In letzter Zeit hat sie sich auf die Entwicklung neuer CSS-Funktionen wie Cascade Layers, Container Queries und Scope konzentriert. Miriam ist eine veröffentlichte Romanautorin, Dramatikerin und Musikerin. Wir haben mit ihr über ihre Arbeit mit Sass und CSS gesprochen.
Rachel:Ich habe zuerst durch dein Raster-Framework Susy von deiner Arbeit erfahren. Was hat dich dazu bewogen, es zu erstellen?
Miriam:2008 war das Layout im Web noch ganz anders. Entwickler hatten sich vom Tabellenlayout abgewandt und nutzten stattdessen semantischere (aber immer noch umständliche) schwebende Grids. Es gab einen Boom bei universellen 12‑spaltigen „Grid-Frameworks“, die ein vordefiniertes (in der Regel statisches) Grid mit einer Reihe vordefinierter CSS-Klassen bieten. Wenn Sie etwas individuell Anzupassendes benötigten, waren Sie auf sich allein gestellt. Es war klar, dass Websites responsiver werden mussten, aber Media-Queries waren noch nicht verfügbar und es gab viele Probleme mit der Browserkompatibilität bei fließenden Floats.
Ich habe den CSS-Systemansatz von Natalie Downe verwendet, der sowohl auf Schriftart- als auch auf Darstellungsbereichsgrößen reagiert. Allerdings war ich frustriert von den vielen sich wiederholenden Berechnungen und Browser-Hacks, die erforderlich waren. Gleichzeitig wurde Sass immer beliebter und passte perfekt zu meinen Anforderungen. Der erste Entwurf von Susy war sehr einfach: nur ein paar Mixins, um die Berechnungen durchzuführen und die Hacks hinzuzufügen, die ich brauchte. Das Ziel war, nur den wesentlichen Code auszugeben. Vollständig anpassbare Grids ohne vordefinierte Klassen.
Rachel:Wie bist du von der Arbeit an einem CSS-Präprozessor zur Arbeit an CSS-Spezifikationen gewechselt? Glaubst du, dass die Arbeit am Präprozessor eine gute Grundlage für das Schreiben von Spezifikationen war?
Miriam:Meiner Erfahrung nach gibt es viele Überschneidungen und ich bin immer noch auf beiden Seiten sehr aktiv. Das ist aber vor allem dem Sass-Team unter der Leitung von Natalie Weizenbaum zu verdanken, das einen sehr langfristigen Ansatz verfolgt und versucht, Tools zu entwickeln, die sich nahtlos in die Entwicklung von Webstandards einfügen. Es ist wichtig, über Pauschallösungen hinauszugehen und auf langfristige Flexibilität zu setzen, wenn Sie über die Zukunft der wichtigsten Webstandards nachdenken.
Wie können wir Tools entwickeln, die die Vielfalt der Anforderungen und Ansätze von Entwicklern berücksichtigen und gleichzeitig Barrierefreiheit und andere wichtige Aspekte fördern und erleichtern?
Rachel:Wir haben eine Reihe von Dingen, die in CSS eingeführt werden und im Grunde Funktionen ersetzen, die traditionell Teil von Sass waren. Gibt es gute Gründe, weiterhin Sass zu verwenden?
Miriam:Ja, für einige Menschen schon, aber es gibt keine universelle Antwort. Nehmen wir zum Beispiel Variablen. Sass-Variablen sind lexikalisch begrenzt und werden auf dem Server kompiliert. Sie bieten organisierte Datenstrukturen wie Listen und Objekte, Farbmanipulation usw. Das ist ideal für die Logik von Designsystemen, die nicht im Browser ausgeführt werden muss.
CSS-Variablen haben einige Überschneidungen, da sie auch Werte speichern können. Sie bieten jedoch eine völlig andere Reihe von kaskadenbasierten Stärken und Schwächen. Sass kann keine benutzerdefinierten Properties verarbeiten und CSS kann strukturierte Daten nicht wirklich verarbeiten. Beide sind nützlich und leistungsstark, aber Ihre spezifischen Anforderungen können variieren.
Ich finde es toll, wenn Nutzer Tools entfernen können, die sie nicht mehr benötigen. Bei einigen Projekten sind möglicherweise nicht sowohl serverseitige als auch clientseitige Variablen erforderlich. Wunderbar! Es ist jedoch zu einfach anzunehmen, dass sie identisch sind und das eine das andere einfach ersetzt. Es wird immer Anwendungsfälle geben, in denen ein Teil der Designlogik serverseitig und ein Teil clientseitig ausgeführt wird, selbst wenn die Sprachen im Wesentlichen dieselben Funktionen bieten. Vorprozessoren sind für uns langfristig wichtig.
Rachel:Gibt es etwas, das dich überrascht hat, als du dich mehr mit der Entwicklung von Standards beschäftigt hast, oder etwas, das die Leute im Allgemeinen vielleicht nicht über den Prozess wissen?
Miriam:Bevor ich mich beteiligt habe, war der Standardisierungsprozess für mich wie eine mysteriöse und magische Blackbox. Ich wusste nicht, was mich erwarten würde. Ich hatte Angst, dass ich nicht genug Wissen über Browserinterna habe, um einen Beitrag zu leisten, aber in Wirklichkeit brauchen sie nicht mehr Browserentwickler. Sie benötigen mehr Entwickler und Designer, die Websites und Anwendungen entwickeln.
Ich war überrascht, dass nur sehr wenige der Beteiligten sich hauptsächlich auf Standards konzentrieren, aber auch nur sehr wenige von ihnen hauptsächlich Websites entwickeln oder gestalten. Das W3C besteht aus „Freiwilligen“ von Mitgliedsorganisationen (die oft von diesen Organisationen bezahlt werden, aber nicht als Hauptberuf) und die Mitgliedschaft ist nicht billig. Das führt dazu, dass die Teilnehmer nicht die typischen Designer und Entwickler sind, insbesondere nicht diejenigen, die in kleinen Agenturen oder als Freelancer für Kunden arbeiten. Meine Rolle als Invited Expert wäre völlig freiwillig und ein teures Hobby, wenn ich keine externe Finanzierung für diese Arbeit gefunden hätte.
In Wirklichkeit ist der Prozess ziemlich offen und öffentlich und erfordert die Beteiligung von Entwicklern. Da aber immer so viele Gespräche gleichzeitig stattfinden, kann es schwierig sein, sich einzubringen. Das gilt insbesondere, wenn Sie nicht hauptberuflich als Creator tätig sind.
Rachel:Container-Abfragen sind seit vielen Jahren das Nonplusultra für viele Webentwickler. Ich freue mich sehr, dass wir sie bekommen. Viele Leute denken über den Nutzen von Container-Abfragen nach. Glaubst du, dass sie auch das Potenzial haben, mehr Kreativität zu ermöglichen?
Miriam:Ja, aber ich sehe diese beiden Aspekte nicht als völlig getrennt an. Wir alle haben nur begrenzt Zeit und versuchen, wartungsfreundlichen und leistungsstarken Code zu schreiben. Wenn etwas praktisch schwer umzusetzen ist, sind wir weniger geneigt, kreativ zu werden.
Dennoch wird die Webbranche heute von großen Unternehmen dominiert, sodass diese geschäftlichen Anliegen immer mehr Aufmerksamkeit erhalten als Webkünstler. Ich denke, wir verpassen viel, wenn wir Webkreativität als primären Anwendungsfall für Funktionen ignorieren. Ich habe mich sehr gefreut, dass einige CSS-Künstler mit dem Prototyp für Containerabfragen experimentiert haben. Jhey Tompkins hat eine besonders clevere und interaktive Demo von CSS-Jalousien als Kommentar zum alten Anti-CSS-Meme erstellt. Ich denke, es gibt noch viel mehr zu entdecken, und ich bin gespannt, was sich die Leute noch einfallen lassen.
Das Gespräch hat sich auch auf größenbasierte Anfragen konzentriert, da dies der ursprüngliche Anwendungsfall war. Ich bin aber gespannt, was die Leute mit Stilanfragen machen werden – die Möglichkeit, bedingte Stile basierend auf dem Wert einer CSS-Eigenschaft oder ‑Variablen zu schreiben. Es ist eine extrem leistungsstarke Funktion, die bisher kaum genutzt wird. Ich glaube, dass sich dadurch noch mehr kreative Möglichkeiten ergeben.
Rachel:Gibt es etwas, das wir in CSS nicht tun können (oder demnächst tun können), das deiner Meinung nach nützlich wäre?
Miriam:Ich freue mich sehr auf einige andere Spezifikationen, an denen ich gearbeitet habe. Kaskadenebenen geben Autoren mehr Kontrolle über Spezifitätsprobleme und „Scope“ sollte dabei helfen, Selektoren genauer auszurichten. Beide sind jedoch übergeordnete architektonische Aspekte. Als Künstler freue ich mich mehr auf Dinge wie CSS-Umschalter, eine deklarative Methode zum Erstellen interaktiver Stile oder Container-„Zeitachsen“, mit denen wir Werte zwischen Media- oder Container-Breakpoints nahtlos überblenden können. Das hat sehr praktische Auswirkungen auf die responsive Typografie, würde aber auch viele kreative Möglichkeiten für responsive Kunst und Animationen eröffnen.
Rachel:Wer macht derzeit wirklich interessante, unterhaltsame oder kreative Arbeit im Web?
Miriam:Oh, das ist schwer zu beantworten. Es gibt so viele Menschen, die in so unterschiedlichen Bereichen kreativ arbeiten. Sowohl die CSSWG als auch Open-UI arbeiten an vielen spannenden Standards, darunter auch an der Fragmentierung. Am meisten Inspiration finde ich aber oft bei Webkünstlern und bei der Art und Weise, wie Menschen diese Tools in der Produktion einsetzen, ohne dass es dabei direkt um den Handel geht. Personen wie Jhey, Lynn Fisher oder Yuan Chuan und viele andere, die die Grenzen dessen, was Webtechnologien visuell und interaktiv leisten können, immer wieder neu definieren. Auch Menschen, die eher geschäftsorientiert arbeiten, können viel von ihren künstlerischen Techniken lernen.
Ich schätze auch die konzeptionellere Webkunst von Künstlern wie Ben Grosser, der uns immer wieder dazu anregt, darüber nachzudenken, was wir vom Web und insbesondere von den sozialen Medien erwarten. Sehen Sie sich zum Beispiel sein neues minus.social an.
Rachel: Auf css.oddbird.net können Sie sich über Miriams Arbeit an CSS informieren. Auf ihrer Website miriam.codes und auf Twitter @TerribleMia erfahren Sie, was sie sonst noch macht.