CSS Klassennamen Schreibweise

[marctrix]

Hej dedlfix,

Wie ist denn eure Meinung dazu? Was meint ihr, was für ein Problem die Entwickler und Verwender von BEM und verwandten Methoden zu lösen versuchen?

Vielleicht die Kaskade zu erlernen?

Sich davor zu drücken, CSS zu verstehen. Nicht böse gemeint, denn die Zeit wird Entwicklern oft nicht zugestanden.

Vermutungen.

Zugegeben.

Leider habe ich auch nicht viel mehr zu bieten. Vielleicht haben die Entwickler die Kaskade besser verstanden, als du es ihnen zugestehst. Im Grunde genommen ist das auch nur eine Art der Vererbung. Vererbung ist aus der OOP zur Genüge bekannt. Und auch die Probleme, die damit verbunden sind. Nicht umsonst geht man heutzutage meist den Weg der Single Responsibility, kleine Einheiten für genau abgegrenzte Aufgaben, statt eine große Vererbungsstruktur aufzubauen, wo jeder mit jedem verwandt ist.

Ist ja nicht so.

Verwandtschaften sind ausschließlich vertikal von unten nach oben und horizontal in demselben Kontext gegeben.

Also innerhalb einer Komponente.

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.

Kein Browser kommt ohne Browser-Styles. Selbst alles auf den initialen wert zurückzusetzen heißt mit Gegebenheiten auskommen zu müssen.

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.

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

Ein Modul muss für sich allein genommen funktionieren. Aber eben auch in einem unbekannten zusammhang.

Um Konsistenz in aussehen nutzen zu können, bin ich auf Vererbung angewiesen.

Beispielsweise um durchgehend gleiche Schriftgrößen und -farben sicherstellen zu können.

Wer mittels HTML, SASS, CSS, RDF(a) (oder ähnliches) ein Layout auf Touch-Screens und Mausschubser-Oberflächen so umsetzt, dass es in allen Browser-OS-Screenreader-Kombinationen zugänglich ist, denkt anders als ein Programmierer.

Das ist die Essenz meiner über 20jährigen Laufbahn.

Und mir ist immer noch kein einziger guter Programmierer begegnet, der nicht dankbar war für meine Unterstützung, weil ich Dinge wusste, die ihm nicht in der Tiefe und mit allen Konsequenzen und Begründungen so klar waren wie mir.

Mir ist auch noch kein html-css-Barrierefreiheits-Fuzzy begegnet, der ausgezeichnet programmieren kann.

Auch diejenigen, die gelegentlich etwas js oder so produzieren (@Gunnar Bittersmann oder Heydon Pickering um mal zwei beim Namen zu nennen) würden sich nicht als Programmierer bezeichnen.

Es gibt immer die Ausnahme, die die Regel bestätigt, vielleicht bin ich ihr auch schon begegnet und weiß es nur nicht. Aber wie viele Firmen haben diese Ausnahmen unter ihren Angestellten und wissen das auch noch.

In der echten Welt spielen die praktisch keine Rolle.

Insofern bleibt es dabei: man ist entweder Frontender oder Programmierer oder von beiden etwas.

Das liegt nicht nur an den unterschiedlichen Denkweisen, sondern auch an der Zeit, die für alle nicht Genies nötig wäre mehreren stacks ständig up-to-Date zu bleiben.

Für mich ist die schleppende Verbreitung von css-Grid ein Beleg dafür.

Programmierer wurschteln lieber weiter mit dem ihnen bekannten bootstrap vor sich hin, statt das effiziente CSS-Grid zu nutzen.

Einfach weil ihnen die wenige Zeit fehlt, die es kosten würde, sich damit auseinander zu setzen.

Es ist eine Notwendigkeit, modular arbeiten zu können. Nicht ohne Grund ist man dabei, Web Components auf den Weg zu bringen, die jeweils ihr eigenes DOM bekommen. Kleine Einheiten lassen sich besser testen und damit warten als große Monster.

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

Aus eigener Erfahrung mit Angular (und auch Desktop-Anwendungen) kann ich zumindest sagen, dass es sich einfacher arbeitet, wenn man Komponenten erstellen kann, und man für diese jeweils eine HTML- und CSS-Datei mit deren individuellem Code in der Nähe hat, statt irgendwo abseits eine zentrale CSS-Datei zu pflegen, die beständig anwächst.

Das ist interessant, weil ich das schon öfters gehört habe.

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.

Vielleicht weil man gezwungen ist, CSS und HTML zusätzlich zu einem Full Stack und einem Software-Stack „so nebenbei“ mitzumachen?

An ein "nebenbei" glaub ich gar nicht mal. Auch bei Desktopanwendungen hat man die Notwendigkeit gehabt, eine Oberfläche zu erstellen. Das sind keine "Nebenbei"-Tätigkeiten. Damals hat nur keiner von Full-Stack gesprochen und die Welt in Frontender und Backender aufgeteilt.

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.

Ich glaube auch nicht, dass wenn man sich extra Frontender leisten kann, es sich diese leisten können, bei entsprechend großen und komplexen Anwendungen auf Modularisierung zu verzichten. Aber vielleicht kenne ich einfach nur CSS nicht gut genug.

Nein, du hast schon recht. Man betrachtet auch als CSSler nicht die gesamte Anwendung, wenn man ein Formular umsetzt.

Aber man respektiert und nutzt die Kaskade.

Ich bin dankbar, dass es sie gibt und gehe davon aus, dass meine Komponente in verschiedenen Anwendungen richtig aussieht. Zumindest wenn sie in Anwendungen eingesetzt wird, für die ich das css geschrieben habe. Denn dann habe ich immer daran gedacht, was wird vererbt und will ich das - oder nicht.

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

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.

Marc