Miriam Suzanne ist Autorin, Künstlerin und Webentwicklerin aus Denver, Colorado. Sie arbeitet derzeit an spannenden CSS-Spezifikationen wie Containerabfragen und Cascade Layers.
Dieser Beitrag ist Teil von Designcember. Eine Feier des Webdesigns – 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 von W3C eingeladene Expertin in der CSS Working Group. In letzter Zeit beschäftigte sie sich mit der Entwicklung neuer CSS-Funktionen wie Cascade Layers, Container Queries und Scope. Offline ist Miriam eine veröffentlichte Schriftstellerin, Dramatikerin und Musikerin. Wir haben über ihre Arbeit mit Sass und CSS gesprochen.
Rachel:Ich habe zum ersten Mal aufgrund Ihres Raster-Frameworks Susy von Ihrer Arbeit erfahren. Was hat Sie dazu bewogen?
Miriam:2008 war das Layout im Web eine ganz andere Erfahrung. Die Entwickler haben sich vom Tabellenlayout zu semantischen (aber immer noch kniffligen) unverankerten Rastern verabschiedet. Es gab einen Boom bei den „One-Size-fits-all“-12-spaltigen „Raster-Frameworks“, die ein vordefiniertes (normalerweise statisches) Raster mit einer Reihe von vordefinierten CSS-Klassen zur Verfügung stellten. Bei Bedarf waren Sie auf sich allein gestellt. Es war klar, dass Websites reaktionsschneller werden mussten, aber noch keine Medienabfragen verfügbar waren und es eine Menge Browserkompatibilitätsprobleme im Zusammenhang mit fließenden Floats gab.
Ich habe den Ansatz CSS Systems von Natalie Downe verwendet. Damit konnte ich sowohl auf Schriftgrößen als auch auf Darstellungsbereichgrößen reagieren, aber ich war frustriert von all den wiederholten Mathematik- und Browser-Hacks, die erforderlich waren. Gleichzeitig erhielt Sass zunehmend Aufmerksamkeit und er erfüllte meine Anforderungen perfekt. Der erste Entwurf von Susy war sehr simpel: Es gab nur ein paar Mixins, um die benötigten Hacks zu rechnen und hinzuzufügen. Das Ziel war, auf ein Minimum zu kommen und nur den notwendigen Code auszugeben. Raster ohne vordefinierte Klassen.
Rachel:Wie ist der Wechsel von der Arbeit an einem CSS-Präprozessor hin zu den CSS-Spezifikationen entstanden? Denken Sie, dass die Arbeit am Präprozessor ein guter Hintergrund zum Schreiben von Spezifikationen war?
Miriam:Meiner Erfahrung nach gibt es viele Überschneidungen und ich bin auf beiden Seiten dieser Spaltung sehr aktiv. Ich denke, das ist aber vor allem dem Sass-Team zu verdanken, das von Natalie Weizenbaum geleitet wird. Sie verfolgt eine sehr langfristige Perspektive und versucht, Tools zu entwickeln, die sich reibungslos in die Entwicklung von Webstandards integrieren lassen. Für die Zukunft wichtiger Webstandards ist es von entscheidender Bedeutung, über „One-Size-fits-all“-Lösungen hinauszugehen und langfristige Flexibilität zu schaffen.
Wie können wir Tools entwickeln, die die unterschiedlichen Anforderungen und Ansätze von Entwicklern berücksichtigen und gleichzeitig die Barrierefreiheit und andere wichtige Aspekte fördern und erleichtern?
Rachel:In CSS werden zahlreiche neue Funktionen eingebaut, die Funktionen ersetzen, die früher zu Sass gehörten. Gibt es gute Gründe, trotzdem etwas wie Sass zu verwenden?
Miriam:Ja, für manche, aber es gibt hier keine universelle Antwort. Nehmen wir z. B. Variablen. SASS-Variablen sind lexisch beschränkt und werden auf dem Server mit organisierten Datenstrukturen wie Listen und Objekten, Farbmanipulation usw. kompiliert. Das eignet sich hervorragend für Designsystemlogik, die nicht im Browser ausgeführt werden muss.
CSS-Variablen weisen einige Überschneidungen auf. Sie können auch Werte speichern, bieten aber ganz andere kaskadenbasierte Stärken und Schwächen. Sass kann keine benutzerdefinierten Eigenschaften verarbeiten und CSS kann keine strukturierten Daten wirklich verarbeiten. Beide sind nützlich und leistungsstark – Ihre spezifischen Anforderungen können jedoch variieren.
Ich finde es großartig, wenn Menschen Tools eliminieren können, die sie nicht mehr benötigen, und einige Projekte möglicherweise nicht sowohl server- als auch clientseitige Variablen erfordern. Wunderbar. Aber es ist zu einfach anzunehmen, dass sie identisch sind und das eine das andere ersetzt. Es wird immer Anwendungsfälle geben, in denen eine Designlogik serverseitig und einige auf Clientseite geschieht – selbst wenn wir so weit sind, dass die Programmiersprachen im Wesentlichen die gleichen Funktionen bieten. Vorverarbeitungstechnologie sind langfristig einsetzbar.
Rachel: Gibt es etwas, das Sie überrascht hat, als Sie sich stärker in die Erstellung von Standards eingebracht haben, oder etwas, von dem Sie glauben, dass es die Menschen im Allgemeinen nicht über den Prozess wissen könnte?
Miriam:Bevor wir mitmachen, war der Standardprozess eine mysteriöse und magische Blackbox und ich war mir nicht sicher, was mich erwartete. Ich hatte Angst, dass ich nicht genügend Browser-Interne-Kenntnisse habe, um einen Beitrag zu leisten, aber in Wirklichkeit sind keine weiteren Browser-Entwickler erforderlich. Sie brauchen mehr Entwickler und Designer, die weltweit Websites und Anwendungen erstellen.
Ich war überrascht, dass sich nur sehr wenige der beteiligten Personen hauptsächlich mit Standards befassen, aber auch nur sehr wenige von ihnen hauptsächlich Websites entwickeln oder entwerfen. Das W3C besteht aus "Freiwilligen" von Mitgliedsorganisationen (oft von diesen Organisationen bezahlt, aber nicht als Hauptaufgabe), und die Mitgliedschaft ist nicht günstig. Das führt dazu, dass die Teilnehmenden nicht mehr mit alltäglichen Designern und Entwickelnden zu tun haben, insbesondere von uns, die in kleinen Agenturen oder als freiberuflich tätige Kundschaft Kundenarbeit übernehmen. Meine Aufgabe als eingeladene Expertin wäre ein wirklich ehrenamtliches Hobby, ein teures Hobby, wenn ich keine externe Finanzierung für diese Arbeit gefunden hätte.
In Wirklichkeit ist der Prozess recht öffentlich und erfordert die Beteiligung der Entwickler – aber es gibt immer so viele Unterhaltungen gleichzeitig, dass es schwierig sein kann, den richtigen Ort zu finden. Vor allem, wenn es nicht Ihren Hauptjob ist.
Rachel:Containerabfragen sind für viele Webentwickler schon seit vielen Jahren der heilige Gral. Ich freue mich sehr, dass wir sie erhalten. Ich glaube, viele denken über den Nutzen von Container-Abfragen nach – haben sie das Potenzial, auch mehr Kreativität zu ermöglichen?
Miriam:Absolut, auch wenn ich diese Punkte nicht als völlig unabhängig sehe. Wir alle haben nur wenig Zeit und versuchen, gut zu wartenden und leistungsfähigen Code zu schreiben. Wenn etwas schwierig ist, um es in der Praxis umzusetzen, ist die Wahrscheinlichkeit geringer, dass wir kreativ werden mit dem, was möglich ist.
Dennoch wird die Webbranche von großen Unternehmensinteressen dominiert, sodass diese Unternehmen immer mehr Sendezeit erhalten als Webkünstler. Und ich denke, wir verlieren viel, wenn wir die Kreativität im Web als primären Anwendungsfall für Funktionen ignorieren. Ich freue mich sehr, dass einige CSS-Artwork mit dem Prototyp für Containerabfragen spielen. Jhey Tompkins entwickelte eine besonders clevere und interaktive Demo von CSS-Venetic-Jalousien als Kommentar zum alten Anti-CSS-Meme. Ich glaube, in diesem Bereich gibt es noch viel mehr zu entdecken, und ich bin gespannt, was die Leute sich sonst noch einfallen lassen.
Im ursprünglichen Anwendungsfall ging es auch um größenbasierte Abfragen, aber ich bin gespannt, was die Leute mit Stilabfragen machen – der Möglichkeit, bedingte Stile basierend auf dem Wert einer CSS-Eigenschaft oder -Variablen zu schreiben. Das ist eine äußerst leistungsstarke Funktion, die bisher kaum erforscht ist. Ich glaube, dass sich dadurch noch mehr kreative Möglichkeiten eröffnet.
Rachel:Gibt es etwas, das in CSS nicht möglich ist (oder künftig eine Möglichkeit dafür gibt), was Ihrer Meinung nach hilfreich wäre?
Miriam:Ich freue mich schon auf andere Spezifikationen, an denen ich gearbeitet habe. Kaskadierende Ebenen geben Autoren mehr Kontrolle über Spezifitätsprobleme und der Umfang sollte bei einem präziseren Auswahl-Targeting helfen. Doch beides ist ein grundlegendes architektonisches Problem. Die Künstlerin in mir begeistert sich mehr für Dinge wie CSS-Ein-/Aus-Schaltflächen, eine deklarative Möglichkeit zum Erstellen interaktiver Stile oder Container-Zeitachsen, die es uns ermöglichen, Werte zwischen Medien- oder Containerhaltepunkten reibungslos zu übergehen. Das hat sehr praktische Auswirkungen auf die responsive Typografie, würde aber auch viele kreative Möglichkeiten für responsive Kunstwerke und Animationen eröffnen.
Rachel:Wer arbeitet im Web momentan wirklich interessant, unterhaltsam oder kreativ?
Miriam:Ich weiß nicht mal, wie ich das beantworten soll. Es gibt so viele Menschen, die in so verschiedenen Bereichen kreative Arbeit leisten. Sowohl von der CSSWG als auch von Open-UI wird an zahlreichen Standards gearbeitet, einschließlich eines Teils Ihrer Arbeit zur Fragmentierung. Am meisten lass ich mich aber von Webkünstlern inspirieren und finde heraus, wie sie diese Tools auf eine Art und Weise erstellen, die nicht direkt mit dem Handel zu tun hat. Nutzer wie Jhey, Lynn Fisher oder Yuan Chuan oder viele andere, die die Grenzen der visuellen und interaktiven Möglichkeiten von Webtechnologien ausweiten Auch Menschen, die eher geschäftsorientiert arbeiten, können durch ihre künstlerischen Techniken viel lernen.
Ich schätze auch die eher konzeptionelle Webkunst von Menschen wie Ben Grosser, die uns ständig dazu bringen, über das zu überdenken, was wir vom Web und insbesondere von sozialen Medien erwarten. Sieh dir zum Beispiel sein neues minus.social an.
Rachel:Sehen Sie sich Miriams Arbeit an CSS auf css.oddbird.net an und informieren Sie sich auf ihrer Website unter miriam.codes und auf Twitter @TerribleMia über weitere Projekte.