Anpassung der On-Premises-Lizenzen zum 1. Januar 2023

Zitat von Fightcrasher

Viel wichtiger wäre es den Designer mehr Freiheit zu geben sie können aktuell nicht alle Möglichkeiten ausschöpfen.

Inwiefern können sie die Möglichkeiten nicht ausschöpfen? Weil es der Redactor nicht zulässt?

Zitat von Gentlemantis

Inwiefern können sie die Möglichkeiten nicht ausschöpfen? Weil es der Redactor nicht zulässt?

Woran es genau liegt kann ich dir nicht sagen hatte aber erst gerade den Fall wo Tom sagte da ist Woltlab dran schuld das ich das nicht ändern kann und das habe ich leider schon öfter lesen müssen unter anderem beim Dark Mode

Zitat von Gentlemantis

Ja das habe ich verstanden, tut mir Leid, ich habe mich falsch ausgedrückt.

Was ist denn für dich persönlich der aktuelle Standard?

Der Standard wäre, so banal wie es klingen mag, erstmal einen Dark Mode zu implementieren. Zudem werden UI Elemente immer abgerundeter, gerade im Mobile First Design werden die Innenabstände erhöht und auf Border, so gut es geht, verzichtet außer diese bieten einen visuellen Vorteil. Das wurde z. B., mal ungeachtet der ungünstigen Farbwahl, bereits auf der Startseite und im neuen Benutzermenü gut umgesetzt. Leider hat sich dieser Stil noch nicht im Standarddesign, gerade im Bereich der Forenauflistung, durchgesetzt und das Design leidet an einigen Stellen auch an überflüssigem Whitespace.

Auf Designkonzepte wie Neu-, Clay oder Glassmorphism muss man nicht aufspringen, aber ein gesunder Minimalismus lässt den Stilentwicklern genügend Freiraum, kreativ tätig zu werden.

Zitat von Tom

Dazu müsste man aber den kompletten Stileditor umbauen, dazu wird es wohl aber nicht kommen 🤷‍♂️

ich könnte mir vorstellen, dass man mit einem Umstieg auf CSS-Variablen (statt SCSS) dem Ziel Dark Mode etwas näher kommen könnte. Dann könnte man "on the fly" anpassen. Im ersten Schritt vielleicht erst mal ohne extra UI und nur Code aber bei den meisten Designern/Stilerstellern sehe ich da eigentlich kein großes Problem.

Ist halt nur die Frage wie performant sowas dann ist. Da fehlt mir ein bisschen der Vergleich.

Zitat von Tom

ist das ganze nicht so einfach.

das sicher nicht, dann wäre es ja auch umgesetzt.

Aber abseits vom Logo (ich muss mal testen ob mein Denkansatz dafür funktioniert) wie viele statische Bilder hat man im Design, die man nicht per Query ersetzen könnte, weil sie als Hintergrund eingesetzt werden?

Vom Nutzer hochgeladene Bilder in Beiträgen etc. sind dann natürlich ein Problem aber das ist jetzt mit reinen dunklen Stilen auch nicht anders.

Nachtrag: ich teste mal ob das geht, was ich denke, und dann poste ich mal ein zusammenhängendes Beispiel davon was ich mir vorstelle

Zitat von Jay-Eric

wie viele statische Bilder hat man im Design, die man nicht per Query ersetzen könnte, weil sie als Hintergrund eingesetzt werden?

In der Regel gar keines. Theoretisch lässt sich ja einfach ein anderes CSS-File laden, das eben hell oder dunkel ist.

Zitat von Jay-Eric

Vom Nutzer hochgeladene Bilder in Beiträgen etc. sind dann natürlich ein Problem aber das ist jetzt mit reinen dunklen Stilen auch nicht anders.

Eigentlich nicht; zumindest nicht mehr als vorher. Die Bilder müssen ja keinen optischen Kontrast zum Hintergrund aufweisen. Problematisch sind nur Bilder, die teil-transparent über irgendwas liegen oder als Hintergrund eingebunden sind.

Zitat von Tom

Ich habe das Gefühl das "einfach" kein Kriterium für eine Umsetzung ist

Stimmt. Vermutlich wäre es verständlicher gewesen zu schreiben: Wenn es einfach wäre, könnte es jeder.

Um noch mal auf meine Idee mit den CSS-Variablen einzugehen, versuche ich hier mal das etwas ausführlicher darzulegen. Es sei dazu gesagt, dass ich versuche eher auf Verständlichkeit (für alle) als auf 100% technisch korrekte Begriffe zu setzen. Und nicht alles was ich schreibe muss exakt so im WSC zu finden sein, es sind nur Beispiele zur Erläuterung.

