[3.2] [BETA] Sassysilver

[Lukardo]

Hi,

danke erstmal für den tollen Style und die Arbeit.
Ich wollte den Style verwenden, aber in Rot, also habe ich die _custom_configuration.scss geändert in Farbocde "Red"
jedoch sieht mein Forum jetzt so aus (habe noch den Rotton geändert und das weiß):

[ externes Bild ]

Warum ist bei mir denn alles noch blau? Was mach ich falsch?

Danke und viele Grüße

[Joyce&Luna]

Hallo

Dies ist eine Alpha Version und so noch gar nicht für das Liveboard zu gebrauchen.
Es fehlen noch einige Farben.

Da muss du entweder selber Hand anlegen oder halt warten bis Melmac soweit ist.
Jetzt speziell hier für jeden einzelnen zu diesem Style Support zu leisten, wäre ein Fass ohne Boden.

Also gedulde dich bitte oder probiere es selber aus.

Anke

[Melmac]

Hallo Lukardo,

hast Du Deine Anpassungen ausschließlich in der _custom_configuration.scss vorgenommen?
Wenn ja, dann gibt bitte ihren jetzigen Inhalt in der Pastebin ein oder füge dirt die komplette Datei ein und verlinke das dann hier, damit ich ihn mir mal anschauen kann - es hängt bei diesen Style auch etwas davon ab, was wo geändert und wie es gemacht wurde

Vielleicht kurz eine Info zum Unterschied in der Funktion zwischen der _custom_configuration.scss und der _custom.scss, am besten vielleicht am Beispiel der Farbgebung:

Es sind aktuell 4 Farbschemata vorbereitet, für die jeweis ein "Basisfarbwert" vorgegeben ist: für das Schema "blue" wäre dies zum Beispiel der Farbcode #0B2958.
Dieser Basiswert wird dann einer Variablen (hier: $col_base) zugewisen, die dann als "Ausgangswert" diverser Berechnungen genommen wird, in denen die weiteren Farbwerte ermittelt werden, die innerhalb eines Schemas für die einzelnen Elemente zum Einsatz kommen sollen.
Es werden dabei auch keine "fixen" Farbcodes ausgeworfen, sondern die so berechneten Werte weiteren, sekundären, Variablen zugewiesen. Erst diese werden dann im eigentlichen CSS anstelle fester Farbcodes eingesetzt und beim Kompilieren durch den berechneten Farbcode ersetzt.

Alle im CSS des Styles verwendeten Variablen und SASS-Funktionen, die grundlegenden Berechnungen vornehmen, sind in der _style_configuration.scss angelegt und definiert. Diese Datei stellt somit eine Art "funktionale Steuerzentrale" dar, weswegen an ihr auch nichts geändert werden sollte.

