Author Topic: Diskussion: Finding Standards: Templates und Module CSS  (Read 4022 times)

Offline Yetiie

  • Posts: 778
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #25 on: April 28, 2015, 06:56:44 PM »
Quote
Da ist viel Heuhaufen um die Nadeln herum

In der Tat :-) Aber die Nadeln hattest du ja vorher schon erhalten ... und nach dem Heuhaufen gefragt *grins



Und da Du Dich mit dem CKE beschäftigst:

Da kannst Du einiges machen und über die Config-Datei im Template ausliefern. Beispiel wäre bei dem Auswahlfeld Schriften nur die Schriften (normal, gross, klein) anzubieten, die auch in der CSS per Klasse definiert sind. (es weden dann auch genau die Klassen aus DEINEM CSS zugewiesen und nicht die PX-Werte der Standardeinstellung .) Oder bei den Format-Tags nicht jede Überschrift sondern nur die anzubieten, die Du in der CSS vorgesehen hast (also z.B. nur h1/2) oder auch andere Tags dort anzubieten ...

Das alles geht in der
wb_ckconfig.js
die wie die editor.styles.js über das Template installiert werden kann.


Das Problem dabei ist, dass das Editor-Modul den Zugriff auf die JS-Einstellungen per PHP blockt bzw. überschreibt. Die müssen dort erst frei 'gehackt' werden. Das sind aber nur zwei oder drei Änderungen, die bei mir inzwischen Standardmäßig je Projekt umgesetzt werden.

Ist also leicht getan.


Anhängende ZIP:

Für den Fall, das dich oder jemand anders so was interessiert hänge ich Dir mal eine ZIP mit zwei Dateien an das Posting dran:

>>>
Eine kurze eigene Beschreibung (nicht mehr ganz aktuell aber noch immer hilfreich wenn man nach den Code-Inhalten und nicht nach den Zeilen sucht) um den Zugriff auf die die JS-Einstellungen wieder herzustellen (also die Änderungen in der PHP-Modul-Datei)

>>>
Eine Beispiel-Config-JS, wo die verschiedenen Einstellungen für die Auswahlfelder und noch ein paar mehr realisiert wurden und sehr gut kommentiert sind, dass du das auch selbst hin bekommst.

Damit und mit er editor.style.js (die Du ja wahrschinlich selbst im Griff hast) kannst Du ein richtig neues WB-Gefühl beim Redakteur erzuegen einfach in dem die Usability des Editors auf das Projekt abgestimmt wird und der Zugriff auf die Formatierungen intuitiv erfolgt.






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

Ich hatte übrigens in den letzten Jahren mehrfach vorgeschlagen, den vollständigen Zugriff auf die JS-Datei im Modul zu gewährleisten, aber das ist nicht aufgenommen worden und es kam auch keine Rückmeldung. Naja, das so was nicht aufgenommen wird muss der Modul-author entscheiden, der dafür sicher gute Gründe hat ... es ist zumindest für mich persönlich nur nicht nachvollziehbar, warum auf Anregungen aus der Community (und da meine ich noch nicht mal meine Vorschläge) keine oder so gut wie keine Reaktion auf solche Vorschläge kommen. Es wäre wünschenswert, wenn sich dieses ändern würde.







Offline jacobi22

  • Posts: 5141
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #26 on: April 28, 2015, 07:10:45 PM »
nur an Anregung.... man könnte ohne Probleme das AdminTool wysiwyg_admin ausbauen, das ja einige dieser Einstellungen dynamisch macht (skin, menu, width & height)
Etwas ist nur unmöglich, wenn man glaubt, dass es das ist!

Offline Yetiie

  • Posts: 778
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #27 on: April 28, 2015, 07:37:13 PM »
@jacobi

Ich weiß nicht, ob das ein Lösung ist. Meine letzte (schon sehr!!! alte Information) hier ist, dass das ein damaliger Versuch war der experimentell galt und nicht fortgeführt werden sollte. JA, das kann sich geändert haben und irgendwo tief versteckt in den Zeilen dieses Forums zu finden sein ... naja, auch die Dokumentation könnte da ein gutes Stück besser sein. Eine solche Informatin wäre dann auch gut, bei dieser Gelenheit zu wiederholen bzw. den Stadn kalr zu stellen, Niemand kann alsses wissen. Viele sind aber neugierig.


Zum anderen aber:

Das Modul CKEditor hat doch genau das vorgemacht, was so super toll ist: Template-First-Technologie. Sollte der wysewyg_admin nicht experimentell geblieben sein stellt sich mir die Frage, warum dann genau diese Technik für TEILE der config.js (also einzelne Configurationen) außer Kraft gesetzt worden ist. Es wäre doch sicher machbar, wenn man einer Einstellung der jonfig.js aus dem Modulordner Vorrang vor nicht getroffenen in einem nicht instllierten wysiwyg_admin einräumt. Das erschließt sich mir wirklich nicht, zumahl auch nirgends geschrieben steht, dass zum Betrieb des CKEs der wysywig_admin erforderlich ist.

Und Last but not least:

In dem Besipiel das ich angesprochen habe werden auch Einstellungen geblockt, die im wysywig_admin sehr wahrscheinlich nicht eingestellt werden können wie die Konfiguration der Pull-Down-Felder. (Würde mich wundern, aber korrigieren wenn das falsch ist und im wysiwyg_admin eingestellt erden kann, welche Tags dort im Pull-Down-Feld angeboten werden.)

Dies aber macht einen großen Teil dessen aus, was in dem von mir angehängten Beispiel demonstriert wird und ist daher voneinem wysiwyg_admin_modul vollkommen unabhängig.


Noch mal:

Das Modul CKE hat etwas fantastisches vorgemacht: nämlich Modulconfiguration und Individualisierung via Template (= Template-First-Technologie, der Webdesigner definiert in seinem Template die Einstellung von WB für das Template). EINFACH GENIAL! Ist es wirklich nicht möglich diese tolle Arbeit trotz mehrfach wiederholter Vorschläge nicht zu Ende zu führen? Selbstverständlich aber ist und muss dies dem Ermessen des Modulautors belassen werden. Darum tauschen wir uns ja auch hier aus, wie man den Ansatz der guten Arbeit selbstständig und praktisch mit kleinem Aufwand verbesssern und zu Ende führen kann.


Offline Stefek

  • Posts: 6177
  • Gender: Male
  • ("ړ)
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #28 on: April 28, 2015, 08:18:16 PM »
Das Modul CKE hat etwas fantastisches vorgemacht: nämlich Modulconfiguration und Individualisierung via Template (= Template-First-Technologie, der Webdesigner definiert in seinem Template die Einstellung von WB für das Template). EINFACH GENIAL! Ist es wirklich nicht möglich diese tolle Arbeit trotz mehrfach wiederholter Vorschläge nicht zu Ende zu führen? Selbstverständlich aber ist und muss dies dem Ermessen des Modulautors belassen werden. Darum tauschen wir uns ja auch hier aus, wie man den Ansatz der guten Arbeit selbstständig und praktisch mit kleinem Aufwand verbesssern und zu Ende führen kann.

Wie? Wer Modul Author?
CKE wird wo anders hergestellt. Was wir machen ist eine Implementierung des Editors.
Und ich habe es schon vor Jahren vorgeschlagen.

Ich bin sogar noch einen Schritt weiter gegangen.
In seinem Template konnte der Author verschiedene CKE Einstellungen und Drop-Downs definieren, je nachdem in welchem Block sich die WYSIWYG Section befindet (es ist ja klar z.B. dass man in einem kleinen Seiten-Block nicht mit H1 hantiert).

Das war dann aber noch nicht das Ende der Fahnenstange. ;-)
Weil, da man den CKE auch woanders verwendet als nur im WYSIWYG Modul, habe ich noch an einer Brücke gearbeitet, wo man z.B. in das Modul NEWS (wo man den Editor), eine weitere JS Datei bzw. Dateien mit Definition des CKE Verhaltens reinlegen konnte und der CKE hat sich dann diese geschnappt und die "Bar" und alles andere so dargestellt, wie in den Dateien definiert.

Wozu soviel Aufwand?
Ja, es ist Aufwand und der Kunde weiß es nicht zu schätzen (weil er den Aufwand nicht sieht). Aber der Kunde fühlt sich besser wenn alles funzt und wenn er Dich nicht anrufen muss, warum seine Eingaben so komisch aussehen "vorne auf der Seite".

Und es gibt auch Szenarien, wo man nicht will, dass der Kunde bestimmte Headlines etc. einträgt. Oder Bilder einfügt.

Von der Implementierung her war das nicht weiter schwer.
Die Prototypen müßten igendwo noch im Forum rumliegen (aber frag mich nicht wo - das war zu 'ner Zeit wo ich mich noch nicht rasieren musste).

Und die Implementierung war so vorgesehen, dass wenn nichts im Template vogefunden wurde, wurde eben der Standard aus dem CKE genommen.

Ansonsten gab es in den Templates mit mehreren Blöcken sowas wie:
editor.css
editor2.css
editor3.css
und
*.js
*2.js

usw.

im NEWS Modul einfach
editor.css
editor_small.css
und die JSe

(all das könnte man sich neu überlegen, wenn man wollte)

Ich glaube damals hat kaum einer verstanden worüber ich rede  :wink:
Oder den Bedarf nicht gesehen oder gehabt.

Gruß,
Christian
"Gemeinsam schafft man mehr."

gemeinsam
1. mehreren Personen oder Dingen in gleicher Weise gehörend, eigen
2. in Gemeinschaft [unternommen, zu bewältigen]; zusammen, miteinander
#Duden

Offline easyuser

  • Posts: 832
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #29 on: April 28, 2015, 08:30:35 PM »
Hat eigentlich der CKEditor einen brauchbaren Syntax Highligther für PHP / CSS / HTML?
Dann kann man endlich den grottigen editarea aus WB werfen (zusammen mit yui und jscalendar, ja ich weiß....).

Oder es müsste halt z.B. Ace http://ace.c9.io/ herhalten.

Hinweis:
Der CKEditor hat extrem viele Einstellmöglichkeit en. Ich würde mich sehr wunder, wenn es nicht möglich ist, per se auf HTML zu verzichten oder das einzustellen: http://docs.ckeditor.com/#!/guide/dev_removeformat

Offline Stefek

  • Posts: 6177
  • Gender: Male
  • ("ړ)
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #30 on: April 28, 2015, 09:11:01 PM »
Jo Michi.
Der sieht gut aus. EditArea ist nicht so gut.

Übrigens, ich würde eine Liste von all den Ideen gerne sehen.
Das Dev-Team sollte wissen, was uns vorschwebt.

Alles in einem Thread: Welche Features Du Dir für WebsiteBaker wünscht.

Und dann ab geht die Post.


"Gemeinsam schafft man mehr."

gemeinsam
1. mehreren Personen oder Dingen in gleicher Weise gehörend, eigen
2. in Gemeinschaft [unternommen, zu bewältigen]; zusammen, miteinander
#Duden

Offline Yetiie

  • Posts: 778
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #31 on: April 28, 2015, 11:22:33 PM »
Quote
Modul Author
Gut gut ... gemeint ist der WB Module Author natürlich.
Der CKE wird natürlich woanders gecodet ... ;-)

Quote
Ich bin sogar noch einen Schritt weiter gegangen.

Ja. Da erinnere ich mich noch gut dran und an den Thread. Also rasiert habe ich mich damals schon .... nur der WB-Flaum
war gerade dabei sich zuvermehren ;-)

