Tabellarische Visu: Page um Background und Transparenz erweitern

[swiss]

Hallo Zusammen

Ich bräuchte mal kurz etwas Hilfe bei der Umsetzung einer Idee...

Was ich schon hinbekommen habe ist, dass man die Option backdrop auch ohne 2d/3d verwenden kann. Denn mit 2d fällt mir das tabellarische Design auseinander. Auch habe ich in der custom.css mal mit opacity experimentiert. Leider lässt sich die CSS Regel nich nur auf die Page anwenden in der auch das Hintergrundbild eingebunden ist. Also müsste die CSS Regel im js code des page widget eingebunden werden. Daher kam mir die Idee die Transparenz gleich einstellbar zu gestalten.

Und jetzt zu meinem Probelm...

Ich bin in js leider garnicht zuhause und bräuchte mal ein Tipp oder codeschnippsel wie man in js eine CSS Regel an alle widgets innerhalb der aktuellen Page vererbt.

Im Anhang habe ich mal ein screenshot. Aber man sieht auch, dass die CSS Regel auf z.B. die Navbars angewendet wird

[Chris M.]

JS und CSS sind erst mal getrennte paar Stiefel, genau so wie das DOM was (typischer Weise) aus dem HTML entsteht...
JS hat aber die Möglichkeit beliebig am CSS (und am DOM...) zu drehen

=> Was brauchst Du genau?
Backdrop bei "Text" und ein einstellbares Opacity für "alles"?

[swiss]

Hallo Chris

Danke für die Rückmeldung

Mir ist schon klar, dass js und css 2 paar Schuhe sind. Doch werde ich bei meinem Vorhaben nicht drum herum kommen die CSS Regeln quasi zur Laufzeit umzubiegen.

Die Idee war:
- Backdrop unabhängig von 2d/3d nutzbar -> funktioniert
- Wenn backdrop nicht "" ist, soll allen Widgets auf der Page die CSS Regel opacity übergeben werden damit der Hintergrund durch die Widgets "hindurch scheint" -> funktioniert noch nicht so wie ich es gerne hätte
- Am Ende noch opacity pro Page einstellbar im Editor

Sollte eigentlich nicht schwer sein und ich habe es schon hinbekommen dass opacity an die Widgets der entsprechenden Seite vererbt wird doch scheint der Background der Groups dadurch nicht transparent zu werden

[swiss]

Was cool wäre... Wenn opacity nur auf die Widgets aber nicht auf die icons und Texte angewendet werden würden. Damit wären so coole Ansichten ähnlich der Domovea Visu möglich ohne die ganzen einschränkungen...

Der erste Versuch (Bild ganz oben) war schon nahe an dem dran was ich gerne umsetzen möchte. Nun fehlt es mir aber an der Vorstellung wie ich das erreichen kann. Hier mal ein Beispiel wie ich mir das Zusammenspeil von Hintergrund und Transparenz vorstellen würde.

[Chris M.]

