[3.2] Farbgestaltung: Schemata, Konzepte, Umsetzung - was ergibt Sinn? [gelöst]

[Melmac]

Ich hätte da mal ne Frage an diejenigen, die sich mit der Materie schon etwas länger beschäftigen bzw. an die (potenziellen) Anwender, die dies später auch noch bedienen können sollen ...
Kurz gesagt: ich bräuchte etwas Austausch zum Thema Farbgebung bei Styles und deren Umsetzung.

Dass ich in meinem Style mit SASS arbeite und nicht mit "plain CSS", soll bitte niemanden hier vom Antworten abhalten: SASS ist nur der Werkzeugkasten, der mir dies alles erst ermöglicht, aber die Fragestellung ist davon erst einmal nicht abhängig


Ausgangslage:
Ich will mehrere ausgearbeitete Farbschemata anbieten, zwischen denen dann automatisiert gewechselt werden kann.
Bisher war es so, dass hierfür dann verschiedene Farbvarianten eines Styles als Tochterstyles einer "Basisversion" erstellt wurden - für jede Farbvariante wurde also ein jeweils eigener Style installiert.

Mit SASS lässt sich das vermeiden: für jede Farbvariante des Styles gibt es ein eigenes Farbschema, in dem die Farben definiert werden, und zwischen denen dann umgeschaltet werden kann.
Im Konfigurationsfile des Styles gibt es einen "Schalter", bei dem nur der Name des anzuwendenden Farbschemas gewechselt werden muss - der Rest erfolgt dann automatisch im Hintergrund.

So weit, so gut - prinzipiell funktioniert das auch alles bereits.
Momentan bin ich dabei, aus den groben Demo-Farbschemata "richtige" zu machen, wodurch ich mich jetzt auch auf ein Konzept festlegen muss, wie die Farben dann ihren Weg in die konkreten Stylesheets bzw. Klassen/Eigenschaften finden sollen.

... und da fehlt mir noch etwas die Erfahrung, um beurteilen zu können, was Sinn ergibt oder was nur zu aufgeblähtem Code führen könnte.

Das momentane "Konzept", das mir vorschwebt:

1. "Basisfarben" des Schemas definieren bzw. generieren:
   • Die bisherigen Stylesheets habe ich, was die anzupassenden Formatierungen betrifft, in neue "Modul-Stylesheets" aufgespalten. Für die wichtigsten Ansichten bzw. Inhalte gibt es ein eigenes Stylesheet, das nur diese Ansicht bzw. Elemente neu formatiert (es enthält also nur diejenigen Selektoren/Eigenschaften, die hierbei von den weiter geltenden prosilver-Originalen abweichen).
   • Die Definition der Farbschemata und deren Steuerung erfolgt zentral in einem eigenen Stylesheet, das nur hierzu dient.
   • Jedes Farbschema wird 3 bis 5 (bin noch am Basteln ...) fest definierte Farben enthalten, die als "Grundfarben" dienen
   • Diese "Grundfarben" des Schemas und einige wenige häufig verwendete Ableitungen aus diesen "primären" Farben (dien durch entsprechende Funktionen berechnet werden) werden dann Variablen zugewiesen, die sich später dann weiter verarbeiten bzw. manipulieren lassen.
     Dieser so erstelle Fundus an Basis-Variablen soll dann die Ausgangsbasis für das Formatieren von Eigenschaften in den Modul-Stylesheets billden
2. Farben den Klassen/Eigenschaften in den Stylesheets zuweisen:
   • In den Modul-Stylesheets fliegen alle bisherigen HEX-Farbwerte raus und werden durch entsprechende Variablen ersetzt
   • Damit die Möglichkeit erhalten bleibt, die einzelnen Farben für das jeweilige Modul nochmals dediziert anpassen/manipulieren zu können (und um einem Anwender die Chance zu geben, bestimmte Farben nach eigenen Vorstellungen gezielt austauschen zu können):
     Die vorher genannten Variablen erhalten ihre Farbwerte nicht direkt aus dem unter (1) eingerichteten Stylesheet und den dort eingerichteten Variablen, sondern über einen kleinen Zwischenschritt =>
   • Im Kopfbereich des Modul-Stylesheets werden alle in diesem zum Einsatz kommenden Farbvariablen aufgelistet und definiert.
     Der Inhalt einer solchen Variablen kann dann entweder aus einer Grundvariablen aus (1) bestehen (wenn deren Farbwert unverändert gelten soll), oder aus dem Ergebnis einer Manipulation einer solchen Basisvariablen (die gleiche Farbe, hier bei einem Element jetzt aber etwas dunkler, heller, blasser etc.) oder aus einem frei zu bestimmenden Farbwert, der bisher noch nicht definiert wurde

Klingt erst einmal furchtbar trocken und theoretisch, sorry.

