Einheitliche Stylesheet definition für Themes

[paulbr]

Hallo

ich melde mich schon wieder mal mit einem Vorschlag 

Macht es nicht Sinn, eine einheitliche CSS Definition als Grundlage für alle
Frontend evtl. auch backend Themen zu erstellen?

Zur Zeit ist es absolut abhängig vom jeweiligen Theme.

Ich denke eine klare definition würde hier ebenso Sinn machen, wie bei den Modulen.

Meine Vorstellung:
 1. css/core/base.css
     css/core/base_iepatch.css
 2. css/screen/template.css
     css/screen/template_iepatch.css
 3. css/screen/content.css
     css/screen/content_iepatch.css

Aufruf:
    css/standard.css   (importiert die o.g. css definitionen)
    css/iepatch.css     (importiert die o.g. css ie patch definitionen) wenn browser ie ist

Dadurch in der clansuite.config.php css = "standard.css" definiert ist, bedarf es hier keine
Anpassung oder Änderung.

Zu Punkt 1)
  hier sollten globale definitionen rein (core welche sich nicht ändern)

Zu Punkt 2)
  hier werden die globalen Blöcke definiert wie:
     - header
     - main
     - footer
     - boxen: widget | notizen | messages  etc.

   das sind semi core definitionen und müssen lediglich farblich an das
   jeweilige themen design angepasst werden.

Zu Punkt 3)
   hier werden die normalen themenspezifische definitionen abgelegt.
   
Im Anhang hab ich mal diese Idee im Ansatz beigelegt, wenn interesse besteht das
einheitlich zu gestalten.

gruss
paul

[Jens-A. Koch]

Hallo Paul,

das is ein guter Vorschlag. Was mir daran gefällt, ist die Aufteilung in Content-Bereich und Layout-Bereich und auch die Aufteilung in einzelne Dateien, die dann über @import zusammengesetzt werden.

Im Moment ist es tatsächlich so, dass man im Theme alle Freiheiten hat - wenn man denn mal die entsprechenden Attribute rausgefunden hat. Zumindest für die Themes "backend/admin" und "frontend/standard" werd ich Deine Struktur einführen. Dann wirkt das wie eine Vorlage, für diejenigen, die neue Themes erstellen wollen.

Gruß Jens

[paulbr]

Der gedanke geht ja dabei in erster Linie in Richtung Templategenerator!

Wenn man einen solchen irgendwann mal realisieren möchte, ist es unumgänglich
eine einheitliche Benennung der css-definitionen zu machen.

Ich würde sogar in diesem Fall einen Schritt weiter gehen und die css importdatei
vorgeben, in der die base.css aus dem core geladen wird, der Rest dann theme intern:
 standard.css
   /* Core einbinden */
   @import url(../../../core/css/core/base.css);

Für die template.css welche die Container definitionen hat, könnte man im Adminbereich
ein Formular erstellen, in dem man z.b. die farben der Container ändern kann.
Mehr wird hier kaum nötig sein.

Für die eigentliche Themenabhängige content.css würde ich einen css editor einbauen,
welche die content.css komplett in einem textfeld lädt.
So kann man hier nach Lust und Laune definitionen ändern/hinzufügen/löschen..was auch immer.
Dieser speichert dann die content.css komplett wieder neu ab.

Wie gesagt, falls mal ein Templategenerator realisiert werden soll  

Anmerkung:
Man könnte sogar prinzipiell auch ohne templategenerator im Adminbereich einen css editor
einbauen, der muss ja nur die aus dem bestehenden backend/frontend im css/screen ordner
abgelegte template.css + content.css zum editieren laden und wieder abspeichern.
So kann man schnell mal ohne FTP zu bemühen bestimmte definitionen zur laufzeit ändern.
Entweder gibt man hier die css-files namentlich fest vor, oder man liest den css/screen ordner
aus und zeigt die files in einer dropdownbox zur auswahl an.

Auch macht es Sinn sich über den namespace der wichtigsten core und template definitionen
gedanken zu machen.

Ich mach mal einen Anfangsvorschlag für einen möglichen Aufbau:

ce = core elemente (basis container)