(Ohne nochmal die Referenzen konsultiert zu haben Die Opacity sollte alles, d.h. inkl. Vordergrund (also Text, Icons) mehr oder weniger transparent machen - wie Du schon geschrieben hast, ist das wohl nicht das, was Du erreichen willst.
Einen Hintergrund kann man getrennt davon durchsichtig machen (-> Alpha).

Ich schau mir jetzt gleich mal den Code an, ob da was generisches gut umsetzbar ist. Mit einer Custom.css sollte da aber bereits jetzt schon viel möglich sein

[swiss]

Hallo Chris

Ich bin ja eigentlich schon relativ weit. Was mein Problem ist, dass ich nicht weiss, wie ich die CSS Regel die ich dem Page Widget übergebe an die in der Page enthaltenen Widget_container weiter vererben kann. Hier fehlt mir das Verständniss. Weil Page zwar opacity oder alpha übernimmt aber z.B. alpha nicht automatisch an die Widgets weiter vererbt... Dies führt natürlich dazu dass die Grups und widgets trotzdem nicht transparent werden. Ich kann aber auch nicht einfach eine Regel an die CSS Klasse widget_container hängen da sonnst auch die Navbars mit den enthaltenen Groups davon betroffen wären.

[Chris M.]

Nun, das Problem ist, dass die gewünschte Eigentschaft beim Metal-Design in der CSS Class .widget ist (-> background-image). Das müsstest Du bzgl. Alpha übersteuern - was aber nicht geht, Du kannst das höchstens ersetzen.

=> Das Design hat die Hoheit über das Alpha in diesem Fall, die Visu-Logik sollte das nicht manipulieren.

Daher würde ich vorschlagen, die Designs so zu überarbeiten, dass die auch mit einem Backdrop-Image umgehen können.
Das war bisher noch nicht relevant, d.h. die Designs haben sich da bisher noch nicht drum gekümmert...

Probier mal beim Metal das

linear-gradient(#444444, #2d2d2d)

durch

linear-gradient(rgba(68,68,68,0.3), rgba(45,45,45,0.3))

zu ersetzen (0x44 = 68, 0x2d = 45, 0.3 = 30%)

[swiss]

Hallo Chris

Vielen Dank für den Tipp Deine CSS Regel führt genau zu dem gewünschten Verhalten. *freu*

Doch was ich nicht verstehe...

Wiso kann man die Transparenz (und nur die Transparenz) nicht einfach zur Laufzeit unabhängig vom Design an .widget übergeben? Wiso muss/soll das Design die Hoheit darüber haben? Was macht es denn für einen Sinn dem Benutzer "vorzuschreiben" dass bei einem Hintergrund die Groups nicht durchsichtig sein dürfen? Wenn das im Editor einstellbar wäre, kann jeder Benutzer frei entscheiden und muss nicht extra (wenn er das ja sowiso will) noch die custom CSS bemühen um die Diktatur vom Design zu überschreiben. Das macht es doch nur wieder auf unnötige Art und Weise viel umständlicher...

Oder habe ich da etwas entscheidendes übersehen was gegen den Ansaz: "Der User soll selber entscheiden dürfen" spricht?

Edit: Ich finde das Ergebniss echt cool Jetzt sollte es nur noch möglichst benutzerfreundlich sein...

[Chris M.]

Doch was ich nicht verstehe...

Wiso kann man die Transparenz (und nur die Transparenz) nicht einfach zur Laufzeit unabhängig vom Design an .widget übergeben? Wiso muss/soll das Design die Hoheit darüber haben?

Weil das Design, nun, eben das Design festlegt...
Das Design legt die Farben etc. fest - und ein Widget kann so nun eine Farbe haben, einen Gradient (wie bei Metal) oder gar ein Hintergrund-Bild...
Per JS-Programm könnte man bei einer Farbe noch ein Alpha drüber mischen, mit mehr Aufwand sogar auch noch bei einem Gradienten. Aber spätestens bei einem Bild wird's fürchterlich hässlich...

=> Wenn man per JS hier *gegen* das Design arbeitet, ist's der Anfang vom Ende.

Aber, Hilfe naht: wir machen ja Open Source - wir haben die Hoheit über's Design! Also nicht Konfrontation - Kooperation ist angesagt!

Was macht es denn für einen Sinn dem Benutzer "vorzuschreiben" dass bei einem Hintergrund die Groups nicht durchsichtig sein dürfen?

Keine Ahnung - das wird der Designer des Designs sich schon bewusst überlegt haben.

(Verteidigung für alle Designs die jetzt aktuell vorhanden sind: Backdrop war kein oder kaum ein wichtiges Feature. D.h. wohl kaum ein Designer wird bisher darauf geachtet haben)

Wenn das im Editor einstellbar wäre, kann jeder Benutzer frei entscheiden und muss nicht extra (wenn er das ja sowiso will) noch die custom CSS bemühen um die Diktatur vom Design zu überschreiben. Das macht es doch nur wieder auf unnötige Art und Weise viel umständlicher...

Wenn der Benutzer was einstellen will, dann wären hier z.B. flavour ein wunderbarer Mechanismus dafür.

Oder habe ich da etwas entscheidendes übersehen was gegen den Ansaz: "Der User soll selber entscheiden dürfen" spricht?

Da hast nur "übersehen" dass die Designs das halt bisher nicht als Anforderung hatte

Jetzt sollte es nur noch möglichst benutzerfreundlich sein...

Das ist eh klar

Nachtrag: Check am besten schon mal den Code für ein Backdrop bei Text-Seiten ein. Gerne mit einer Erweiterung bei der Demo-Config, die das nutzt. Dann können wir uns besser um die Optimierung der Designs am konkreten Beispiel kümmern.

[swiss]

Hallo Chris

Wäre es denn trotzdem möglich alph einstellbar zu gestalten? Denn je nach backdrop kann man mehr oder wehniger Transparenz verwenden damit sich die Widgets noch gut vom Hintergrund abheben...

Eventuell könnte man das ja so lösen...

Das Design legt fest, ob alpha verwendet werden kann oder nicht und gibt eine Grundtransparenz (falls vorhanden) vor.

In der Config kann alpha wenn in der CSS vorhanden mit einem eigenen Wert übersteuert werden. Also quasi ein find&replace für alpha zur Laufzeit, wenn ein backdrop auf der aktuellen Page verwendet wird.

Damit wären doch die Anforderungen erfüllt oder?

EDIT: Ich sehe nur gerade ein Problem... find&replace wird nicht so einfach da alpha keine eigenständig "veriable" ist sondern bei linear-gradient ein optionaler parameter darstellt...

Zum einchecken meiner Anpassungen... Ich werde es nochmals versuchen aber das doofe Sicherheitsupdate von SF hat dafür gesorgt dass ich seit dem keine Verbindung mit RW auf das Repo mehr herstellen kann -.-

[Chris M.]

Wäre es denn trotzdem möglich alph einstellbar zu gestalten?

Nein, denn

EDIT: Ich sehe nur gerade ein Problem... find&replace wird nicht so einfach da alpha keine eigenständig "veriable" ist sondern bei linear-gradient ein optionaler parameter darstellt...

Und wenn das Design sogar ein Hintergrund-Bildchen bei jedem Widget verwendet (z.B. um eine schicke Reflektion darzustellen) dann ist's noch übler.

Hier beißt uns, dass es kein globalAlpha gibt, das mit dem lokalen einfach aufmultipliziert wird - wie z.B. bei'm HTML Canvas Element...

Denn je nach backdrop kann man mehr oder wehniger Transparenz verwenden damit sich die Widgets noch gut vom Hintergrund abheben...

In der heilen Welt wäre das sicher optimal.
In der praktischen vermute ich, dass es reichen sollte auf zwei verschiedene Arten von Backdrops sich einzustellen - auf überwiegend dunkle und auf überwiegend helle.
Vermutlich reicht es sogar oft aus, überhaupt nur zwischen Mit und Ohne Backdrop zu unterscheiden.
Ungetestet: ich glaube bei Pure ist's sogar vollkommen egal, das geht hoffentlich sofort...

Eventuell könnte man das ja so lösen...

Das Design legt fest, ob alpha verwendet werden kann oder nicht und gibt eine Grundtransparenz (falls vorhanden) vor.

In der Config kann alpha wenn in der CSS vorhanden mit einem eigenen Wert übersteuert werden. Also quasi ein find&replace für alpha zur Laufzeit, wenn ein backdrop auf der aktuellen Page verwendet wird.

Damit wären doch die Anforderungen erfüllt oder?

Wie Du schon gesehen hast: Find&Replace geht nicht.

Aber es sollte gehen, dass es ein (oder gar mehreren) Flavour für Transparent gibt.

[swiss]

Flavour zum einstellen der Transparenz höhrt sich noch einer guten Lösung an. Somit kann in der CSS auf das Design Rücksicht genommen werden und dem User trotzdem ohne CSS "gewürde" die möglichkeit gegeben werden direkt im Editor im gewissen Rahmen die Transparenz an sein Hintergrund anzupassen

EDIT: Nur... Wie kann man denn z.B. potassium und transparenz verwenden? 2 Flavours auf 1 Page angewendet geht ja auch nicht... oder?

[Chris M.]

EDIT: Nur... Wie kann man denn z.B. potassium und transparenz verwenden? 2 Flavours auf 1 Page angewendet geht ja auch nicht... oder?

Man muss die Zahl der vorhandenen Falvours verdoppeln, d.h. es gäbe dann "potassium" und "potassium_transparent" oder so.

[Ziegelstein]

Hallo, krame das hier raus weil ich eben erst angefangen habe mit 2D Seiten zu spielen.
Gibt es hier zum Thema Transparenz bereits was neues (Schalter zu X Prozent durchsichtig machen etc..?)

Muss das noch selber über CSS eingestellt werden ? --wie geht denn das?
oder ist das als Feature schon im neuesten release integriert?

schönen Restsonntag!!

[Chris M.]

Nein, hier dürfte zumindest im offiziellen Code nicht mehr weiter gemacht worden sein. D.h. Du müsstest über die Custom CSS selber Werte einstellen bzw. die des Designs übersteuern.