Um jetzt die Vorgabewerte der Basisvariablen anzupassen (Bsp.: um auf das Schema "red" umzuschalten), ohne in die _style_configuration.scss einzugreifen => hierfür ist die Datei _custom_configuration.scss vorgesehen.
Du fügst dort bei Bedarf, wie in den bereits enthaltenen Beispieldaten angezeigt, die für die jeweilige Variable alternativ vorgesehenen optionalen Werte ein.
Hier also: statt blue dann red.
Dies sorgt jetzt dafür, dass in den Berechnungsfunktionen für die sekundären Farbwerte der Farbcode für "red" (#48100C) als Ausgangswert verwendet wird statt, wie bisher der für "blue".

Solltest Du eigene SASS-Funktionen erstellen woillen, also welche, die bisher noch nicht im Style vorhanden sind, dann machst Du dies ebenfalls in dieser Datei.
Der Hintergrund für diese, auf den ersten Blick vielleicht umständlich aussehende, Vorgangsweise ist, dass somit eine klare, auf Dateiebene stattfindende Trennung zwischen "Basiscode" des Styles und den eigenen Codeanpassungen gewährleistet wird.

Wenn Du jetzt aber gezielt einzelne Klassen des CSS oder bei einzelne Klassen die Werte bestimmter Eigenschaften anpassen willst (= die vorgegebenen oder berechneten Werte überschreiben), dann machst Du dies in der _custom.scss.
Es ist das gleiche Vorgehen wie in anderen, "klassisch" aufgebauten Styles auch, nur eben in einer gesonderten Datei, die explizit hierfür vorgesehen ist.

[Da somit alle eigenen = "custom" CSS-Anpassungen in zwei _custom*.scss Dateien zusammengefasst sind, reicht es, diese bei einem Styleupdate nicht zu überschreiben, um alle diese eigenen Anpassungen zu erhalten - es entfällt also das manuelle Nachtragen der eigenen Änderungen ]

-----------------

@Joyce&Luna

Dies ist eine Alpha Version

Stimmt, er ist ja auch noch nicht fertig entwickelt: einige Features fehlen noch, andere sind zwar in den Grundzügen fertig, müssen aber noch "feingetunt" werden - und andere können sich nochmals ändern.
Die Sache mit den Farbschemata funktioniert, nur die Ausarbeitung ins Detail hat noch nicht stattgefunden: es fehlen noch diverse Berechnungen für weitere sekundäre Variablen.
Momentan bin ich auch am überlegen, dieses Konzept nochmals zu überarbeiten, um es schlanker zu machen.
Auf eigene Anpassungen dürfte dies aber kaum Auswirkungen haben, da die anpassbaren Basisvariablen erhalten bleiben werden.

und so noch gar nicht für das Liveboard zu gebrauchen.

Dies würde ich jetzt aber anders formulieren: da er sich noch in Entwicklung befindet und sich noch einiges ändern kann, da noch Features fehlen bzw. einige noch nicht vollständig (= "final") umgesetzt sind, kann das natürlich optische Auswirkungen beim Einsatz in einem Live-Board haben, wenn eine neue Revision aufgespielt wird.
Dessen sollte man sich dann auch bewusst sein - nur: "nicht zu gebrauchen" passt da nicht so richtig. Er ist "nicht zu empfehlen", wenn man nach einem Style sucht, an dem man, einmal auf die eigenen Bedürfnisse angepasst, keine Änderungen mehr vornehmen will und der "fertig" und ohne Ecken und Kanten ist.

Da muss du entweder selber Hand anlegen oder halt warten bis Melmac soweit ist.

Was aber bei jedem Style der Fall ist, auch validierten.

Jetzt speziell hier für jeden einzelnen zu diesem Style Support zu leisten, wäre ein Fass ohne Boden.

Es bist ja auch nicht Du, der im Ernstfall den Support leisten muss; und was ein "Fass ohne Boden" ist, darfst Du daher ruhig mir selbst überlassen

Was wäre, wenn ich dies als Chance sehe, hier feed back zu erhalten, auf Fehler, Ungereimtheiten oder nicht berücksichtigte Funktionen hingewiesen zu werden?
Der Style ist noch in Entwicklung, stimmt, mit Sicherheit auch nicht fehlerfrei und in einigen Bereichen noch "lückenhaft umgesetzt" - aber gerade deswegen ist es absolut okay, sogar wichtig (!), dass hier solche Fragen gestellt werden!

Ich mache dies hier ja nicht, um mich irgendwie als toll bestätigt zu sehen: letztendlich, neben dem Lerneffekt, der dabei auch für mich anfällt, soll es ein Style werden, der ein paar Möglichkeiten mehr bietet und dennoch in grundlegenden Dingen, die immer wieder nachgefragt werden, im Rahmen des sinnvoll machbaren möglichst einfach anzupassen ist.

Dazu braucht es aber die Perspektive des Anwenders, der letztendlich mit diesem Style arbeiten will/muss: ich bin jedem dankbar, der ihn testet und mir feed back gibt.

[Kirk]

Ich habe mir die neuste Version installiert (vorher alte Version komplett entfernt), wenn ich in der _custom_configuration.scss wollte ich bei "Board colour scheme" von blau auf rot wechseln.
Ich habe im Testboard die EXT SCSS Compiler von Arty drauf, nach der Änderung der oben genannten Datei bekomme ich diese Fehlermeldung:

Invalid content in _import_prosilver.scss

Ich denke es hat hiermit zu tun @import url("../../prosilver/theme/stylesheet.css");

[Melmac]

Artys Compiler-Extension stört sich am Importieren der prosilver stylesheet.css über die _import_prosilver.scss - im Gegensatz zu Koala, Prepros & Co., die dies sauber verarbeiten.

Die momentan einzige Erklärung die ich habe, warum dies mit lokal installierten SASS-Compilern nicht passiert, sondern nur bei dieser Extension, hat mit deren Funktionsweise zu tun (so ich deren Code jetzt richtig interpretiere):
Die Extension liest den Inhalt jeder in der stylesheet.scss gelisteten Stylesheet-Dateien aus und sendet diesen zum Kompileren an den Server Artys - der eigentliche SASS-Preprozessor ist dort installiert, die Extension nur der "Bote der benötigten Daten".

Beim Auslesen wird von der Ext kompilierbarar Code, also SASS/SCSS oder CSS erwartet - der aber in der _import_prosilver.scss nicht enthalten ist.
Die Ext kann nicht rekursiv auslesen, also die dort enthaltenen "@import" Anwesungen auswerten bzw. ausführen, da dies in ihrem Funktionsumfang auch gar nicht vorgesehen ist.
Daher dann auch diese Fehlermeldung.

Bei "richtigen" SASS-Compilern ist dies kein Problem: die verfügen über die erforderliche Intelligenz
Ich lehne mich daher jetzt mal aus dem Fenster: es ist ein Fehler, der durch die Extension verursacht wird, nicht einer eines falschen Codes.


[btw.:
Mit Prepros ist es auch nicht erforderlich, diese Extension in einem online-Board installiert zu haben, um (S)CSS-Änderungen dort wirksam zu machen
Ein FTP-Zugangriffskonto aufs theme-Verzeichnes des Boards und eine in einem lokal installierten Board anpassbare Kopie des Live-Styles genügen.
Stylesheet-Änderungen lassen sich so dann "auf Knopfdruck" online stellen (die geänderten Stylesheets werden von Prepros hochgeladen), ohne hierfür einen zusätzlichen FTP-Client zu benötigen - denn braucht man nur bei Änderungen an den HTML-Files.]

[Kirk]

Mit Prepros und Koala hatte so meine Probleme. Da du in der alten Version zusätzlich css Dateien drinnen hattest funktionierte es mit Artys Compiler-Extension.

[Melmac]

Gegenüber den älteren Versionen hat sich in Sachen Stylesheets viel geändert:

"Früher":
Es wurden die originalen prosilver-Stylesheets verwendet, von denen einige (diejenigen, die über die stylesheet.scss zum Kompilieren angezogen werden mussten) entsprechend umbenannt wurden und deren Code via SASS "gestrafft" wurde.
Alle anderen Files im theme-Verzeichnis (also diejenigen, die normal auf "*.css" endeten, blieben auch original - sie wurden aber auch nicht in den Kompilierungslauf einbezogen, sondern ganz normal weiterhin über die overall_header.html eingebunden

"Jetzt":
Es werden jetzt alle prosilver-Stylesheets unverändert übernommen => ein Teil wird durch das Importieren der stylesheet.css von prosilver über die _import_prosilver.scss eingebunden (geht nicht anders, wenn ich sie in den Kompilierungslauf einbeziehen möchte), alle anderen, indem ihre Aufrufe in den jeweiligen HTML-Files auf die Originale im prosilver theme-Verzeichnis gesetzt sind.

Im theme-Verzeichnis von SassySilver sind jetzt also nur noch styleeigene Stylesheets vorhanden.
Ich habe hier => viewtopic.php?f=154&t=239773#p1369443 mal versucht, deren jeweilige Funktion/Aufgabe kurz anzureißen.

Du hast aber Recht: das Repository enthält noch einen Fehler - hab wohl ein Commit nicht eingestellt
Ich korrigiere das und stelle es später neu in GitHub ein.
(Es betrifft nur die Importreihenfolge in der stylesheet.scss - die korrigierte Datei hänge ich hier mal schnell an)

(Arty hatte ursprünglich vor, den Compiler wieder von seinen Servern zu entfernen und damit diese Extension wertlos zu machen - wie lange sie also noch nutzbar sein wird, steht etwas in den Sternen.

Ich schaue mir das trotzdem nochmals an, wie sich dies vielleicht doch noch vermeiden lässt, zumindest solange, wie seine Ext noch funktioniert - dazu aber mehr in einem eigenen Post.

[Melmac]

** Neue Version 0.2.1.1 ALPHA - Downloads siehe erster Beitrag ++

Der Fehler in der Reihenfolge der Importregeln ist jetzt behoben.

[Melmac]

In den Tagen seit meinem letzten Beitrag hier habe ich ein paar Tests durchgeführt um dem Problem mit Artys Compiler-Extension bzw. Koala auf die Spur kommen zu können - und bräuchte jetzt etwas feed back, wie hier aus Anwendersicht am besten weiter vorgegangen werden könnte.

Kurz zusammengefasst: sobald über die stylesheet.scss auf Dateien zugegriffen wird, die sich nicht im SassySilver-Themeverzeichnis befinden (also: sobald CSS-Dateien von prosilver importiert werden), bereiten diese beiden Programme Probleme: sie können dem anscheinend nicht folgen und die angegebenen Files einlesen, wohingegen dies mit Prepros einwandfrei funktioniert ...
Koala ist ein vergleichsweise sehr einfach gehaltener Preprocessor, reduziert auf die notwendigste Funktionalität (und schon lange nicht mehr aktualisiert worden) - zu der wohl das, was es hierzu erfordern würde, nicht gehört.

SASS selbst bzw. der Import-Code ist hierbei auch nicht die Ursache: die aktuellen SASS-Bibliotheken unterstützen das von mir gewählte Vorgehen nativ - "SASS kann das"

Um Koala oder Artys Extension verwendbar zu machen, müsste ich auf das Importieren der prosilver Stylesheets verzichten und diese Dateien wieder direkt ins SassySilver-Themeverzeichnis aufnehmen (entsprechend in der Namensgebung angepasst natürlich, damit sie auch vom Kompilierungslauf erfasst werden können).

Vorteil:

• Diese beiden Compiler können weiter verwendet werden.
• Die ursprüngliche Struktur des Themeverzeichnisses bleibt erhalten und ich erspare mir zumindest die _import_prosilver.scss

Nachteile:

• Es werden in sich "unnötige" Datein "mitgeschleppt", die eigentlich nicht erforderlich sind, da an deren Code ohnehin keine Änderungen vorgenommen wird
• Das Update des Styles wird für mich aufwändiger: die betreffenden Stylesheets müssen von der neuen prosilver Version ins Themeverzeichnis von SassySilver kopiert und erneut umbenannt oder, alternativ, die Änderungen zwischen den prosilver Versionen manuell übertragen werden.
  Beides erhöht die Chancen, dass sich dabei Fehler einschleichen.
• Dito für den Anwender, sollte er einmal ein manuelles Update durchführen müssen oder wollen.

Letzteres wäre sogar etwas, das ich gerne vermeiden würde, soweit sinnvoll machbar.

Beim jetzigen Vorgehen (Import der Stylesheets von prosilver) kann ich dies umgehen: mit jedem Update von prosilver werden auch automatisch alle Änderungen im Bereich der Stylesheets nach SassySilver "übertragen".
Der Nachteil eben: es muss zum Kompilieren ein vollwertiger Preprocessor eingesetzt werden, der auch alle Funktionen und Möglichkeiten von SASS unterstützt.
(Prepros ist free für den nicht-kommerziellen Einsatz, plus: er bietet, wie schon einmal angerissen, ein paar imA nützliche Zusatzoptionen)

Die Frage ist jetzt: wie weiter? Was wäre aus Anwendersicht der bessere Ansatz?

[Kirk]

An deiner Stelle würde ich es so beibehalten wie es jetzt ist. Auch wenn ich mit Prepros Probleme hatte heißt es nicht das es anderen auch so geht. Was Artys Compiler-Extension angeht, kann es sein das bei zukünftigen phpBB Versionen diese gar nicht mehr funktioniert.