Our road to (F-U-N)ctional CSS – Teil 1

Vor einiger Zeit kam ein Kollege auf mich zu und fragte mich: „Wie nutzt man heutzutage CSS effektiv? Bei den ganzen Begriffen wie OOCSS , SMACSS, BEM oder den Frameworks wie Bootstrap , Foundation und Material UI steigt ja niemand mehr durch.“ Über die letzten Jahre hat sich die Art, wie ich CSS schreibe, sehr stark von einer semantischen Vorgehensweise in eine funktionale gewandelt. Einige haben den Begriff „Functional CSS“ schon gehört oder eher vom Prinzip der funktionalen Programmierung. Stylesheets auf diese Art zu entwickeln hat schon für einige spannende Reaktionen in der Entwickler-Community gesorgt. Damit der gewählte Weg für euch besser nachvollziehbar ist, möchte ich euch anhand des Gelernten erklären, warum es aus heutiger Sicht die effektivere Variante ist mit CSS loszulegen.

Altbekanntes, semantisches CSS

Viele von euch können mit dem Begriff „Separation of concerns “ etwas anfangen. Die Idee dahinter ist es, dass euer HTML nur Informationen über eure Inhalte haben sollte und das Styling im CSS stattfindet. Hier ein kleines Beispiel:

Hier sieht man die CSS-Klasse .text-left und richtig erkannt, diese Schreibweise verletzt unsere „Separation of concerns“, da wir im HTML sagen, wie der Textblock auszusehen hat. Die präferierte Schreibweise werde ich euch nicht vorenthalten, und wir werden einen generischen, auf den Inhalt des Elements angepassten, CSS-Klassennamen wählen:

Die Quintessenz dahinter wurde im CSS Zen Garden (Oldschool) beschrieben, denn diese Denkweise sollte es ermöglichen, eine Seite komplett neu zu gestalten, indem man einfach die Stylesheet-Datei austauscht. Also sah mein Workflow nach bestem Wissen damals so aus:

1. Markup für eine UI-Komponente runterhacken (hier: eine Profile Card):

2. Content-spezifische CSS-Klassennamen vergeben:

3. Klassennamen als „HOOK“ (greetings to react ?) im CSS/LESS/SASS verwenden und das Element anpinseln:

Und hier ist das Resultat:

See the Pen
Profile card, nested selectors by Toni Haupt (@sourcewars)
on CodePen.

Dieser Ansatz ergab für lange Zeit Sinn, aber mit der Zeit und den wachsenden Anforderungen bei neuen Projekten, fühlte sich diese Schreibweise irgendwie komisch an. „Your code smells“ tauchte immer wieder in meinen Gedanken auf, denn die Entkopplung zwischen HTML und CSS war für mich nicht das Gelbe vom Ei. In den meisten Fällen war das CSS ein Spiegel für das HTML-Markup, oder präziser formuliert: eine Kopie der HTML-Struktur in Form von verschachtelten CSS-Selektoren.

Zukunftssicher – Styles von der HTML-Struktur trennen

Die Suche ging weiter, und so bin ich auf die BEM-Methodologie (Block Element Modifier) gestoßen. Der riesengroße Vorteil ist hierbei, dass wir die Spezifität aushebeln können und somit eine Möglichkeit haben, weniger Abhängigkeiten zwischen unserem CSS und unserer HTML-Struktur zu erreichen. Wenden wir diesen Ansatz einmal auf unsere Profile Card an:

…und das angepasste CSS schaut so aus:

Eine deutliche Verbesserung, da mein HTML-Markup semantisch war und keine Beschreibung von Styles enthielt, mit dem Bonus unnötige Selektoren zu vermeiden und die Spezifität aufzubrechen. Aber mit wachsenden Projekten und Anforderungen an neue Komponenten ergaben sich neue Probleme.

WTF?! Ähnliche Komponenten!

Die Idee reifte weiter, und wir brauchten ein neues Feature: die Vorschau eines Artikels in einem Kartenlayout. Diese Komponente hat ein Artikelbild, einen Inhaltscontainer mit Whitespace, bestehend aus einem gefettetem Titel und einem Anlesertext mit kleiner Schriftgröße. Ganz genau: Diese Artikelkarte sieht aus wie unsere Profilkarte. Doch wie gehen wir jetzt vor, damit wir unserem Ansatz „separation of concerns“ treu bleiben?
Unsere CSS-Klasse .profile-card können wir der Artikelvorschau nicht zuweisen; das würde der Semantik widersprechen. Also erstellen wir eine eigene Komponente mit der Klasse .article-teaser, und so wird das HTML-Markup aussehen:

Jetzt kommt die Stunde der Wahrheit, und wir müssen uns überlegen, was mit unserem CSS passieren soll.

Option 1: Styles kopieren

Wir schnappen uns die Styles unserer profile-card und benennen einfach die Klassen um:

Looking for DRY (Don’t Repeat Yourself)! Es könnte so einfach sein, oder? Doch wir laufen hier schnell in die Falle, dass unser Design inkonsistent wird, da wir relativ einfach das Padding, die Schriftfarbe und andere Eigenschaften verändern können.

Option 2: @extend nutzen

Eine elegantere Lösung wäre die @extend-Methode eines Pre-processors eurer Wahl und die Styles in unser .profile-card zu nutzen.

Fühlt sich so an, als hätten wir unser Problem damit umgangen und unsere Styles wiederverwendet. Doch @extend wird generell nicht als bevorzugte Lösung angepriesen.
Wir haben den duplicate code in unserem CSS entfernt, und das HTML-Markup ist weiterhin semantisch korrekt. Aber es gibt noch eine weitere Option, die Erstellung generischer Komponenten.

Option 3: Erstellung einer generischen Komponente

Unsere .profile-card und der .article-teaser haben aus semantischer Perspektive nichts miteinander zu tun. Betrachten wir es aber aus der Designperspektive haben die beiden doch sehr viele Gemeinsamkeiten. Also gehen wir einen neuen Weg, benennen die Komponente etwas allgemeiner nach ihrer Funktionsweise und verwenden diese für unsere .profile-card und den .article-teaser. So entsteht als Komponente .media-card, und das Ganze sieht im CSS so aus:

Das HTML-Markup muss natürlich für beide angepasst werden. Hier das Beispiel anhand der .profile-card:

Ihr als Profis werdet mir jetzt natürlich sofort an den Kopf werfen „Du vermischst jetzt aber die concerns der beiden!“ Unser HTML-Markup weiß jetzt, dass beide Komponenten aussehen sollen wie eine .media-card. Doch was passiert, wenn die .profile-card ein anderes Layout als der .article-teaser bekommen soll? Vorher konnten wir einfach die entsprechenden Styles in unserer CSS-Datei bearbeiten, doch jetzt müssen wir das HTML-Markup verändern. Blasphemie!!! Doch nicht so voreilig, und lasst uns einmal die Sonnenseite dieses Ansatzes betrachten:

Wie stylen wir ein neues Inhaltselement, das genauso aussehen soll wie unsere vorherigen Komponenten?

Wählen wir den semantischen Ansatz, schreiben wir uns neues HTML-Markup, packen wieder unsere Content-spezifischen CSS-Klassen als Stylinghooks drauf, erstellen ein neues Stylesheet für die Komponente und wenden unsere Shared Styles mit @extend oder als mixin an. Nutzen wir jedoch unseren generischen Ansatz der .media-card, schreiben wir nur das HTML-Markup für die neue Komponente. Wenn hier wirklich eine Vermischung unserer concerns stattfindet, müssten wir doch nicht an verschiedenen Stellen Änderungen vornehmen?

„Separation of concerns“ dient nur als Strohmann

Betrachten wir die Beziehungen zwischen HTML und CSS, gibt’s hier nur schwarz oder weiß, denn entweder haben wir eine „separation of concerns“ (schwarz) oder halt nicht (weiß). Doch diese Denkweise ist so nicht richtig, und wir sollten eher in Richtung der Abhängigkeiten zwischen HTML und CSS nachdenken.

1. „Separation of concerns“ oder besser gesagt CSS, welches vom HTML-Markup abhängig ist:

• Benennen wir unsere CSS-Klassen basierenden auf dem Inhalt (z. B. .profile-card) ist unser HTML die Dependency für das CSS. Das HTML-Markup ist jedoch unabhängig, da es lediglich unseren Stylinghook in Form der .profile-card zur Verfügung stellt.
• Das CSS-Styling ist aber abhängig von dem bereitgestellten HTML-Markup und muss diese Elemente zielgerichtet ansprechen.