Gibt es da etwas, das ich übersehen habe oder gäbe es einfachere Möglichkeiten hierfür, wenn ein Anwender ohne großen Editieraufwand bestehende Farbschemata abwandeln oder neue hinzufügen können soll?

Das Problem für mich ist: falls das Konzept als solches doch klemmen sollte, wirds ein wahnsinniger Aufwand werden, dies neu anzupassen.
Ein paar neue Variablen oder Funktionen für Farbmanipulationen sind schnell ergänzt, aber im Nachhinein nochmals die "Weiterverarbeitung" in Richtungs Stylesheets umzugestalten ...

Wenn etwas unklar sein sollte oder Infos fehlen: bitte nachfragen

[Joyce&Luna]

Hi Melmac

Es gibt ja viele unterschiedliche Farbtöne in Prosilver ich meine ca. 50 sind es.
Ich habe vor ca. 1-2 Jahren mal in Area51 gelesen, das dort einer die Farben reduziert hat meine er kam so auf die ca. die hälfte.
Dazu habe ich mal eine Farbtafel gemacht.
Ich habe schon in Area51 danach gesucht, aber leider bisher nicht gefunden. Man konnte die colours.css davon herunter laden.
Es würde eine Erleichterung sein dazu passend was auf zu bauen.

Edit:
Ich glaube ich irre mich jetzt und es waren weit aus mehr und die wurden auf 50 reduziert. Ich schaue mir das noch mal genauer an.
Ist zu lange her

Habe gerade mal Prosilver das sind mehr wie 50. Dann wurden die Farben auf 51 reduziert denn diese Farbtafel habe ich noch.

[Melmac]

prosilver und die Farben ... nennen wir es mal Wildwuchs
Sowas werde ich mir mit Sicherheit nicht antun: letztendlich ist das kaum noch durchschaubar und noch viel weniger verwalt- bzw. anpassbar.

Der Knackpunkt ist bei mir: es geht ja nicht nur um ein einziges Farbschema sondern um mehrere - zwischen denen dann umgeschaltet werden kann, ohne dass deswegen irgendwelche weiteren Eingriffe in den Stylesheets bzw. Formatierungen der einzelnen Elementeigenschaften erforderlich werden soll/dürfen.

Salopper formuliert: wie sorge ich dafür, dass z.B. das Navigationsmenü und die Kategorietitel, die in Schema A dunkelgrün bzw. 10% weniger dunkel als das Navigationsmenüformatiert werden, jetzt dunkelrot (bzw. 10% weniger dunkelrot) dargestellt werden, wenn ich auf Schema B umschalte - und das gleiche Spiel dann für alle anderen Farbformatierungen und/oder Elemente in deren Farben.

Zusätzlich wäre es ganz nett, wenn jeder Anwender seine eigene Farbpalette hinzufügen könnte, ohne deswegen gleich in allen möglichen Stylesheets wieder rumeditieren zu müssen.

Auf die Weise, wie prosilver vorgeht, kann das nicht funktionieren. Deswegen ja meine Frage, ob jemand ein besserer Weg einfällt oder ob zumindest jemand etwas bei meinem Ansatz sieht, das ich dabei übersehen habe.

Vielleicht hat ja auch jemand "nur" ein paar Infos oder Tipps, wie man am geschicktesten an das Thema "Farbpalette" oder auch "Zusammenstellung von Farben für einen Style" herangehen könnte - für mich ist das hier nämlich mein erster Gehversuch in dieser Richtung.

[Joyce&Luna]

Okay, ich muss mir das Aktuelle mal herunter laden und in Ruhe anschauen.

Mal darüber nach gedacht mit Grafiken zu arbeiten. Aber ich schaue erst mal.
Aber nicht jetzt, muss Früh raus.
Wie sähe es aus, wenn ein neues Schema von einem Anwender erstellt wird und er dafür eine eigene CSS Datei nutzt.

Wenn ich so meine Style bei den Anwender anschaue, verändern die unterschiedlich die Farben und passen optisch noch nicht mal zusammen.
So alla Villa Kunterbunt Ich denke das gleiche werden die auch mit deinem Style machen.

Ich würde an deiner Stelle nur 4-6 Farben anbieten und wer was anderes haben möchte, muss halt daran basteln.

Bis morgen mal

[tas2580]

Salopper formuliert: wie sorge ich dafür, dass z.B. das Navigationsmenü und die Kategorietitel, die in Schema A dunkelgrün bzw. 10% weniger dunkel als das Navigationsmenüformatiert werden, jetzt dunkelrot (bzw. 10% weniger dunkelrot) dargestellt werden, wenn ich auf Schema B umschalte - und das gleiche Spiel dann für alle anderen Farbformatierungen und/oder Elemente in deren Farben.

