Mein Forum
Registrieren
Neu hier?
Baukonstruktionen
Fertighaus
Fenster
Dämmung
Dichtheit
Passivhaus
Schimmel
Energieausweis
Heizung
Pellets
Erdwärme
Warmwasser
Stromsparen
Solaranlagen
Photovoltaik
Lüftungsanlagen
Energiespartipps
Berechnungen
Teilen:
|
|
||
|
Ja so ist es jetzt eh wieder. Mit dem Schönheitsfehler, dass ein Cookie ausgelesen werden muss, und dass das eben diese Zeitverzögerung mit sich bringt, die fallweise zum Aufblitzen der weißen Seite führt. Wir werden das serverseitig lösen. |
||
|
||
|
Sinngemäß funktioniert es eh schon so, nur die Implementierung ist scheinbar nicht so einfach. Man kann media queries nicht overriden, also muss man auf jeden Fall mit JS direkt das CSS manipulieren. Und das halt im Idealfall so, dass man nichts nachladen muss und das JS auch schon im HTML embedded. Ob man dann noch die media queries einbaut oder gleich alles selber macht, ist glaub ich schon fast egal. Bezüglich Reihenfolge hast du natürlich Recht, da hatte ich einen Denkfehler. |
||
|
||
|
@energiesparhaus das Problem ist nicht das Cookie, sondern dass zwei zusätzliche sequentielle Requests passieren. Zuerst wird das JS geladen, dann ausgeführt, dann aus dem JS noch das CSS. Da kann man schön zuschauen, wenn man im Browser eine langsame Verbindung simuliert. Serverseitige Lösung finde ich super, das Cookie ist ja schon da 🙂 |
||
|
||
|
@christoph1703 : und serverseitig ist es auch wieder nicht einfach weil der Server nicht weiß ob der User im Browser prefers-color-scheme (bzw. halt die Auswahl des Betriebssystems verwenden will) gewählt hat. Diese Eigenschaft ist serverseitig nicht bekannt, somit muss erst recht wieder über JS abgefragt werden. Ideen werden gerne angenommen... |
||
|
||
|
Eigentlich müsste der Server das schon mitbekommen. Die Einstellung wird ja als Cookie gespeichert und Cookies werden mit jedem Request vom Browser an den Server mitgeschickt. Was für ein Backend habt ihr denn in Verwendung? |
||
|
||
|
Die Präfernz des Users wird als Cookie gespeichert, die Systemeinstellung kennen wir nicht. Evtl. müssen wir da über die Logik noch nachdenken. |
||
|
||
|
Der Server bekommt prinzipiell das Cookie sehr wohl mit dem Request vom Browser mitgeschickt. Kann also sehr wohl im Reply den entsprechenden Link von unterschiedliche CSS Varianten im Header auswählen. Kein Clientseitiges Javascript nötig. Weiß natürlich nicht wie euer System tickt aber mit node.js könnte ich sowas programmieren. |
||
|
||
|
Die high-level Logik wäre dann: - Cookie sagt hell: helles CSS - Cookie sagt dunkel: dunkles CSS - Cookie sagt System: CSS mit prefers-color-scheme - kein Cookie (neues Gerät): auch CSS mit prefers-color-scheme Wie @purrtastic schon gesagt hat, wir helfen gern. |
||
|
||
|
Ja der Server kann natürlich das Cookie auslesen, nur nicht die Systemeinstellung am Handy. Deshalb müssen wir sa noch etwas nachdenken. @christoph1703 : Über Dark Mode trauen wir uns ohne dezidierte Auswahl vom User nicht drüber. Ansonsten ist das eh die aktuelle Logik. Nur halt nicht optimal umgesetzt wg. Skript am Client. |
||
|
||
|
Juhuuuuu normale Ansicht Bei uns auch alles Darkmode , Hsndy im permanenten Nightshiftmodus, aber Forumsseite geht nur im Light Mode angenehm 😀😀 |
||
|
||
|
@energiesparhaus ich glaube wir reden aneinander vorbei. Die Auswahl in den Benutzereinstellung soll nicht verschwinden. Das war wohl ein Missverständnis von Beginn an, weil mir da noch nicht bewusst war, dass man media queries nicht overriden kann. Die clientseitige Implementierung bis zum Setzen des Cookies braucht keine Änderung. Nur serverseitig könnte man optimieren wie folgt: Cookie aus dem Request auslesen - dabei können die Werte "light", "dark" und "system" rauskommen. Für jede der drei Optionen gibt es dann ein eigenes CSS. Die für "light" und "dark" sind selbsterklärend - jeweils das entsprechende Theme. Das für "system" enthält beide Themes (da der Server ja die Systemeinstellung des Clients nicht kennt) und schaltet mit prefers-color-scheme dazwischen um. |
||
|
||
|
Ja das ist genau das was es brauchen würde. Jetzt haben wir noch das kleine Problem dass wir einen Haufen statischer HTML-Seiten haben wo wir serverseitig gar keinen dynamischen Code ausliefern. Weiß jemand was man am IIS umstellen muss damit htm auch durch den compiler laufen wie cshtml? Handler-Zuordnung adaptieren bringt die Fehlermeldung  |
||
|
||
|
Ui, von IIS hab ich leider gar keinen Plan. Wärs vielleicht eine Option, das in den Handler fürs CSS zu integrieren? Dann müssten die statischen Seiten gar nichts davon mitkriegen - also im HTML würde immer das gleiche CSS referenziert werden und der Server liefert dann unter diesem Pfad eine dynamische Antwort. |
||
|
||
|
Schuss ins Blaue: Was passiert, wenn man die Files auf cshtml umbenennt? In dem Fall wäre die Lösung mit dem dynamischen CSS Handler aber eleganter, dann müsste man nicht den gleichen Code auf X Seiten duplizieren. |
||
|
||
|
Umbenennen wäre möglich aber schlecht für SEO. Man müsste umbenennen und die alten URLs per url_rewrite umbiegen. Ginge schon, eleganter wärs wohl anders. |
||
|
||
|
Ja, das spricht dann mehr für die Lösung mit dem dynamischen CSS Handler. |
||
|
||
|
Weil ich gerade vor einem ähnlichen Problem stehe und bei die User auch light oder dark pro Gerät in Seiteneigenen Settings überschreiben können sollen. Bei mir ist das in localStorage und daher auch erst aktiv wenn js zum laufen beginnt. Aber ich finde es total okay, im Ladevorgange CSS prefers-color-scheme zu verwenden und erst dann evt. einen User override aktiv zu machen. Wer z.B: an einem OLED-Gerät sitzt wo light mode wirklich unangenhm hell sein kann, der soll halt das einstellen, bzw. wird sich kaum über aufblitzen beschwerden, wenn er sonst einen light mode als default hat. Wobei dazu zu sagen ist, für meine Seite gilt das nur beim ersten Aufruf, bewegungen in der Seite sind über pseudo history und dynamisches js fetching.. |
||
|
||
|
Ja, grundsätzlich spricht nicht viel dagegen, die finale Einstellung im JS zu machen. Das sollte halt besser ohne zusätzliche Requests zum Server gehen, dann ist das Aufblitzen ziemlich sicher auch kein Thema. So wie es jetzt umgesetzt ist, habe ich 2x 23 ms Netzwerklatenz bis das dunkle CSS da ist, plus die Zeit die der Browser braucht um das Ganze auszuführen. Ich habs jetzt für mich mit einem Proxy gelöst, der mir das CSS ersetzt. Bookmarks geändert und passt 😉 |
||
|
||
|
Die serverseitige Umschaltung funktioniert! Vielen Dank dafür @energiesparhaus ! Ich hätte noch zwei Verbesserungsvorschläge: In /ressources/tinymce/skins/ui/oxide/content.min.css die Textfarbe von schwarz auf weiß ändern: @media (prefers-color-scheme: dark) { Und an dark.css hab ich auch noch ein paar rudimentäre Anpassungen gemacht: https://gist.github.com/typerat/ad8aa896a2e48fd04d965c713ad6c594 Ein bisschen mehr Liebe schadet sicher nicht, aber so ist es größtenteils schon sehr gut verwendbar 🙂 |
||
|
||
|
Schauen wir uns an, danke. Allerdings können wir in die tinymce-skin das nicht direkt eintragen sonst greift die Einstellung nicht mehr wenn jemand die Systemeinstellungen überschreiben will (heißt laut persönlichen Einstellungen immer light mode haben will) |
||
|
||
|
Richtig, das habe ich jetzt nicht bedacht. Eigentlich müsste man das aber auch im dark.css einbauen können, oder? Dem Browser ist es ja egal, aus welcher Datei die Regel kommt (solange die Reihenfolge stimmt). |
Beitrag schreiben oder Werbung ausblenden?
Einloggen
Kostenlos registrieren [Mehr Infos]
