Miriam Suzanne ist Autorin, Künstlerin und Webentwicklerin aus Denver, Colorado, und arbeitet derzeit an spannenden CSS-Spezifikationen wie Container Queries und Cascade Layers.
Dieser Beitrag ist Teil von Designcember. Ein Hoch auf das Webdesign – präsentiert von web.dev.
Miriam Suzanne ist Autorin, Künstlerin und Webentwicklerin aus Denver, Colorado. Sie ist Mitbegründerin der Webagentur OddBird, Autorin für CSS Tricks, Mitglied des Sass-Kernteams und W3C Invited Expert in der Preisvergleichsportal-Arbeitsgruppe. Kürzlich hat sie sich auf die Entwicklung neuer CSS-Funktionen wie Cascade Layers, Container Queries und Scope konzentriert. Miriam ist Offline-Autorin, Dramatikerin und Musikerin. Wir haben über ihre Arbeit mit Sass und CSS gesprochen.
<ph type="x-smartling-placeholder">
Rachel:Ich habe aufgrund Ihres Raster-Frameworks Susy zum ersten Mal von Ihrer Arbeit erfahren. Was hat Sie dazu veranlasst?
Miriam:2008 war das Layout im Web ganz anders. Die Entwickler hatten vom Tabellenlayout zu mehr semantischen (aber immer noch komplizierteren) Floating-Rastern gewechselt. Es gab einen Boom bei „One-Size-fits-all“-12-spaltigen „Raster-Frameworks“, die ein vordefiniertes (normalerweise statisches) Raster mit einer Reihe vordefinierter CSS-Klassen bereitstellten. Wenn Sie etwas stärker anpassen wollten, waren Sie auf sich allein gestellt. Es war klar, dass Websites responsiver werden mussten, aber Medienabfragen waren noch nicht verfügbar und es gab zahlreiche Browserkompatibilitätsprobleme rund um flüssige Gleitkommazahlen.
Ich verwendete Natalie Downes CSS Systems-Ansatz, bei dem sowohl die Schriftgröße als auch die Größe des Darstellungsbereichs berücksichtigt werden konnte. Aber die wiederholten Mathematik- und Browser-Hacks, die mich ständig ändern mussten, waren frustriert. Gleichzeitig erregte Sass etwas Aufmerksamkeit und es passte perfekt, was ich brauchte. Der erste Entwurf von Susy war sehr einfach: nur ein paar Mixins, um die Berechnungen durchzuführen und die erforderlichen Hacks hinzuzufügen. Das Ziel war, möglichst wenig zu tun und nur den wesentlichen Code auszugeben. Vollständig anpassbare Raster ohne vordefinierte Klassen.
Rachel:Wie sind Sie von der Arbeit an einem CSS-Präprozessor zu CSS-Spezifikationen gewechselt? War die Arbeit am Präprozessor Ihrer Meinung nach ein guter Hintergrund für das Schreiben von Spezifikationen?
Miriam:Nach meiner Erfahrung gibt es viele Überschneidungen und ich bin auf beiden Seiten dieser Spaltung immer noch sehr aktiv. Das ist vor allem dem Sass-Team zu verdanken, das von Natalie Weizenbaum geleitet wird. Sie verfolgt einen langfristigen Ansatz und versucht, Tools zu entwickeln, die sich problemlos in die Entwicklung von Webstandards integrieren lassen. „Meinung“ geht über die Einheitsgröße Lösungen zu entwickeln und auf langfristige Flexibilität zu achten, ist wichtig, wenn Sie über die Zukunft grundlegender Webstandards nachdenken.
Wie können wir Tools entwickeln, die die Vielfalt der Entwickleranforderungen und Ansätze berücksichtigen und gleichzeitig Barrierefreiheit und andere wichtige Überlegungen fördern und erleichtern?
Rachel:In CSS gibt es eine Menge Dinge, die im Wesentlichen Funktionen ersetzen, die früher Sass-Funktionen waren. Gibt es gute Gründe, weiterhin so etwas wie Sass zu verwenden?
Miriam:Ja, für manche, aber es gibt keine universelle Antwort. Nehmen wir zum Beispiel Variablen. Sass-Variablen haben einen lexikalischen Bereich und werden auf dem Server mit organisierten Datenstrukturen wie Listen und Objekten, Farbbearbeitung usw. kompiliert. Das eignet sich hervorragend für Designsystemlogik, die nicht im Browser ausgeführt werden muss.
CSS-Variablen haben einige Überschneidungen und können auch Werte speichern, bieten jedoch ganz andere kaskadenbasierte Stärken und Schwächen. Sass kann keine benutzerdefinierten Eigenschaften und CSS können keine strukturierten Daten verarbeiten. Beide sind nützlich und leistungsstark – aber Ihre spezifischen Anforderungen können variieren.
Ich denke, es ist großartig, wenn Mitarbeiter Tools eliminieren können, die sie nicht mehr benötigen, und für einige Projekte sind möglicherweise nicht sowohl server- als auch clientseitige Variablen erforderlich. Wunderbar! Es ist jedoch zu einfach, anzunehmen, dass sie identisch sind und das eine einfach das andere ersetzt. Es gibt immer Anwendungsfälle für eine Designlogik, die serverseitig und einige clientseitig erfolgt – auch wenn wir so weit sind, dass die Sprachen im Wesentlichen dieselben Funktionen bieten. Präprozessoren unterstützen wir langfristig.
Rachel:Gibt es etwas, das dich überrascht hat, da du dich stärker in die Entwicklung von Standards eingebracht hast, oder etwas, von dem die Leute im Allgemeinen nichts von diesem Prozess wissen?
Miriam:Bevor ich anfing, fühlte sich der Standardprozess wie eine mysteriöse und magische schwarze Box an und ich war nicht sicher, was mich erwartete. Ich hatte Angst, dass ich nicht genügend Browser-intern war, um einen Beitrag zu leisten, aber in Wirklichkeit brauchen sie keine weiteren Browserentwickler. Sie brauchen mehr Entwickelnde und Designer, die Websites und Anwendungen im Web erstellen.
Ich war überrascht, dass sich nur sehr wenige der Beteiligten hauptsächlich auf Standards konzentrieren, aber nur sehr wenige von ihnen in erster Linie Websites entwickeln oder entwerfen. Das W3C besteht aus „ehrenamtlichen Helfern“ von Mitgliedsorganisationen (oft von diesen Organisationen bezahlt, aber nicht als Hauptaufgabe) und die Mitgliedschaft ist nicht günstig. Das trennt die Teilnehmenden von den alltäglichen Designschaffenden und Entwickelnden, insbesondere denen von uns, die Kundenarbeiten in kleinen Agenturen oder freiberuflich tätig sind. Meine Rolle als eingeladener Experte wäre ein ehrenamtlicher Mitarbeiter, ein teures Hobby, wenn ich keine finanzielle Unterstützung für diese Arbeit gefunden hätte.
In Wirklichkeit ist der Prozess ziemlich offen und öffentlich und erfordert Beteiligung der Entwickler – aber es finden immer so viele Gespräche gleichzeitig statt, dass es schwierig sein kann, den richtigen Platz zu finden. Vor allem, wenn es nicht Ihr Hauptberuf ist.
Rachel:Containerabfragen sind für viele Webentwickler seit vielen Jahren der heilige Gral. Ich freue mich sehr, dass wir sie bekommen. Ich habe das Gefühl, dass viele Leute über den Nutzen von Containerabfragen nachdenken – haben Sie das Gefühl, dass auch sie mehr Kreativität freisetzen können?
Miriam:Absolut, auch wenn ich die nicht als völlig unabhängig betrachte. Wir alle haben begrenzte Zeit, und wir versuchen, einfach zu wartenden und leistungsfähigen Code zu schreiben. Wenn etwas praktisch nur schwer umzusetzen ist, sind wir weniger wahrscheinlich, wenn es darum geht, kreativ zu sein, was möglich ist.
Dennoch wird die Webbranche heute von großen Unternehmen dominiert, sodass diese geschäftlichen Belange immer mehr Sendezeiten erhalten als Webkünstler. Und ich denke, dass wir viel verlieren, wenn wir die Kreativität im Web als primären Anwendungsfall für Funktionen ignorieren. Es hat mich gefreut, dass einige der CSS-Arten mit dem Prototyp für Containerabfragen spielen. Jhey Tompkins entwickelte eine besonders clevere und interaktive Demo zu venetischen Jalousien im Preisvergleichsportal als Kommentar zu dem alten Anti-CSS-Meme. In diesem Bereich gibt es noch viel mehr zu entdecken, und ich kann es kaum erwarten, zu sehen, was die Leute sich noch einfallen lassen.
Im ursprünglichen Anwendungsfall standen größenbasierte Abfragen im Mittelpunkt, aber ich bin gespannt, was Nutzer mit Stilabfragen machen: die Möglichkeit, bedingte Stile zu schreiben, die auf dem Wert einer CSS-Eigenschaft oder -Variable basieren. Es ist eine äußerst leistungsstarke Funktion, die bisher kaum erforscht wurde. Ich denke, das eröffnet noch mehr kreative Möglichkeiten!
Rachel:Gibt es etwas, das wir in CSS nicht tun können (oder werden in Kürze noch etwas tun können), das Ihrer Meinung nach nützlich wäre?
Miriam:Ich freue mich schon auf andere Spezifikationen, an denen ich mich gearbeitet habe. Kaskadenebenen geben Autoren mehr Kontrolle über Spezifitätsprobleme und der Umfang sollte ein präziseres Selektor-Targeting ermöglichen. Beides sind jedoch architektonische Überlegungen auf höchster Ebene. Der Künstler in mir freut sich mehr auf Dinge wie CSS-Ein-/Aus-Schaltflächen, eine deklarative Möglichkeit zum Erstellen interaktiver Stile oder Container-Zeitachsen, die einen reibungslosen Übergang zwischen Medien- und Container-Haltpunkten ermöglichen. Das hat sehr praktische Auswirkungen auf die responsive Typografie, würde aber auch viele kreative Möglichkeiten für responsive Grafiken und Animationen eröffnen.
Rachel:Wer arbeitet gerade noch so interessant, unterhaltsam oder kreativ im Web?
Miriam:Oh, ich weiß nicht mal, wie ich das beantworten soll. Es gibt so viele kreative Arbeiten in so unterschiedlichen Bereichen. Sowohl bei der CSSWG als auch bei Open-UI werden viele spannende Standards erarbeitet, darunter auch einige Ihrer Arbeit zur Fragmentierung. Aber ich lasse mich oft am meisten von Webkünstlern inspirieren und finde heraus, wie die Menschen diese Tools in der Produktion einsetzen, und zwar auf eine Weise, die nicht direkt mit Handel verbunden ist. Menschen wie Jhey, Lynn Fisher, Yuan Chuan oder viele andere, die die Grenzen der visuellen und interaktiven Möglichkeiten von Webtechnologien erweitern. Auch Menschen, die eher geschäftsorientiert arbeiten, können viel von ihren künstlerischen Techniken lernen.
Besonders gut gefällt mir die konzeptionelle Webkunst von Menschen wie Ben Grosser, der uns immer wieder dazu bringt, unsere Erwartungen an das Web und insbesondere die sozialen Medien zu überdenken. Sieh dir zum Beispiel sein neues minus.social an.
Rachel:Informieren Sie sich unter css.oddbird.net über Miriams Arbeit in Bezug auf Preisvergleichsportale und finden Sie auf ihrer Website miriam.codes und auf Twitter @TerribleMia weitere Informationen.