Gehen wir mal von Dunkelgrün #008800 aus, teilen das in die drei Grundfarben auf und rechnen das in Dezimal um, dann wäre das 0 136 0. Da kann man jetzt ganz einfach 10% abziehen und das wieder zurück in HEX verwandeln, also #007A00.
Wichtig ist wahrscheinlich, dass du die RGB Werte einzeln berechnest und nicht einfach vom Gesamtwert 10% abziehst, wobei das evtl. auch ein interessantes Ergebnis gibt. Falls du nicht von Hex nach Dezimal umrechnen möchtest kannst du die Farben ja auch einfach mit rgb(0, 136, 0) angeben.
Da eine Grundfarbe ein Byte groß ist hat sie 255 als Maximalwert. Wenn du also das genaue Gegenteil haben möchtest musst du einfach 255 abziehen. Das Gegenteil von #008800 ist also #ff77ff. Ob das immer gut aussieht musst du wissen, aber der Kontrast ist so auf jeden Fall immer gut.

Gruß Tobi

[canonknipser]

Hast du dir das schon mal angeschaut: https://www.phpbb.com/community/viewtop ... &t=2413816 ?

[Lehrling]

Das ist ein anspruchsvolles Unterfangen, denn zur Navigationsleiste z.B. gehören ja nicht nur die Hintergrund- und die Schriftfarbe, sondern auch die Linkfarben, inklusive der Farben für hover, focus und visited und gerade der Text sollte ja immer gut lesbar sein und für Überschriften greifen oft auch andere Farbcodes. Ich fürchte, einfache Lösungen werden dann auch ein einfaches Layout generieren, was ja nicht unbedingt schlecht sein muss.

[Melmac]

Erst mal: Danke fürs Feed Back

Ich trenne es am besten in einzelne Posts auf - wird sonst zu viel auf einen Schlag

Hast du dir das schon mal angeschaut: https://www.phpbb.com/community/viewtop ... &t=2413816 ?

Ich wusste zwar, das es das von Hanakin gibt, habe aber bisher noch nicht damit gearbeitet.

Vom Prinzip her kommt das auf das heraus, was ich gerade umzusetzen versuche. Nur, dass ich in meinem Ansatz die Anzahl der so zu generierten Farben/Basisvariablen stark reduziert habe - und mit einem Zwischenschritt bei der Übergabe an die Ausdrücke in den Stylesheets arbeite.
Ich bin da eher von Artys Ansatz mit einer auf das Notwendigste beschränkten Anzahl an real eingesetzten Farben im Style ausgegangen.

In der jeweiligen Palette (Schema): Eine Primärfarbe, eine oder eher zwei sekundäre Farben plus eine "Akzentfarbe"; aus jeder von ihnen noch zwei oder drei daraus abgeleitete Schattierungen, die dann alle zusammen "fest verdrahtet" und abhängig vom gewählten Farbschema an (Basis-)Variablen übergeben werden - und mit diesen wird dann in den Modul-Stylesheets weiter gearbeitet.

In diesen Stylesheets sollen die Rückgabewerte dieser Basisvariablen auch nicht direkt an die jeweiligen Eigenschaften übergeben werden. Das ist, IMHO, viel zu "starr" und löst ein Problem nicht: es artet dennoch wieder in Sucherei und Editiererei aus, wenn ich in einem und für einen bestimmten Kontext einen Farbwert gezielt manipulieren will oder muss, überall sonst aber die "Vorgabe" beibehalten werden soll.

Daher dann auch der Zwischenschritt, den weder Hanakin noch Arty vorgesehen haben - er dürfte mit der Struktur der bestehenden prosilver Stylesheets, IMHO, auch gar nicht sinnvoll machbar sein.

Ich hoffe nur, das erschlägt jetzt nicht: mein Style, der mich erst mit dieser ganzen Thematik hier konfrontiert hat, geht, was die Formatierung betrifft, einen etwas anderen Weg als das klassische prosilver.
Prinzipiell verwendet er erst einmal das CSS von prosilver, unverändert - normalerweise sollte also jede Extension, die auf prosilver-Selektoren setzt, auch mit ihm funktionieren, zumindest also "ala prosilver" formatiert werden, in der Regel aber die "neue Farbgestaltung" übernehmen können.
Auf dieser "Schicht" kommen dann bei mir dedizierte "Modul-Stylesheets" oben drauf, die die Formatierung bestimmter Ansichten oder Blöcken von zusammengehörigen und/oder wiederkehrenden Elementen steuern.

Beispiel: die Darstellung von Beiträgen (in Topics, in den Suchergebnissen, in den PNübersichten ...), deren Layout ja umschaltbar sein soll. Für jede dieser Layoutvarianten wäre eigentlich eine Kette an Edits über mehrere Stellen in den Stylesheets (Plural ) hinweg erforderlich - die dann aber auch noch, je nach Layout, unterschiedlich ausfallen.
Um diesen Block "Beitrag" jetzt konzentriert an einem Ort steuern und formatieren zu können, habe ich das komplette ihn steuernde CSS, sofern es von der Vorlage von prosilver abweicht, in einem eigenen Stylesheet zusammengefasst.