In diesem Szenario kann das HTML ein neues Aussehen erhalten, das CSS ist jedoch nicht wiederverwendbar.

2. „Mixing concerns“ und das HTML hängt am CSS-Tropf:

• Nutzen wir unseren generischen Ansatz als wiederholendes Pattern in unserem User Interface (z. B. .media-card), ist unser CSS eine Abhängigkeit für das HTML-Markup. Das Styling aber ist komplett unabhängig und interessiert sich nicht dafür, auf welchen Inhalt es angewendet wird. Es stellt nur Bausteine zur Verfügung, die wir auf unser HTML-Markup anwenden können. Umgekehrt ist das HTML abhängig von CSS-Klassen und muss darüber informiert werden, welche Klassen existieren und wie diese zusammengesetzt werden, damit das visuelle Ergebnis erreicht wird. In diesem Fall ist unser CSS wiederverwendbar, kann aber nicht einfach umgestylt werden.

Der CSS Zen Garden nutzt den ersten Ansatz, während bekannte UI-Frameworks wie Bootstrap, Foundation oder Material UI den zweiten Weg wählen. Beide Vorgehensweisen sind nicht falsch, vielmehr kommt es auf euren Anwendungsfall an:Womit verschafft ihr euch die größten Vorteile innerhalb des Projektes? – Die Möglichkeit eure Komponenten jederzeit umgestalten zu können oder wiederverwendbares CSS?

Pokemonstyle: Ich wähle dich, Reusability!

Auf Basis meiner gesammelten Projekterfahrungen, Fehlschlägen und erfolgreichen Umsetzungen habe ich den Weg der Wiederverwendbarkeit auf CSS-Ebene gewählt. 

Die Reise geht weiter: inhaltsunabhängige CSS-Komponenten

Mein explizites Ziel war es, CSS-Klassen zu vermeiden, die stark am Inhalt der Elemente ausgerichtet sind und vielmehr wiederverwendbare Namen zu etablieren. Die Resultate enthalte ich euch nicht vor, und so sind zum Beispiel folgende CSS-Klassen entstanden:

• .card
• .btn, .btn–primary, .btn–secondary (look at the Modifier — from BEM)
• .badge
• .card-list, .card-list-item
• .img, .img–round
• .modal-form, .modal-form-section …

Die Learnings daraus haben mir auch aufgezeigt: „Je mehr Funktionalität eine Komponente besitzt, umso schlechter sieht es mit der Wiederverwendbarkeit aus!“. Ich möchte dies an einem praktischen Beispiel für euch anschaulicher machen. Wir entwickeln ein Formular mit ein paar Bereichen/Sections und einem Submit-Button. Betrachten wir alle Elemente als Teil unseres .grouped-form, können wir dem Submit-Button die Klasse .grouped-form__button mitgeben:

Jetzt kommt ein neuer Button hinzu, dieser befindet sich jedoch ausserhalb unseres Formulars, also macht es keinen Sinn die Klasse .grouped-form__button zu nutzen. Doch was uns auffällt, ist, dass beide Buttons primäre Funktionen in der Anwendung auslösen können. Also lösen wir uns von der Form und benennen unsere Klasse in .btn .btn–primary um.

Aufgabe gelöst, jetzt soll das Formular aber das Aussehen einer Card bekommen. Wir könnten jetzt einfach einen Modifier .grouped-form .grouped-form–card nutzen, aber wir haben bereits eine .card definiert. Also wrappen wir ein div mit der Klasse .card um unser Formular .

Jetzt haben wir den charmanten Vorteil, dass unsere .card ein Container für verschiedene Inhalte sein kann, aber auch, dass unser .grouped-form in jedem beliebigen Container genutzt werden kann. Der größte Vorteil ist jedoch die Wiederverwendbarkeit, denn wir müssen keine einzige Zeile neues CSS schreiben.

Komponenten erweitern

Wir kennen das aus dem Alltag und unseren Kundenanforderungen: Wir brauchen einen neuen Button im Formular, und dieser soll etwas mehr Abstand zu den vorherigen Buttons haben.

Wir können eine neue Subkomponente .grouped-form__footer einführen und den Buttons .grouped-form__footer-item als CSS-Klasse mitgeben.

Und das passende CSS dazu:

Abstände sind ein bekanntes Problem und können natürlich noch an anderen Stellen auftreten. Nehmen wir einmal die Komponente eines .header oder einer .subnavigation hinzu. Wir können die .grouped-form–footer-Klasse außerhalb des .grouped-form nicht verwenden. Das Problem können wir mit einer neuen Subkomponente lösen:

Puuuuuh… hier stinkt der Code, der uns gleich bevorsteht, schon wieder. Denn jetzt würden wir den Code aus unserem .grouped-form__footer in unsere neue .header-bar__actions-Komponente packen. Das fühlt sich genauso an wie im Beispiel der inhaltsabhängigen CSS-Klassen. Zur Lösung des Problems können wir eine neue, generische Komponente erstellen. Wir nennen diese einfach .actions-list:

Nachdem wir unsere neue CSS-Komponente haben, können wir uns wieder dem Formular/Header widmen und unsere neuen CSS-Klassen anwenden:

Weil mir dieses Spielchen einfach so viel Spaß macht, aber es schon viele Pixelschubser (ja ich bin selber einer ?‍? ) in den Wahnsinn getrieben hat, kommt jetzt noch die Anforderung, dass eines der .actions-list-Elemente links und das andere rechts ausgerichtet werden dürfen.
Soll ich jetzt einen Modifier nutzen und .actions-list–left bzw. wahlweise .actions-list–right verwenden?

Inhaltsunabhängige Komponenten und Utility-Klassen

Das Ausdenken dieser tollen Namen ist, kurz und knapp, anstrengend und zeitraubend. Wir erstellen einen neuen Modifier .actions-list–left, und es wird nur eine CSS-Eigenschaft angewendet. Was wäre, wenn wir weitere Komponenten hätten, die auch links oder rechts ausgerichtet werden müssen? Erstellen wir jetzt wieder neue Komponenten und Modifier für diese Sonderfälle?

Alignment Utilities ?

Mein Ziel ist es weiterhin, wiederverwendbare Klassen zu haben, mit denen ich flexibel auf diese Szenarien reagieren kann. Also extrahiere ich .actions-list–left/–right in die Utility-Klassen .align-left und .align-right:

Jetzt kann ich wieder ganz bequem auf das Composition Pattern zurückgreifen und es auf mein .grouped-form und den .header anwenden:

Viele von euch werden sich beim Anblick dieser Convention nicht wohl fühlen, schließlich haben wir uns doch seit Jahren vorgenommen, unsere UI-Komponenten mit aussagekräftigen Namen auszustatten. Man sollte sich jetzt auch nicht selber täuschen und denken, dass .grouped-form eine bessere Semantik als .align-right besitzt. Denn beide sind so benannt, dass sie uns klar zu verstehen geben, wie sie Markup und die entsprechende Darstellung beeinflussen. Ganz genau: Wir schreiben HTML, das an das CSS gebunden ist. Wenn wir zum Beispiel unser .grouped-form in ein .horizontal-form umwandeln wollen, tun wir dies im HTML-Markup.

Unnötigen Ballast über Bord werfen

Jetzt wird es spannend, und Folgendes sorgt vielleicht für einen weiteren Light-Bulb Moment. Denn unsere .actions-list ist komplett unnötig geworden, und wir können diese entfernen, da wir die Ausrichtung mit unseren Utility-Klassen regeln. Also weg damit:

Was mich an dieser Stelle stutzig machte, ist die Tatsache, dass ich nun .actions-list__item ohne eine .actions-list habe. Wenn wir noch einmal im Artikel zurückspringen, war unsere Anforderung, dass wir etwas mehr Abstand zwischen den Buttons haben. Unsere .actions-list war also eine gute generische Lösung, aber im Laufe der Entwicklung stellen wir fest, dass wir diese Abstände auch an anderen Stellen, die nicht zu einer .actions-list gehören, benötigen werden. Vielleicht sollten wir eine neue CSS-Komponente .spaced-horizontal-list (Namensfindung kann echt anstrengend sein) kreieren, jedoch sind es ja nur die Child-Elemente, die diese spezifischen Styles benötigen.

Spacer Utilities