Hier wars: http://forum.WebsiteBaker.org/index.php/topic,17981.msg144151.html#msg144151

Ich fand das damals recht beeindruckend. Aber für mich zu aufwendig. Hatte mich daher auf die hier dargsestellten Techniken konzentriert.

Die Technik, den Editor je Block mit verschiedenen Breiten aufrufen zu können würde ich als sinnvoll/interessant empfinden.



Editor Ace

Mit dem habe ich zufällig vorletzte Woche ein wenig rumgespielt. Der scheint mir gut zu sein und wird soweit ich mich erinnere auch von einem aktiven Team (Mozilla) unterstützt und mitentwickelt. Ausführlichere Demo hier: http://ace.c9.io/build/kitchen-sink.html

Mächtiges Tool, viele Möglichkeiten des Syntaxhighlightings .Aber ziemlich nackt und keinerlei (ich weiß nicht ob das hier erforderlich ist) Dateiverwaltung ... aber das einlesen und abspeichern einer Datei war recht unproblematisch. Editoren wurden aber in den letzten beiden Jahren hier mehrere (immer mal wieder einer) empfohlen.


Offline Stefek

  • Posts: 6177
  • Gender: Male
  • ("ړ)
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #32 on: April 28, 2015, 11:40:53 PM »
Hallo Yetiie,

danke.
Genau das wars.

Nach wie vor interessant, vorausgesetzt WB nimmt den CKE als Standard.
Dann könnte man das alles umsetzen.

Mehrere Blöcke -- sicher, das verwenden dann nur "Power-Baker" (oder Designer, die nicht nur schöne, sondern auch praktische Templates anbieten wollen).

Auch Module bedienen --- klar, sieh mal News oder Bakery. Da willst Du vielleicht einfach nur im "Anreißer" grad mal Bold und Italic anbieten, nicht mehr. Der Editor bietet aber alles, also drücken die "Spezialisten" alles was geht.

Das gute an einem einfachen CMS ist, dass es auch "Power-Features" haben kann, ohne dass es was ausmacht, wenn man sie nicht nutzt (weil man sich auf weniger beschränkt).
"Gemeinsam schafft man mehr."

gemeinsam
1. mehreren Personen oder Dingen in gleicher Weise gehörend, eigen
2. in Gemeinschaft [unternommen, zu bewältigen]; zusammen, miteinander
#Duden

Offline Yetiie

  • Posts: 778
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #33 on: April 29, 2015, 08:17:13 AM »
Quote
vorausgesetzt WB nimmt den CKE als Standard

Welchen Standard? Also, bei mir ist der CKE Standard. Oder meinst Du den Standard, das weil das immer schon so gemacht wurde? Aber es gibt ja in Deutschland auch Verwaltungen, die gemäß der Kompetenz ihrer Leitungskräfte immer noch Windows XP einsetzen. Und es gibt auch solche Leitungskräfte, die das durchaus in Ordnung finden und als richtigen Schritt vertreten.

Naja, jeder mag für sich selbst entscheiden, was er aktuell empfindet. Aber lass uns doch mal eine Liste aufstellen, was für (ernsthafte!) Gründe es geben könnte, dass User oder Webdesigner, die WB einsetzen, den FCK noch benutzen. Denn eine Ursache dafür, dass er noch bentutzt wird, muss es ja geben (und jeder muss das auch selbst entscheiden). Und wenn man die Ursachen kennt, kann man ja etwas unternehmen, wenn man mag (jeder für sich selbst natürlich oder für WB, je nachdem für was man verantwortlich zeichnet und ob man die Wichtigkeit der Aktualität von Software versteht/vertritt/als wichtig erachtet oder auch nicht):


Mögliche Gründe, warum ich den FCK Editor benutze:

  • er wurde mir von kompetenten Leuten empfohlen
  • habe ich immer schon benutzt
  • die offizielle Seite, auf der der Hersteller des Editors empfielt, diesen nicht mehr zu benutzen, kenne ich nicht
  • er wurde dem WB-Package beigelegt und ich vertraue den Machern von WB, dass sie in einem CMS aktuelle Software zusammen stellen
  • die Icons in dem Editor finde ich schön (kein Witz, das spielt bei Kaufentscheidungen eine nicht zu unterschätzende Rolle, wei Frauen, die ein Auto kaufen, weil es rot ist, hatte ich tatsächlich gerade im Bekanntenkreis und ist daher wirklich kein Witz! Da wird im Marketing viel drüber nachgedacht.)
  • ich weiß gar nicht, dass es eine Alternative gibt
  • das Suchen nach aktuellen Versionen im Forum ist mir zu aufwendig (ich glaube aber, der Punkt hat sich gebessert und die aktuelle Version oder zumindest fast aktuelle Version wird inzwischen im Downloadbereich bereit gestellt, ein aufrichtiges Dankeschön dafür)
  • ich finde bei A M A S P keine aktuelle Version mehr (Übrigens: [OT] sowohl zu der Situation und wie auf diesen Angriff auf WB von der Leitung hier reagiert wurde und immer noch wird fehlen mir ehrlich gesagt auch nach den Jahren immer noch die Worte. Und ich bekomme als WB-Fan jedesmal den von dem dortigen Seitenersteller intonierten Fußkrebs, wenn ich die Seite sehe und könnte in die Platine beißen, wenn ich sehe, dass von WB nichts aber auch gar nichts entgegen gestellt wird. [/OT])
  • Mir ist wurscht, ob die von mir verwendete Software aktuell ist, mache ja eh nur kleine Seiten die sich mehr im Hobby-oder Vereins-Bereich bewegen, da ist mir das nicht wichtig
  • wieso: er werkelt doch immer noch gut, was willst Du also eigentlich ...


Also: Gründe gesucht. Wer kennt weitere ernsthafte(!) Gründe, warum der FCK immer noch von Usern hier benutzt wird?

Hinweis: Unsachliche Gründe wie 'ich bin Fußballfan', 'Antiquitäten sammeln ist mein Hobby', 'wurde mir schon von meiner Oma empfohlen' sind NICHT zugelassen und sollten daher bitte unterbleiben oder zumindest als Ironie, Witz, oder 'nicht ernst gemeint' gekennzeichnet werden.



Ganz ehrlich. Ich bin ehrlich und aufrichtig froh, dass sich hier jemand gefunden hat, den CKE regelmäßig zu aktualisieren. In welcher Form letztendlich auch immer. Das tut dem Projekt gut. Habe ich schon mehrfach zum Ausdruck gebracht: DANKE DAFÜR!!!!




Quote
Dann könnte man das alles umsetzen.

Sei vorsichtig damit. Das könnte gegen die Geschäftordnung verstoßen oder gegen die intonierte Nutzung der hier bereit gestellten Software. Oder Du könntest in Verdacht gerade mit aktuellen Lösungen WB verbessern zu wollen. Bei mir regt sich mehr und mehr die Vermutung (sicher weiß man so was ja nie), so was kommt hier bei einigen nicht gut an. *grins - DAS ist natürlich NICHT ganz ernst gemeint - grins*

fischstäbchenbrenner

  • Guest
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #34 on: April 29, 2015, 10:29:55 AM »
@TOPIC...

Wie soll die empfohlene CSS/JS-Reihenfolge beim Laden der Seite sein?
Ich bevorzuge:

register_frontend_modfiles('css'); //Hier also die ganzen Modul-CSS, als erstes
register_frontend_m odfiles('jquery');
register_frontend_m odfiles('js');

Diverse Plugin.css //hier auch bootstrap.css wenn gewünscht

editor.css //Schriften, Farben, styling der Tags (h1-h6, a, li, table, input, submit...)

template.css //Zuletzt: Die großen Blöcke, das Menü, aber auch: Abweichungen/Ergänzungen zu den Modul frontend.css, Media Querys

--Footer:
Diverse PlugIn.js, - sofern das funktioniert, sonst in den <head>

Die frontend.css der Module rühre ich NIE an. Das kommt alles in template.css rein.

Die editor css nehme ich nicht nur für den Editor, sondern lade die auch gleich mit rein. Ich versuche immer mehr, möglichst ALLE Farben in der editor.css anzugeben, wenn geht alle auf einen Haufen.

Offline Stefek

  • Posts: 6177
  • Gender: Male
  • ("ړ)
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #35 on: April 29, 2015, 10:55:50 AM »
Also: Gründe gesucht. Wer kennt weitere ernsthafte(!) Gründe, warum der FCK immer noch von Usern hier benutzt wird?
Das ist doch einfach.
Die meisten Leute geben sich mit dem zufrieden, was im Paket drin ist.

Wobei es auch Ausnahmen geben kann. Chio meinte irgendwie, dass er den FCK bevozugt  -- wenn ich es richtig verstanden habe --  weil er technisch gesehen bestimmte Sachen besser macht als der CKE.
(Es kann sein, dass es eine Einstellung im CKE gibt, die standardmäßig aktiviert ist und ruft dieses Verhalten eben hervor.)

Was ich also meinte, als ich schrieb:
Nach wie vor interessant, vorausgesetzt WB nimmt den CKE als Standard.
Dann könnte man das alles umsetzen.

Dass der CKE als Standard-Editor im Paket ausgeliefert wird.
Dann kann man die Sachen umsetzen, den CKE aufschrauben und dann bei nächster Gelegenheit diese Implementierungen ins WB-Paket  einbinden.

(Aber das geht am Usprungsthread echt vorbei jetzt -- bei bedarf öffne einen neuen Thread.)
"Gemeinsam schafft man mehr."

gemeinsam
1. mehreren Personen oder Dingen in gleicher Weise gehörend, eigen
2. in Gemeinschaft [unternommen, zu bewältigen]; zusammen, miteinander
#Duden

Offline Yetiie

  • Posts: 778
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #36 on: April 29, 2015, 11:06:03 AM »
... [/OT]

Du. einfach nur als Anregung und Gedankengang:

Ich weiß zwar, dass register_frontend_m odfiles() hier als Standard betrachtet wird. Aber warum nicht darauf verzichten und die benötigten CSS/JS-Dateien per Hand einladen.

Ich denke, das gibt mehr Möglichkeiten der Steuerung z.B. welche jQuery-Version zu verwenden ist. Einige neuere JQs, die in einem Template verwendet werden laufen ggf. nicht mehr (ich glaube?) aktuell angebotenen Version 1.7... oder anders herum: Bei einem WB-Update würde eine mögliche neue JQuery Version ältere JQs im Template, die dann bei dem Sprung ggf. nicht mehr laufen würden, nicht berühren.

Auch die CSS-Dateien der Module gehören für mich(!) ins Template. Denn dort definiere ich zum Beispiel das aussehen der Formulare an einem Platz und die paar Struktur-Klassen noch aufzunehmen ist da dann ein Klacks.

Außerdem müssen die möglichen Module ja in der Regel sowieso vom Template optisch gestaltet werden ... heißt: viele Module machen wenig Sinn, wenn ihre Verwendung nicht im CSS (also im Template) vorher vorgesehen wurde.

Ich meine: es ging ja um Einfachheit. Also: ich finde es einfacher, dass sich ein User nicht mehr darum kümmern muss im Backend Anpassungen vorzunehmen sobald das Template installiert ist, als das er hier das prüfen muss, dort die Einstellung vornehmen muss etc.

Und Last but Not Least erhöht das Zusammenfassen der CSS/JS-Dateien die Ladezeiten.

Der Vorschlag läuft daher darauf hinaus komplett auf register_frontend_m odfiles() zu verzichten.

Bitte das aber nur als Idee/Anregung verstehen. Ich weiß (und das ist auch richtig so), dass da jeder seine eigene Methode hat und bevorzugt.



Zur Reihenfolge:
Was ich gelernt habe: CSS muss/sollte bereit stehen wenn JQuery geladen wird.
Aus dieser Warte wäre Deine Reihenfolge die Richtige.

fischstäbchenbrenner

  • Guest
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #37 on: April 29, 2015, 11:08:40 AM »
Ich würde gerne mit "Finding Standards" in spätestens 2 Wochen zu einem Ergebnis kommen.

So gesehen ist wurscht, ob der CKE in das WB-Paket kommt oder nicht, weil das ohnehin erst in 2 Jahren entschieden wird ;-)

UND:
Es geht um Standards, und nicht darum, was dann jeder für sich draus macht. Es verkompliziert die Sache enorm, wenn man schon gleich mit Feinheiten daherkommt.

fischstäbchenbrenner

  • Guest
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #38 on: April 29, 2015, 11:48:05 AM »
Sollte man den Modulentwickler - speziell bei Modulen mit Formularfeldern im Frontend - sagen:
Gehe minimal davon aus, dass bootstrap.css das einzige css ist, das noch geladen wird.
Verwende die empfohlenen Bootstrap-Container und Klassen - und schau ob das ordentlich aussieht.
Um den Rest kümmert sich das Template.css


Eine Liste der empfohlenen Klassen muss man dann eben erstellen.

Ein einfach gangbarer Web wäre, ein wb_modernizer.css anzubieten, das zusätzlich (statt bootstrap.css) reingehängt wird und alle diese Klassen definiert.
Das könnte auch von einem CDN geladen werden und laufend ergänzt werden.


Offline Yetiie

  • Posts: 778
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #39 on: April 29, 2015, 11:50:05 AM »
Noch was ist mir auf-/eingefallen und auch nur als Anregung:


editor.css

Ich lade immer die komplette CSS in den Editor (@import). Hört sich erst mal nach Chaos an, ist es aber nicht und funktioniert tatsächlich.

Auf diese Weise werden nicht nur die Schriften/Überchriften oder was sonst separat dort in der editor.css notiert ist richtig angezeigt. Sondern es erscheinen auch die kompletten Elemente wie z.B. Boxen mit Box-Header/-Footer, Linkboxen, Spalten oder Lisitems automatisch richtig, - was manchmal je nach Element auch ein größeres CSS-Gerüst sein kann.

Das Einzige was in der editor.css zusätzlich definiert werden muss sind (je nach SCSS-Aufbau) tatsächlich die Links, die sonst manchmal nicht funktionierten.

Vorteil: CSS alles an einem Ort und keine (oder nur minimale) Doppelnotationen in zwei verschiedenen Dateien.


---------------------
(Auch hier gilt: just Anregung und Gedankenaustausch. Bitte immer nur das herauspicken, was passt.)



Offline Yetiie

  • Posts: 778
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #40 on: April 29, 2015, 11:51:10 AM »
WB-CDN ... hört isch spannend an :-)

