CSS Houdini ist vielleicht die aufregendste Entwicklung in CSS. Houdini besteht aus einer Reihe von separaten APIs, die jeweils separat in Browsern ausgeliefert werden, und einige davon wurden bereits ausgeliefert (hier ist die Browserunterstützung). Die Paint API ist eine davon. Ich bin sehr gespannt darauf und habe kürzlich angefangen darüber nachzudenken, wie ich sie in meiner Arbeit einsetzen kann.
Eine Möglichkeit, dies zu tun, ist die Vermeidung der Neuerfindung des Rads. Dies werden wir in diesem Beitrag besprechen, indem wir es mit Methoden vergleichen, die wir derzeit in JavaScript und CSS verwenden. (Ich werde nicht auf die Frage eingehen, wie man CSS Houdini schreibt, da es großartige Artikel wie diesen, diesen und diesen gibt.)
Houdini bringt Modularität und Konfigurationen in CSS
Die Funktionsweise von CSS Houdini bringt zwei Vorteile: **Modularität** und **Konfigurierbarkeit**. Beides sind gängige Methoden, um unser Leben als Entwickler zu erleichtern. Wir sehen diese Konzepte oft in der JavaScript-Welt, aber weniger in der CSS-Welt... bis jetzt.
Hier ist eine Tabelle, die die Arbeitsabläufe für einige Anwendungsfälle vergleicht, wobei traditionelles CSS mit der Verwendung von Houdini verglichen wird. Ich habe auch JavaScript für weitere Vergleiche hinzugefügt. Sie können sehen, dass CSS Houdini es uns ermöglicht, CSS produktiver zu nutzen, ähnlich wie sich die JavaScript-Welt zu Komponenten entwickelt hat.
| Traditionelles CSS | CSS Houdini | JavaScript | |
|---|---|---|---|
| Wenn wir häufig verwendete Snippets benötigen | Schreibe es von Grund auf neu oder kopiere es von irgendwoher. | Importiere ein Worklet dafür. | Importiere eine JS-Bibliothek. |
| Passe das Snippet für den Anwendungsfall an | Manuell den Wert in CSS ändern. | Bearbeite benutzerdefinierte Eigenschaften, die das Worklet verfügbar macht. | Bearbeite Konfigurationen, die die Bibliothek bereitstellt. |
| Code teilen | Teile den Code für die Rohstile mit Kommentaren, wie jeder Teil geändert werden kann. | Teile das Worklet (in Zukunft, mit einem Paketverwaltungsdienst) und dokumentiere benutzerdefinierte Eigenschaften. | Teile die Bibliothek mit einem Paketverwaltungsdienst (wie npm) und dokumentiere, wie sie verwendet und konfiguriert wird. |
Modularität
Mit Houdini kannst du ein Worklet importieren und es mit einer einzigen Codezeile verwenden.
<script>
CSS.paintWorklet.addModule('my-useful-paint-worklet.js');
</script>
Das bedeutet, dass es nicht notwendig ist, häufig verwendete Stile jedes Mal neu zu implementieren. Du kannst eine Sammlung deiner eigenen Worklets haben, die in jedem deiner Projekte verwendet oder sogar untereinander geteilt werden können.
Wenn du nach Modularität für HTML und JavaScript zusätzlich zu Stilen suchst, dann sind Web Components die Lösung.
Das ist sehr ähnlich zu dem, was wir bereits in der JavaScript-Welt haben. Die meisten Leute werden keine häufig verwendeten Funktionen neu implementieren, wie z.B. Throttling oder Deep-Copying von Objekten. Wir importieren einfach Bibliotheken wie Lodash.
Ich kann mir vorstellen, dass wir CSS Houdini Paketverwaltungsdienste haben könnten, wenn die Popularität von CSS Houdini zunimmt, und jeder Worklets für interessante Wasserfall-Layouts, Hintergrundmuster, komplexe Animationen usw. importieren könnte.
Konfigurierbarkeit
Houdini funktioniert gut mit CSS-Variablen, die sich weitgehend selbst befähigen. Mit CSS-Variablen kann ein Houdini-Worklet vom Benutzer konfiguriert werden.
.my-element {
background-image: paint(triangle);
--direction: top;
--size: 20px;
}
Im Snippet sind --direction und --size CSS-Variablen, und sie werden im triangle Worklet verwendet (definiert vom Autor des triangle Worklets). Der Benutzer kann die Eigenschaft ändern, um zu aktualisieren, wie es angezeigt wird, sogar dynamisch durch das Aktualisieren von CSS-Variablen in JavaScript.
Wenn wir es wieder mit dem vergleichen, was wir bereits in JavaScript haben, haben JavaScript-Bibliotheken normalerweise Optionen, die übergeben werden können. Zum Beispiel können wir Werte für Geschwindigkeit, Richtung, Größe usw. an eine Carousel-Bibliothek übergeben, damit sie so funktioniert, wie wir es wünschen. Das Anbieten dieser APIs auf Elementebene in CSS ist sehr nützlich.
Ein Houdini-Workflow macht meinen Entwicklungsprozess viel effizienter
Sehen wir uns ein vollständiges Beispiel dafür an, wie all dies zusammenwirken kann, um die Entwicklung zu erleichtern. Wir verwenden ein **Tooltip**-Designmuster als Beispiel. Ich stelle fest, dass ich dieses Muster oft auf verschiedenen Websites verwende, und implementiere es doch jedes Mal für jedes neue Projekt neu.
Lassen Sie uns kurz meine frühere Erfahrung durchgehen
- Okay, ich brauche ein Tooltip.
- Es ist eine Box mit einem Dreieck an einer Seite. Ich werde ein Pseudo-Element verwenden, um das Dreieck zu zeichnen.
- Ich kann den Trick mit dem transparenten Rand verwenden, um das Dreieck zu zeichnen.
- Zu diesem Zeitpunkt wühle ich höchstwahrscheinlich in meinen vergangenen Projekten, um den Code zu kopieren. Lassen Sie mich nachdenken... dieses muss nach oben zeigen, welche Seite ist transparent?
- Oh, das Design erfordert einen Rand für das Tooltip. Ich muss ein weiteres Pseudo-Element verwenden und einen Rand für das zeigende Dreieck vortäuschen.
- Was? Sie haben beschlossen, die Richtung des Dreiecks zu ändern?! OK, OK. Ich werde alle Werte beider Dreiecke anpassen...
Das ist keine Raketenwissenschaft. Der gesamte Prozess kann nur fünf Minuten dauern. Aber sehen wir, wie es mit Houdini besser sein kann.
Ich habe ein einfaches Worklet erstellt, um ein Tooltip zu zeichnen, mit vielen Optionen, um sein Aussehen zu ändern. Sie können es auf GitHub herunterladen.
Hier ist mein neuer Prozess, dank Houdini
- Okay, ich brauche ein Tooltip.
- Ich werde dieses Tooltip-Worklet importieren und verwenden.
- Jetzt werde ich es mit benutzerdefinierten Eigenschaften modifizieren.
<script>CSS.paintWorklet.addModule('my-tooltip-worklet.js')</script>
<style>
.tooltip-1 {
background-image: paint(tooltip);
padding: calc(var(--triangle-size) * 1px + .5em) 1em 1em;
--round-radius: 0;
--background-color: #4d7990;
--triangle-size: 20;
--position: 20;
--direction: top;
--border-color: #333;
--border-width: 2;
color: #fff;
}
</style>
Hier ist eine Demo! Spielen Sie mit den Variablen herum!
CSS Houdini öffnet eine Tür für die gemeinsame Nutzung von modularisierten, konfigurierbaren Stilen. Ich freue mich darauf, dass Entwickler CSS Houdini Worklets verwenden und teilen werden. Ich versuche, weitere nützliche Beispiele für die Verwendung von Houdini hinzuzufügen. Ping mich, wenn Sie Ideen haben oder zu diesem Repository beitragen möchten.
Es ist schade, dass dieser Artikel Sass und SCSS vollständig ignoriert. Ich bin noch auf keine Situation gestoßen, in der eine Kombination aus SCSS und CSS-Custom-Properties keinen sauberen und offensichtlichen Workflow erzeugen kann.
Styled-Components bietet die gleiche Lösung, plus es ist in Frontend-Frameworks integriert.
Jedes im Artikel erwähnte Positive ist mit Styled-Components möglich.
Es ist die Zukunft von CSS.
Toller Artikel!
Wie kann etwas, das an ein JavaScript-Framework gebunden ist, „die Zukunft von CSS“ sein?
Bingo.
Lazar, das war genau mein Gedanke, als ich diesen Artikel gelesen habe. Ich sehe keinen Vorteil darin, die Variablen eines Moduls über Skripte ändern zu können.
Aus dem Tooltip-Beispiel verwischt dies gefährlich die Trennung der Zuständigkeiten
Teams müssen dann an mehreren Stellen nachsehen, welche visuellen Stile überschrieben werden – und das ist einfach falsch
Kann mit OOCSS und Modifier/Variant-Klassen gehandhabt werden
Wenn Spezifität oder Regelgewicht ein Problem sind, verwenden Sie das invertierte ITCSS-Dreieck, das von Harry Roberts populär gemacht wurde.
Wenn Sie sich Sorgen machen, Variationen im Voraus in OOCSS zu schreiben, übernehmen Sie atomare Praktiken.
Was er sagt – jeder liebt seine Präprozessoren
Letztendlich sind Methodologien + Best Practices > Tools, die ein paar Typen bei HP, Microsoft und Google für notwendig halten.
Großartig
Ich befürchte, dass das „modularisierte“ CSS-Problem bereits behoben ist, ohne (teilweise) nicht unterstütztes JavaScript auf dem Client. CSS Houdini ist sicherlich aufregend und vielversprechend, aber das „Modularitäts“-Problem ist bereits mit Klassen und einem Build-System gelöst.
Warum nicht stattdessen Styled-Components verwenden?
Weil es an React gebunden ist.
Bezüglich der Anpassung des Worklets, sind die benutzerdefinierten Variablen normale CSS-Variablen, richtig?
Sie konfigurieren also Ihr Worklet über globale Variablen, ohne Scoping oder Ähnliches, um zu verhindern, dass Ihre Worklet-Anpassung mit CSS-Variablen kollidiert, die an anderer Stelle in Ihrem CSS verwendet werden?
Es ist viel besser als das, was wir jetzt haben, aber als Programmierer erscheint es... umständlich?
Das ganze Modularisierungsding ist ein roter Hering, es sei denn, Ihnen ist egal, wie Ihre Website aussieht... Ihr Kunde wird es definitiv tun.
Diese Art von Dingen ist nur für Component-Bibliotheken nützlich, die versuchen, ihre hart zu überschreibenden, eifrigen !important-Nutzungen zu pushen.
Wo bleibt die Berücksichtigung der Erstellung von Single-Level-Selector-Regeln... Die Berücksichtigung der Wartung großer Designsysteme über Projekte hinweg...
Ich werde unpopulär sein, aber BEM ist das Beste, was CSS passiert ist. Je näher Sie Ihre Stile an Vanilla CSS halten können, desto besser.
Wenn dies aus einer .js-Datei geladen werden muss, wird es nach dem Rendern der Seite geladen? Gibt es ein Flackern und dann malt CSS Houdini neu?
Ich habe eine gründlichere Erklärung gefunden, wie Houdini funktionieren wird. Abgesehen vom Erstellen von benutzerdefinierten Dreiecken in CSS gibt es darin noch viel mehr Spaß!
https://tsh.io/blog/css-houdini-future-frontend-development/
Keine Erwähnung der Tatsache, dass man dies noch Ewigkeiten nicht verwenden kann, da man jahrelang auf die Fallback-Implementierung zurückgreifen muss. Ein Fallback, der genauso viel Zeit kostet wie die von Ihnen beschriebene „traditionelle“ Methode, also keine Zeitersparnis. Und zu diesem Zeitpunkt, warum Houdini überhaupt verwenden, wenn der Fallback in allen Browsern funktioniert?
Derzeit sehe ich die Stärke von Houdini nicht in den beschriebenen Vorteilen. Der Vorteil, den ich sehe, ist, dass es Paint-Algorithmen ermöglicht, die derzeit mit CSS einfach nicht möglich sind. Das ist ein Szenario, das man progressiv verbessern kann. Zum Beispiel ein abgerundeter Button, aber in den allerneuesten Browsern ein Button mit einer seltsamen organischen Form.
In den kommenden Jahren halte ich es für eine schlechte Idee, Dinge zu implementieren, die man jetzt in CSS tun kann, um sie stattdessen in Houdini zu tun. Das ergibt keinen Sinn.