Vielleicht sollten wir nur die Child-Elemente stylen und können dafür eine Klasse erfinden wie zum Beispiel „Dieses Element sollte etwas Abstand zum anderen haben“. Wir haben bereits mit den Utility-Klassen .align-left/-right gearbeitet, und das Ganze wenden wir jetzt einmal auf unser Problem mit den Abständen an. Also schreiben wir uns eine neue Utility-Klasse .mar-r-sm, die uns etwas Margin nach rechts verschafft:

Das Ganze müssen wir natürlich auch in unserem Formular und Header anwenden:

Das Konzept der .actions-list ist hinfällig, unser CSS-Code wird reduziert, und unsere Klassen sind sehr gut wiederverwendbar.

Und dann machte es Klick – Utility-Klassen sind genial

Nachdem ich die Vorteile dieser Herangehensweise erkannt habe, entstanden im Handumdrehen diverse Klassen für kleine visuelle Optimierungen und Anpassungen:

• Schriftgrößen, Farben und Schriftstärken
• Positionierungen, Rahmeneigenschaften, Schatten…
• Hintergrundfarben und Farbverläufe
• kleine Helferlein für Flexbox und CSS-Grid
• Alltagshilfen für Paddings und Margins

Das Geniale daran ist, dass wir komplette UI-Komponenten entwickeln können, ohne eine einzige Zeile CSS zu schreiben. Hier ist mal ein kleines Beispiel einer Produktkarte aus dem E-Commerce-Bereich:

See the Pen
E-commerce card by Toni Haupt (@sourcewars)
on CodePen.

Ich hoffe, das schreckt euch jetzt nicht ab, und ihr denkt jetzt, wer soll das denn noch lesen können. Doch versuchen wir das Ganze doch einmal als CSS-Klassen zu benennen, dann könnte sowas lustiges herauskommen wie .image-card-with-a-full-width-section-and-a-split-section-below… .

Ich finde das einfach zu viel Overhead, und ich möchte in der Lage sein, aus kleinen Stücken Komponenten zusammenzusetzen. Ich möchte auf das Beispiel unserer .profile-card zurückkommen: Vielleicht haben wir Karten, die einen Schatten besitzen sollen, also erstelle ich jetzt wieder einen Modifier explizit für diesen einen Kartentyp .profile-card–shadow. – Oder kann ich nicht einfach eine .shadow-Utility-Klasse erstellen und diese meinem Markup hinzufügen? Klingt für mich schlüssig und macht die ganze Sache wiederverwendbar. Einige Karten sollen keine runden Ecken haben, doch unsere .profile-card schon, und so können wir uns ebenfalls dafür einen Utility-Klasse .rounded erstellen.Wenn wir diesen Weg mit dem Fokus auf Reusability weiter folgen, entstehen viele nützliche Utilities zum Erstellen von Komponenten.

Konsistenz im CSS

Für Entwickler sehe ich hier einen großen Vorteil. Durch unsere Utility-Klassen haben wir ein vordefiniertes Set an Optionen. Wie oft wart ihr schon in der Situation „Oh, dieser Text könnte etwas heller sein“, und habt dann auf die Funktion lighten() (SCSS) auf eurer $text-color (-Variablen) zurückgegriffen? Oder der Text könnte etwas größer sein, und ihr habt dann der Komponente eine neue font-size: 1.2em zugewiesen. Im ersten Moment fühlt es sich okay an. Schließlich haben wir ja die Variable $text-color genutzt oder eine relative font-size, statt willkürlicher Werte.

Spielen wir das Ganze einmal weiter, und ihr hellt die Textfarbe um 15 Prozent auf. Ein anderer Entwickler möchte in seiner Komponente die Farbe nur um 10 Prozent aufhellen. Bevor ihr euch umschauen könnt, habt ihr eine Vielzahl neuer Textfarben in eurem Stylesheet. Das passiert im Regelfall in sehr vielen Projekten, in denen neues CSS geschrieben wird. Hier sind mal ein paar Beispiele großer bekannter Seiten:

• Github 157 unique colors, 143 background colors, 56 font sizes
• Apple 26 unique colors, 31 background colors, 45 font sizes
• Twitter 36 unique colors, 50 background colors, 46 font sizes
• Medium 79 unique colors, 59 background colors, 61 font sizes
• Facebook 83 unique colors, 110 background colors, 35 font sizes
• New York Times 25 unique colors, 16 background colors, 38 font sizes
• Google 40 unique colors, 52 background colors, 26 font sizes
• Bild.de 31 unique colors, 62 background colors, 85 font sizes