Alle relevanten Klassen/Eigenschaften, die für dessen farbliche Formatierung sorgen, sind dann auch alle an diesem einen Ort versammelt und so ausgelegt, dass sie erst einmal nur dieses eine Modul beeinflussen.

Der Zwischenschritt bei der Farbzuweisung an die einzelnen Klassen/Eigenschaften:
Eigenschaften, die die Farbgebung steuern, bekommen eigene, eindeutige Variablen, die alle im Kopfbereich des Stylesheets aufgelistet werden und wo ihnen dann als Rückgabewerte entweder eine passende Basisvariable zugewiesen wird oder eine Funktion, die den Wert der Basisvariablen gezielt für diesen Bereich oder dieses Element weiter manipuliert.
Der Vorteil, den ich hierbei (noch ... ) sehe: ein Anwender kann auch mal gezielt aus einem gewählten Farbschema ausbrechen, ohne deswegen gleich ein neues erstellen oder in den Berechnungsfunktionen herumwühlen zu müssen (was u.U. die komplette Balance der Schemata zerhacken könnte).

[Melmac]

@Tobi:

Bingo, das ist genau der Punkt, bei dem mir noch das Wissen und Verständnis fehlt und ich momentan Gefahr laufe, dies falsch oder zu umständlich anzugehen

Im Prinzip könnte ich erforderliche Berechnungsschritte ja auch im jeweiligen Schema für die so zu manipulierenden Ausgangsfarben "fest" definieren und somit dann an die konkreten Ausgangsfarben des Schemas anpassen, oder?
Alternativ: diese ersten Ableitungen direkt als Farbwerte festlegen und an eigene Basisvariablen übergeben.
Das bläht zwar erst einmal den Umfang des Schemas etwas auf, ist aber vielleicht exakter steuerbar?

Für die weitere Anpassung "vor Ort" sollte SASS eigentlich genügend Funktionen zur Farbmanipulation bieten, die "universeller" anwendbar sind, ohne deswegen zu unausgewogenen Ergebnissen führen zu müssen.
Auch da muss ich noch so einiges durchackern ...

Die eierlegende Wollmilchsau mit völliger Freiheit bei der Anpassung wirds eh nicht werden können - will ich auch gar nicht
Es soll eine Basis werden, die funktioniert, in sich "rund" wirkt und möglichst einfach um weitere Schemata erweiterbar sein soll - das alleine ist für mich gerade schon heftig genug
Wer unbedingt mehr (Farben) haben will, der darf sich da gerne selbst mit rumschlagen. Die Möglichkeit hat er ja - siehe "Modul-Stylesheets".

[Melmac]

@Anke:

Wie sähe es aus, wenn ein neues Schema von einem Anwender erstellt wird und er dafür eine eigene CSS Datei nutzt.

Aus den Stegreif geantwortet:
Entweder er orientiert sich dabei an der vorhandenen Systematik der vorhandenen Schemata und verwendet entsprechend aufeinander abgestimmte eigene Werte (dafür gibts genügend Generatoren im Inet) ...
... oder er verzichtet komplett auf die Option, zwischen verschiedenen Farbschemata umschalten zu können, und definiert sich seine Basisvariablen selbst und/oder setzt seine Wunschfarben direkt im jeweiligen Modul-Stylesheet ein. Der Rest, der dadurch noch nicht abgedeckt wird, kommt dann in die _custom.css - ganz "klassisch" also.
Wie dies dann gemacht werden soll und in welchem Umfang, bleibt dann jedem selbst überlassen - schwieriger als bisher bei prosilver dürfte es auch nicht sein.

Es ist ja "nur" eine Option, die genutzt werden kann (und daher vorbereitet ist), aber eben nicht muss.

Okay, ich muss mir das Aktuelle mal herunter laden und in Ruhe anschauen.

Die Branches auf GitHub sind in diesem Punkt etwas "veraltet"
Der 3.1 Branch wird ohnehin nicht mehr weiter gepflegt und develop wird erst dann aktualisiert, wenn diese Sache hier zumindest in den Grundzügen steht und funktioniert.

Im Master Branch ist aber der letzte "offizielle" Stand für 3.2.2 drin, der auch die ersten Modul-Stylesheets enthält.

Was ich eventuell anbieten könnte: einen neuen Branch für diese Geschichte einrichten, der dann den jeweiligen Zwischenstand enthält - und jede Menge "experimentellen" Code (klingt doch gleich viel besser als "übriggebliebene Codereste" oder Codemüll" ), der irgendwann mal ausgemistet werden muss.