Bisher ist es so, dass u.a. die Farben in SCSS-Variablen "gespeichert" werden, z.B. $wcfContentBackground. Das ganze wird dann auf dem Server verarbeitet und im Stylesheet z.B. als

body {
    background-color: #fff;
}

abgelegt.

Problem an der Sache: Auf dem Server liegt jetzt fertiger CSS-Code. Wollte man jetzt auf einen im Browser oder Betriebssystem eingestellten Dark Mode reagieren, ginge das aktuell nur in dem die relevanten Deklarationen überschreibt. Im Worst Case heißt das: 100% Doppelter Code. Beispiel:

body {
    background-color: fff;
}

@media (prefers-color-scheme: dark) {
    body {
        background-color: #111;
    }
}

Würde man jetzt statt der SCSS-Variablen alle Werte in CSS-Variablen speichern, hätte man auf dem Server ein Stylesheet mit diesem Inhalt

body {
    background-color: var(--wcfContentBackground);
}

Irgendwo weiter oben in der Datei wäre die Variable definiert.

Man hätte jetzt also die Farben von den Variablen getrennt und die Ersetzung erfolgt erst im Browser. So könnte man dann auf Einstellungen im Browser reagieren ohne 100% doppelten Code zu haben.

Soweit erst mal die Vorarbeit.

Meine Idee wäre jetzt im ersten Schritt zu sagen: Ok, wir setzen erst mal auf CSS-Variablen, den SCSS Parser behalten wir (noch) bei. Es gibt aber im ersten Schritt noch keine zusätzlichen Eingabefelder für Farben, sodass sich der Entwicklungsaufwand auf WoltLabs Seite erst mal in Grenzen hält.

Dann hätte man zum Beispiel im Stileditor für wcfContentBackground #fff in die Farbpalette eingetragen und würde dann im zusätzlichen CSS noch hinterlegen

@media (prefers-color-scheme: dark) {
    :root {
        --wcfContentBackground: #000;
    }
}

Was man an zusätzlichen Feldern schaffen könnte: Einmal im Stil selbst einen Toggle für die Option "experimenteller Dark Mode Support" mit der Beschreibung "erfordert zusätzliches CSS". Diese Option würde dann ein zusätzliches Feld sichtbar machen, in das man noch ein Logo für den Dark Mode laden kann.

Das Logo selbst könnte man dann im Template so einbinden

<picture>
    <source srcset="logo-light.png"
            media="(prefers-color-scheme: light)">
    <source srcset="logo-dark.png"
            media="(prefers-color-scheme: dark)">
    <img src="logo.png" alt="">
</picture>

Das habe ich gerade mal in Firefox, Chromium und Safari getestet, keiner hat Probleme damit. An sich ist <picture> auch lange genug unterwegs und wenn prefers-color-scheme nicht weit genug verbreitet wäre, gäbe es diese Unterhaltung nicht.

Jetzt kann natürlich sagen: Das bläht den HTML-Code auf. An der einen Stelle. Aber wenn man Dinge mit Javascript löst, für die es CSS gibt, hat man aus meiner Sicht ganz andere Probleme.

Die restlichen Grafiken sind aus meiner Sicht i.d.R. nur Hintergrundgrafiken und werden per CSS eingebunden.

Ist das jetzt die perfekte Lösung? Vermutlich nicht. Aber es wäre ein Anfang und würde ein paar mehr Möglichkeiten schaffen. Der Nachteil für den Administrator ist dann im ersten Schritt natürlich erst mal das man nur eine Farbpalette sieht und sich die zweite im Code versteckt. Aber das wäre dann bei experimentellen Funktionen eben erst mal so. Wenn man das von Seiten WoltLabs und der Designer klar kommuniziert, sollte das kein allzu großes Problem sein. (Es wird natürlich wieder die üblichen Verdächtigen mit den üblichen Kommentaren geben.)

Hinsichtlich der Kompatibilität: Die hat man ohnehin schon mit 6.0 gebrochen. Dann kann man das auch gleich richtig machen. Denn wenn man das jetzt nicht macht, kommt das niemals. Zumal aus Designsicht eh nur ein Versionsupgrade wirklich problemlos kompatibel war (ich glaub 5.2 auf 5.3).

Und noch mal: Im ersten Schritt verkauft man das erst mal als experimentelle Funktion. Dann kann Erfahrung in der echten Welt sammeln.

Das ist jetzt doch etwas länger geworden als urspünglich gedacht. Sorry. Ich hoffe es ist verständlich was ich meine.