#cePagePane  (definiert den äusseren rahmen. Ränder oder breiten fixierung der Seite)

   #cePageAera  (der eigentliche Seitencontainer)

      #ceHeader
      #ceTopNav(breadcrumb)

      #ceMain

        #ceCol1(widget left)    #ceCol3(content)    #ceCol2(widget right)

      #end ceMain

      #ceBottomNav(fussnavigation)
      #ceFooter(copyright etc.)

   #end cePageAera
#end cePagePane

Anmerkung:
  Möchte man für ein theme beispielsweise nur den content und widget rechts
  (#ceCol3 und #ceCol2) kann man dies im content.css einfach überschreiben indem man:
     #ceCol1 auf display:none und
     #ceCol3 auf margin-left: 0 setzt
  hierzu bedarf es keine Änderung der basis definition.


cb = core block elemente (block container)

Core Blockdefinitionen z.b. newsblock, artikelblock etc..
 .cbBorder  = Blockrahmen
 .cbHeader = Blocktitel
 .cbBody    = Bodybereich des Containers
 .cbFooter  = Fussbereich des Containers

 .cbCell1 | .cbCell2 | .cbCell3 .... (spaltengestaltung)
 .cbRow1 | .cbRow2  (zeilengestaltung z.b. bei grid)


cm = core message elemente (boxen)

Core Messageblock definitionen z.b. Infos, errors etc.
 .cmInfobox  = z.B. Informationen
 .cmWarning = z.B. Unstimmigkeiten oder Validation
 .cmError      = z.B. System Fehler


Ich denke es ist wichtig eine einheitliche Namensgebung für die wichtigsten definitionen festzulegen,
insbesondere auch für formelemente. Manches wird ja nicht unbedingt im front-/backend template
definiert, sondern auch in  core/viewhelper/  smarty, form und datagrid.
Hier braucht es eine verständliche Struktur damit jeder weiss wo er was ändern muss in den
stylesheets.

Ich bin kein Experte in css, hier sind die Designer aufgerufen Ideen und cross browser lösungen
zusammen zutragen, damit die Clansuite auch in diesem Bereich Flexible, Perfekt und leicht
anpassbar wird.


gruss
paul

[Jens-A. Koch]

Templateeditor erweitern auf CSS-Editing
Ein Templateeditor auf Basis von Codemirror ist ja schon im System. Der funktioniert nach dem Verfahren, den Ordner auszulesen und dann die Files in einer TreeNavigation anzuzeigen. Den könnte man leicht abwandeln, um nach den CSS Files zu suchen und diese formatiert anzuzeigen und abzuspeichern. Das bekommen wir also sehr leicht hin.

Templategenerator
Wie könnte man einen Templategenerator realisieren? An die Definitionen im Model anknüpfen? Oder an die Platzhalterzuweisungen an den View, innerhalb der Action?
Evtl. machen hier auch verschiedene Checkboxen Sinn, um bestimmte Viewhelper gleich mit im Template zu haben (bspw. {modulenavigation}). Bzw. auch eine Liste mit den verfügbaren Platzhaltern im System.
Die Liste mit Platzhaltern macht dann auch im Templateeditor einen Sinn, wenn man nachträglich noch einen bestimmten Platzhalter einfügen möchte.

Die Frage die sich dann stellt, ist ob wir diese Liste manuell pflegen oder automatisch erstellen.
Fürs automatische Erstellen, könnte man entweder preg_matchen oder mit Reflection auf dem PHP Source arbeiten. Ich arbeite ja ohnehin gerade an dem Gettext-Extractor, der dann die PO-Language Files speichert. Den Extractor-Ansatz könnte man auf CSS-Attribute und Templateplatzhalter im allgemeinen ausdehnen - jetzt scanne ich nur auf den Languageplatzhalter {t}.

CSS - Struktur
Also wenn wir den CSS Folder mit dieser Struktur in den Core packen, dann läuft das ja darauf hinaus, dass wir quasi ein CSS-Framework für Clansuite schreiben. Auf dieses wird dann aus dem jeweiligen Theme per import gelinkt. Unter /core/css/blueprint liegt auch noch das Blueprint Framework, dass ist bis jetzt nicht im Einsatz. Die teilen dort ebenfalls in ie, print und screen auf.

[paulbr]

Also wenn wir den CSS Folder mit dieser Struktur in den Core packen, dann läuft das ja darauf hinaus, dass wir quasi ein CSS-Framework für Clansuite schreiben. Auf dieses wird dann aus dem jeweiligen Theme per import gelinkt. Unter /core/css/blueprint liegt auch noch das Blueprint Framework, dass ist bis jetzt nicht im Einsatz. Die teilen dort ebenfalls in ie, print und screen auf.

Ja ich denke man sollte hinsichtlich der flexibilität und der änderbarkeit ein eigenes css framework
basteln.

Externe fertige Frameworks wie Blueprint, yaml oder wie sie alle heissen, haben zum einen den Nachteil
das sie teilweise überladen sind und zum anderen die Namensgebung ist meiner Meinung nach nicht
Userfreundlich gelöst.

Was braucht man für das Framework?
1. eine cross browser core css welche die hauptbestandteile browser sicher anzeigt
2. eine template definition mit den in allen themen gleich zu haltenten blöcken
    und formelementen.
3. eine content definition für den rest

Wobei Punkt 1 nicht Theme relevant daher nicht geändert werden sollte.
         Punkt 2 wegen farb- und fontestaltung änderbar sein sollte.
         Punkt 3 die auf das theme bezogene definitionen je nach designer änderbar sein muss.

Wie könnte man einen Templategenerator realisieren?

Ein Templategenerator könnte als Wysiwig Generator aufgebaut werden,
indem man a la frontpage die elemente an die gewünschte Position ziehen kann.

Die Elemente wie Formularfelder, boxen etc... können ja definiert werden und ersetzen
mit speicherung dann diese durch die existierende für die Renderengine.

Elemente erhalten eine Eigenschaftenbox in der man z.b. Farbe, Font etc. festlegen kann
bzw. in der man die styleklasse eintragen kann, je nachdem wie aufwändig man das machen
möchte.

Der Themenersteller wählt zunächst die Grundform:
 - header + main + footer sind immer vorhanden als basisform
 - er kann nun entscheiden will er 3 spalten im #main oder nur 2 und welche
   linkes widget + content oder rechtes widget + content
 - farbanpassung braucht man nicht im generator machen, das kann man dann im css editor tun
 - wenn man die widgets wie die module in der DB registriert, kann man diese hier auswählen.

Es gibt da manigfache Möglichkeiten, ich bin aber der Meinung man sollte das gar nicht zu kompliziert
aufbauen, je einfacher desto sicherer.

Nachtrag
Ich habe mal die in meinem Vorposting vorgeschlagene Struktur festgehalten und
als Anhang beigelegt.
ich denke man kann sich so vlt. ein besseres Bild machen.

[Edit]
  Man könnte generell aus der clansuite.config.php im Sektor Template,
  css = "standard.css" wegnehmen und global immer eine import.css als standard
  laden. So braucht man doch von theme zu theme keine config definition für css machen.
  was im endeffekt themenspezifisch dann in der import.css importiert wird ist dann unerheblich.
  Ob das dann die standard.css oder noch 5 andere sind spielt keine rolle.

[Jens-A. Koch]

Ok - die Dateien sind eingefügt. Und zwar unter "/themes/core/css/csf/" und für ein einzelnes Theme unter "/themes/frontend/xtemplate". Dort will ich das Rendering mit Xtemplate und das Boxen Modell vom CSS testen. Es sind nun einige Nachbesserungen erforderlich und das Einfügen der fehlenden Attribute (Datagrid etc.).

[Edit]
  Man könnte generell aus der clansuite.config.php im Sektor Template,
  css = "standard.css" wegnehmen und global immer eine import.css als standard
  laden. So braucht man doch von theme zu theme keine config definition für css machen.
  was im endeffekt themenspezifisch dann in der import.css importiert wird ist dann unerheblich.
  Ob das dann die standard.css oder noch 5 andere sind spielt keine rolle.

Ja, richtig - die CSS global zu definieren macht keinen Sinn. Ich nehme es dort raus. Hardcoded reicht als Lösung.