Um mehr Konsistenz im CSS zu bewahren, kann man auf Variablen oder Mixins zurückgreifen. Aber jede neue Zeile CSS kann die Komplexität erhöhen. Denkt immer daran: Mehr CSS bedeutet nicht, dass eure Styles einfacher zu verstehen sind. Nutzen wir aber bereits vorhandene Klassen, können wir dieses Problem umgehen. Ihr wollt euren Text visuell in den Hintergrund treten lassen, dann können wir exemplarisch auf einen CSS-Klasse .text-dark-soft zurückgreifen. Wollt ihr den Text etwas kleiner machen, nutzt doch einfach die bereits vorhanden Klasse .text-sm. Wenn wir als kreative Köpfe auf eine kuratierte Liste von vordefinierten Klassen Zugriff haben, verhindern wir ein lineares Wachstum unseres CSS, und Konsistenz gibt’s obendrein Gratis dazu.

Utility CSS und B-E-M

Ich bin ein großer Fan der B-E-M-Methode und greife nicht nur auf Utitlity-Klassen zurück. Wenn wir uns einmal Tachyons anschauen, sieht man, dass ein Button aus vielen Klassen bestehen kann:

Verwirrend, aber die Erläuterung kommt sofort:

• f6: sechste Größe in unserer Schriftskala
• br3: dritten border-radius nutzen (.5rem)
• ph3: dritte Größe in unserer horizontalen Paddingskala nutzen (1rem)
• pv2: zweite Größer in unserer vertikalen Paddingskala nutzen (.5rem)
• white: weiße Textfarbe
• bg-purple: Hintergrundfarbe purple
• hover-bg-light-purple: bei hover bekommt der Button ein helleres purple als Hintergrundfarbe

Eine sehr nette Implementierung für diesen Button können wir mit dem Abstraction Pattern erreichen. Bedeutet kurz und knapp, dass wir unsere Komponente nach B-E-M benennen und die Utility-Klassen in diese neue Komponente auslagern. Hier als Beispiel mit LESS (hier könnt hier vorhanden Klassen als Mixins nutzen):

Achtung: Wollt ihr SASS/SCSS oder Stylus nutzen, müsst ihr euch separate Mixins bauen. Ich zeige euch aber im zweiten Teil des Tutorials eine elegantere Lösung mit Tailwind und der @apply-Funktion.

Mit diesem Vorgehen können wir auch unnötige Abstraktionen vermeiden. Beim Component-first-Ansatz versucht man alles abstrakt darzustellen, doch es gibt diverse Elemente, die wir nur einmal benötigen. Nehmen wir einen klassischen Header-Bereich den wir im Normalfall einmal definieren, und dieser zieht sich wie ein roter Faden durch unsere Anwendung. Wenn wir auf Template Engines zurückgreifen, definieren wir diesen Bereich meistens in einem Masterlayout, und mit dem Utility-Ansatz können wir diesen Code so strukturieren:

Ich würde diesen Bereich nur noch dann extrahieren, wenn ich auf unnötig wiederkehrende Erscheinungen dieses Elements stoßen würde.

Sind doch nur Inline-Styles oder?

Den Zahn muss ich euch leider ziehen, denn bei Inline-Styles gebt ihr feste Werte mit in den Code, wie zum Beispiel: font-size: 12px, ein anderes Element kann dann im Style-Tag font-size: 16px stehen haben, oder font-size: .5em und so weiter. – Ich denke, ihr erkennt das Problem. Utility-Klassen hingegen geben euch eine engere Auswahl, und so könnt ihr nur auf eine bestimmte Auswahl zurückgreifen. Nehme ich jetzt .text-sm oder .text-xs (small oder extra-small), .pv-2 oder .pv-5 (padding-vertikal), .text-dark oder .text-light?

Mit dem Utility-first-Ansatz konnte ich konsistente Layouts entwickeln und meine Produktivität beim Schreiben neuer Komponenten stieg drastisch an.

Damit ich euch aber nicht im Regen stehen lasse, folgt in Kürze ein praktisches Beispiel. Hier werden wir mit Tailwind ein Login-Formular entwickeln. Lasst mir gerne Fragen oder Anregungen in den Kommentaren da. Danke für’s Lesen und bis bald.