Offline Stefek

  • Posts: 6177
  • Gender: Male
  • ("ړ)
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #41 on: April 29, 2015, 11:55:52 AM »
Ich mach das anders.

In die editor.css ziehe ich @import eine Datei "global-styles.css" rein.

In der editor.css habe ich nur einige spezielle Sachen, die den Editor betreffen und die box stylen.

Gabs mal ein Tutorial zu.
Wurde aber nicht beachtet.  :wink:

Aber die editor.css hat z.B. definiert den body selector.
Aber auf eine weise, wie ich im FE den <div class="content"> definiert habe (Farbe, Breite)

So sieht der User im Backend das, was er später im Frontend sieht.

Und diese editor.css, die den body umdefiniert, kann ich NICHT ins FE laden. :-D

Stefek
"Gemeinsam schafft man mehr."

gemeinsam
1. mehreren Personen oder Dingen in gleicher Weise gehörend, eigen
2. in Gemeinschaft [unternommen, zu bewältigen]; zusammen, miteinander
#Duden

fischstäbchenbrenner

  • Guest
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #42 on: April 29, 2015, 01:27:14 PM »
editor.css

Ich lade immer die komplette CSS in den Editor (@import). Hört sich erst mal nach Chaos an, ist es aber nicht und funktioniert tatsächlich.

Auf diese Weise werden nicht nur die Schriften/Überchriften oder was sonst separat dort in der editor.css notiert ist richtig angezeigt. Sondern es erscheinen auch die kompletten Elemente wie z.B. Boxen mit Box-Header/-Footer, Linkboxen, Spalten oder Lisitems automatisch richtig, - was manchmal je nach Element auch ein größeres CSS-Gerüst sein kann.

Das Einzige was in der editor.css zusätzlich definiert werden muss sind (je nach SCSS-Aufbau) tatsächlich die Links, die sonst manchmal nicht funktionierten.

Vorteil: CSS alles an einem Ort und keine (oder nur minimale) Doppelnotationen in zwei verschiedenen Dateien.
Da haut es aber den FCK ziemlich auf die Nase, und wohl auch andere Editoren.
Das geht unter kontrollierten Bedingungen, aber so allgemein eher nicht.

In die editor.css ziehe ich @import eine Datei "global-styles.css" rein.

In der editor.css habe ich nur einige spezielle Sachen, die den Editor betreffen und die box stylen.

...

Aber die editor.css hat z.B. definiert den body selector.
Aber auf eine weise, wie ich im FE den <div class="content"> definiert habe (Farbe, Breite)

So sieht der User im Backend das, was er später im Frontend sieht.
Und diese editor.css, die den body umdefiniert, kann ich NICHT ins FE laden. :-D

Stefek

Ich mach das geringfügig anders:
Es gibt ja nur wenig, was sich in editor und End-Ansicht unterscheidet.
Ich hab zb:
editor.css body {width:500px; color:#000;}
template.css body {width:100%; color:#fff; background:...} /*bei dunklen Templates)

Da die editor.css IMMER nach der editor css geladen wird, kann ich die paar Unterschiede überschreiben.

An <div>-Blöcke im Editor lasse ich die User gar nicht ran - da kommt nur Murks raus ;-)
In den (seltenen) Fällen, wo divs nötig sind, richte ich ihnen das per Members oder einem anderen Modul ein. Das ist ohnehin immer individuell zu regeln.

Bei Responsiven Templates ist das ohnehin alles viel zu schwierig für User. Da mache ich viel mit Members - ohne Editor, nur PlainText.

@import: Das einzige, was bei mir so reinkommt, sind die Web-Fonts. In die editor.css. Die sind dann auch gleich dort wo sie definiert werden.

fischstäbchenbrenner

  • Guest
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #43 on: April 29, 2015, 01:39:53 PM »
FEHLER oben: die template.css wird immer NACH der editor.css geladen.


Es gab ja schon mal einen "Standard" für die Handhabung der styles und der editor.css.
An sich die Lade-Reihenfolge wie oben (oder?)

Die editor.css sollte da aber NUR für die Ansicht im Editor verwendet werden und NICHT im Template dazugeladen werden.
Das hat schon Sinn, weil so eine Datei weniger geladen werden muss. Idealerweise (wenn keine Module mit eigenem frontend.css) habe ich also nur 1 einzige css Datei zu laden.

Der Nachteil ist aber, dass man doppelt Arbeit hat, und daher bei vielen freien Templates gar keine editor.css dabei war. Die Designer wollten einfach die Doppelgleisigkeit nicht haben.

Ich gehe mehr und mehr dazu über, in die editor.css ALLES reinzutun, was ein Template-ANwender wahrscheilich ändern will. Also vor allem mal die Farben (das ist immer das erste). Auch die im Menü usw.

Ich habe also einen Block, in dem ich alle Elemente mit gleichen Hintergrundfarben zusammenfasse, einen mit allen Colors, Borders..

Das geht nicht immer gut, leider. Aber bei einfacheren Designs gehts.
« Last Edit: April 29, 2015, 01:53:29 PM by fischstäbchenbrenner »

fischstäbchenbrenner

  • Guest
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #44 on: April 29, 2015, 02:15:52 PM »
Um das mal zusammenzufassen:
CSS-Reihenfolge und Template-CSS Vorgaben kann man eigentlich den alten Standard übernehmen und um ein paar "Best Practise" Tips für heutige Zustände ergänzen.

Und (auch wenn das jetzt hart klingt): Dort wo es mehrere annähernd gleichwertige Möglichkeiten gibt, wird man die empfehlen, die bereits am häufigsten verwendet wird. Und das ist eben editor.css vor template.css reinladen, in letzterer ggf die Besonderheiten der editor.css überschreiben.
Webfonts in die editor.css per @import rein, dann hat man sie auch im Editor und muss die Fonts ggf nur einmal ändern. 


Oben schon mal angesprochen:

die frontend.css der Module

Da ist der "alte" Standard: Modulspezifische Klassennamen (beginnend mit dem Modulnamen) und diese alle in der frontend.css definieren. Das hat sich als unbrauchbar erwiesen.
Etwas wie (background-)color oder width in px hat in der frontend.css eines Modul nichts zu suchen.
Aber gerade die spezifischen Klassen scheinen dazu geführt zu haben, dass Modul-Entwickler schon gleich mal fest ins Design reingreifen.

In Wahrheit muss man sagen: Ein Form-Nodul sollte eigentlich GAR kein frontend.css brauchen, weil es Sache des Templates ist, wie ein input  usw aussieht.
OK, es gibt Elemente, die besonderes Styling brauchen, aber auch da sollte wenn möglich auf Standards zurückgegriffen werden. Gerade bei Form-Elementen kann das gut und gerne Bootstrap sein, warum nicht.

Offline Stefek

  • Posts: 6177
  • Gender: Male
  • ("ړ)
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #45 on: April 29, 2015, 02:31:32 PM »
In Wahrheit muss man sagen: Ein Form-Nodul sollte eigentlich GAR kein frontend.css brauchen, weil es Sache des Templates ist, wie ein input  usw aussieht.
OK, es gibt Elemente, die besonderes Styling brauchen, aber auch da sollte wenn möglich auf Standards zurückgegriffen werden. Gerade bei Form-Elementen kann das gut und gerne Bootstrap sein, warum nicht.

Ja. Kann. Dann wieder: wer wirds verwenden?

Nach einer Zeit (bevor der nächste WB released wird ;-)) gibts wieder neue "Frameworks" die IN sind.

Wenn Du einen speziellen Einsatzbereich hast, wenn Du auf etwas Spezielles hinarbeitest -- wie z.B. alle DEINE Templates auf EINEN NENNER zu bringen --  dann macht es Sinn.
Ansonsten denke ich persönlich, dass man in dieser Beziehung nichts "erfinden" oder "festlegen" kann, das alle glücklich macht.

Ich denke, das sollte man größtenteils den Designern überlassen.

Die IDEE die ich zuvor angesprochen habe, WB mit einem Default-Content, auf verschiedenen Seiten mit unterschiedlichen Modulen verteilt, anzubieten wäre für sowas ein NENNER.

Sicher, das macht keinen glücklich jetzt, weil es das nicht gibt.

Aber genau so wenig gibt es jetzt im Form-Modul Bootstrap Selectoren in den Einstellungen des Moduls  :wink:

Stefek
"Gemeinsam schafft man mehr."

gemeinsam
1. mehreren Personen oder Dingen in gleicher Weise gehörend, eigen
2. in Gemeinschaft [unternommen, zu bewältigen]; zusammen, miteinander
#Duden

fischstäbchenbrenner

  • Guest
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #46 on: April 29, 2015, 02:43:06 PM »
Bei Modul-Klassen und CSS sollte man sagen:
Jeder Container muss einzeln ansprechbar sein. Oft (wenn ein Zugriff darauf einfach möglich sein  soll) mit ID
Gleichartiges soll gleichartig ansprechbar sein.

als zb:
Code: [Select]
....<div id="dasmodul-blockID" class="form-group dasmodul-block">
<label class="dasmodul-label-typ">
<input  id="dasmodul-inputID" class="form-control dasmodul-input-typ">
</div>....

form-group und form-control kommt aus boostrap und das kann man auch für WB übernehmen.
id="dasmodul-blockID" brauche ich als  Designer der Website, um das Element zb anders zu positionieren, oder ihm eine spezielle Hintergrundfarbe zu geben.  
Der Modul-Autor definiert vielleicht class="dasmodul-block".

Manchmal wird es sich nicht vermeiden lassen, dass Farben - zumindest Grautöne - angegeben werden.
Ich würde eine class="isDark", gleich im Wrapper oder am Contentblock eines Templates definieren, damit ein Modul CSS weiß, dass es auf dunklem Grund ist und daher helle Elemente verwenden soll. Das Gegenteil (heller Grund) ist Default.

instantflorian

  • Guest
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #47 on: April 30, 2015, 07:37:35 AM »
Hallo,

die in diesem Thread angesprochenen Themen wären sicherlich auch für internationale Nutzer bzw. das noch zu bildende Module Team interessant. Vielleicht könnte die Diskussion versachlicht und unter Development 2.8.x auf englisch neu aufgenommen werden?

Kurz noch 2c von mir:

Der Ansatz einer Standardisierung von Template- und Modul-CSS ist grundsätzlich zu begrüßen. Allerdings weiß ich nicht, ob man sich der allgemeinen Bootstraphörigkeit anschließen sollte.

Schaut man sich frei verfügbare oder auch kommerzielle Templates (nicht speziell WB, sondern überhaupt, vgl. z.B. templatemo.com) an, beruhen gerade ältere, aber immer noch brauchbare Templates nicht auf Bootstrap; oft bringen Templates auch bereits ihre eigenen, BT-unabhängigen Styles für Formulare usw. mit.

Ich persönlich vermeide immer noch die Verwendung von Bootstrap, es ist mir zu komplex. Würde jetzt die BT-Auszeichungssprache zum Quasi-Standard, schliche sich BT zur Hintertür herein. Hm.

Den Ansatz, das Module überhaupt kein eigenes Styling mehr mitbringen sollten und alles aus der Template-CSS kommt, finde ich richtig, und handhabe das auch oft genug schon so, nicht zuletzt weil mir sonst jedes Modulupdate die Styles in der frontend.css des Moduls zerschießt. Praktischerweise kann das ja jeder halten, wie es ihm passt: kein register_frontend_m odfiles('css'); im Template - kein frontend.css.

Ansonsten sollte bei der template.css/editor.css/frontend.css-Geschichte noch berücksichtigt werden, dass es nicht mehr state of the art ist, drölfzig verschiedene CSS- und Javascript- Dateien zu laden, sondern zwecks Performanceoptimier ung die Anzahl der zu ladenden Dateien so klein wie möglich zu halten. D.h. es sollte nicht Ziel sein, noch mehr Dateien im Frontend zu laden, sondern weniger.

BR
-Florian.

fischstäbchenbrenner

  • Guest
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #48 on: April 30, 2015, 10:40:31 AM »
Hallo Florian,

Ich bin AUCH kein Freund von Bootstrap - aber Bootstrap existiert nun mal (vor allem als Marketing-Zugpferd)
Das muss man zur Kenntnis nehmen.

Man muss nicht justament quertreiben - man kann ja beides haben. Für NICHT-Bootstrap Templates sind die entsprechenden Klassen eben unformatiert, und es ist ja egal wie sie heißen.


Dass es nicht gut ist, 20 Dateien zu laden, weiß jeder - aber es ist einfach und es funktioniert bereits jetzt.
Ein Einsteiger kann einfach mal an Modulen reinladen, soviel er will.
Später kann man immer noch zusammenfassen. Manuell oder automatisiert - aber auch dann braucht man etwas, was man zusammenfassen kann.

WB soll zunächst einmal Spass machen und zu einem flotten Ergebnis führen. Mit Details kann man sich besser spielen, wenn man schon mal was funktionierendes hat.
 

Offline Stefek

  • Posts: 6177
  • Gender: Male
  • ("ړ)
Re: Diskussion: Finding Standards: Templates und Module CSS
« Reply #49 on: April 30, 2015, 05:44:57 PM »
Chio,

ich gebe Dir recht.

Die Sachen könnten so in den Standard-Layouts benannt werden. Mit Bootstap Selectors (Klassen Bezeichnungen).

Bei Modul-Klassen und CSS sollte man sagen:
Jeder Container muss einzeln ansprechbar sein. Oft (wenn ein Zugriff darauf einfach möglich sein  soll) mit ID
Gleichartiges soll gleichartig ansprechbar sein.

als zb:
Code: [Select]
....<div id="dasmodul-blockID" class="form-group dasmodul-block">
<label class="dasmodul-label-typ">
<input  id="dasmodul-inputID" class="form-control dasmodul-input-typ">
</div>....

Ich denke das wurde schon irgendwie in die 2.8.4. eingepflanzt, dass es grundsätzlich geht.
Anstatt den alten Anchor mit Section ID wird die ganze Section in ein DIV mit Selectors jeweils für die Section-ID und Modul-Namen vergeben.

Also etwa so:
<div class="section m_wysiwyg" id="Sec59">

Es fehlt aber ein <div> Container zusätzlich um den Block herum.
Schade das.
So könnte man Frontend Drag'N'Drop der Section Anordnung machen. Auch zwischen (Layout-)Blocks.  :wink:

Gruß,
Stefek
"Gemeinsam schafft man mehr."

gemeinsam
1. mehreren Personen oder Dingen in gleicher Weise gehörend, eigen
2. in Gemeinschaft [unternommen, zu bewältigen]; zusammen, miteinander
#Duden

 

postern-length