CSS Klassennamen Schreibweise

[dedlfix]

Tach!

Und ja, um sicherzustellen, dass etwas übergeordnetes übernommen wird, müsste man alles auf Verdacht auf Null setzen (was vermutlich sogar geht. Ich habe das noch nie benötigt aber eventuell geht so was wir * {all: initial})

Aber warum habe ich das noch nie benötigt?

Weil wir eh nie bei „null“ anfangen.

Das ist auch nicht das Ziel. Jedenfalls nicht das Ziel der einzelnen Komponenten. Eine Anwendung wird meistens ein Theme haben, das grundlegende Dinge regelt und vorgibt. Man braucht schon einen Fahrplan, damit nicht alles wie bunt zusammengewürfelt aussieht. Trotzdem gibt es noch genug Individualität, die man nur innerhalb einer Komponente haben möchte.

Und wir hören auch nie bei null auf. Das letzte Wort hat immer der Anwender. Und benutzt den lesemodus oder eigene Farben oder eine Bildschirm-Lupe.

Das ist sowieso irrelevant, weil außerhalb unseres Einflussbereiches, egal welche Vorgehensweise der Entwickler genommen hat.

Von Modulen zu träumen, die man für sich genommen aus dem Zusammenhang gerissen testen kann ist daher - genau der richtige Ansatz.

Ich träume eher von Modulen, die nicht überall einen Zusammenhang erfahren, wo sie keinen haben sollen. Völlig zusammenhanglos und damit absolut universell wiederverwendbar geht wohl nirgends.

Dabei ist .meine-komponente nav a genau so hilfreich wir .meine-komponente__nav-link

Und was spricht dann dagegen, dass man das anders benennt, wenn es gleichwertig ist?

Trotzdem widerspricht es meiner Erfahrung, der ich alle CSS-„Schnipsel“ eines gesamt-Projektes immer als Einheit begreife. Ich nehme auch das css, das mit einer Komponente geliefert, grundsätzlich in mein main.css

Natürlich hat jede Komponente einen Platz (alle Regeln für eine Komponente stehen in einem Abschnitt der Datei und es gibt keinen prinzipiellen Unterschied zu vielen Dateien), aber es verdeutlicht so die Abhängigkeiten, die sich nicht dadurch entfernen lassen, dass man die Styles auf tausend Dateien verteilt.

Wenn du eine Oberfläche gestaltest, sortierst du doch die Dinge auch nicht nach ihrer Art. Erst alle Labels, dann alle Links und dann die Eingabefelder. Du kombinierst die Dinge so, wie sie sinnvoll zusammengehören. Warum widerspiegelt sich das dann nicht im Code? Warum wird da angestrebt alles nach Codesorten zu trennen und das als Gruppiermerkmal zu nehmen? Mit Komponenten findet sich hingegen das zusammen, was zusammengehört. Die Struktur, das Verhalten und das Aussehen. Jedenfalls die individuellen Teile davon.

Auch Desktop-Anwendungen werden komplexer und die vielen, vielen bugs und Sicherheitslücken zeigen, dass man die modularität hin, Altlasten her, nicht mehr überschauen kann. Ganz egal wie winzig die Teile sind, in die man sie stückelt.

Das liegt nicht unbedingt an der Stückelung sondern dass Qualitätssicherungsmaßnehmen teuer sind oder zumindest so erscheinen. Und außer Browsern sehe ich sie eher verschwinden und durch Web-Clients ersetzt.

Dagegen kostet es mich viel Arbeit, Komponenten von anderen so einzubinden, dass sie nicht als Fremdkörper wirken.

Das Problem versuchen wir zu vermeiden, indem wir beispielsweise Material Design als Grundlage nehmen und dann darauf achten, dass Fremdkomponenten dafür ein Styling mitbringen. Und keine Sorge, da bleibt noch genug Spielraum, um nicht beliebig auszusehen.

Oft ist es besser das komplette mitgelieferte css wegzuwerfen und von Grund auf neu zu schreiben, weil es ein aussehen mitliefert, das überhaupt nicht gewünscht ist.

Besonders wenn man für die Komponente oder ein Theme bezahlt hat, ist eine solche Vorgehensweise unwirtschaftlich. Da muss man schon darauf achten, dass das zum Einsatzzweck passt.

dedlfix.