CSS anstatt Frames

[paulbr]

Hier mal ein Tip zur Anpassung, falls mal jemand ein Frameset für ein Theme benötigt.

Anstatt ein Frameset in einem Theme einzubauen, ist es besser das mittels CSS zu machen.
Framesets sind mittlerweile deprecated, wie man so schön sagt.

Zudem hat man den Vorteil das man trotz frames nur 1 Layout-Template benötigt und trotzdem
einen festen frame oben und/oder unten am Bildschirmrand, sowie dazwischen einen scrollablen
Mainbereich hat.

Wie kann man das umsetzen:

In dem Layout-Template: index.tpl des Themes, gleich nach dem body-tag

<div id="topframe">
  --- hier die tabelle, menüs, texte oder widgets welche da erscheinen sollen ---
</div>

<div id="mainframe">
  --- hier kommt der normale body inhalt was in jeder index.tpl vorhanden ist rein. ---
       z.b. breadcrumb, left_widget, right-widget, content etc.
       ebenfalls wird hier, wenn man das css framework benutzen will, die div's
       für header, col1, col2, col3, footer eingefügt.
</div>

<div id="bottomframe">
  --- hier die tabelle, menüs, texte oder widgets welche da erscheinen sollen ---
</div>

Wichtig ist nur, das die 3 Framecontainer ausserhalb sitzen, da sonst der bottomframe,
sollte der Mainframe zu kurz sein, nach oben rutscht und somit nicht mehr am unteren
Bildschirmrand ist.

das benötigte frameset.css

Code:

body{
    margin:0;
    padding:30px 0 30px 0;
    font-family: "Lucida Grande", Arial, Verdana, Helvetica, sans-serif;
    font-size: 9pt;
}

div#topframe{
    position:absolute;
    top:0;
    left:0;
    width:100%;
    height:30px;
    background: #FFFF00;
    border-bottom: 2px groove #000000;
}

div#bottomframe{
    position:absolute;
    bottom:0;
    left:0;
    width:100%;
    height:30px;
    background: #FFFF00;
    border-top: 2px groove #000000;
}

@media screen{
    body>div#topframe{
        position:fixed;
    }
    body>div#bottomframe{
        position:fixed;
    }
}

* html body{
    overflow:hidden;
}

Die frameset.css muss als letztes style importiert werden, weil die body angaben wichtig
für die frames sind.

Ein topframe macht durchaus Sinn um da z.b. wichtige links unterzubringen, so hat man diese
egal wie weit man nach unten gescrollt hat, sofort greifbar.

Das soll nur ein Tip sein, damit nicht jemand so wie ich, erst ein paar stunden mit normalen
Framesets herum experimentiert um dann festzustellen, das es auf diese Art viel einfacher zu
handhaben ist.

gruss
paul

[thunderm00n]

Was du beschreibst ist quasi das Standard BoxedModel welches mittels Divs und CSS genutzt wird um Tabellen und IFrames zu vermeiden. Wichtig bei 3-Spaltigen Layouts ist hier der 1px IE Workaround zu nutzen damit auch der IE alles richtig darstellt...

Ich persönlich bin sowieso ein Freund vons Divs, daher verzichte ich wann immer es geht auf tabellen und frames... hatte auch mal ein eigenes Backendtheme nur mittels CSS und Divs gebaut, weiß aber nicht obs das noch gibt^^ war lange zeit nicht dabei da ich mich leider nicht zweiteilen konnte.

[Jens-A. Koch]

@paul
Danke für die Beschreibung.

@thunder
Willkommen zurück 
Wenn Du die Zeit findest, wäre es schön, wenn Du Dich der "Clansuite CSS Framework"-Geschichte annehmen würdest. Bei den Forms hattest Du ja auch schon mit @import's gearbeitet - es geht in diese Richtung, nur noch etwas strukturierter.

[paulbr]

ja, auch ich verwende lieber div's.

Das frameset ist noch ausserhalb des normalen boxmodels, welches erst im mainframe zum tragen kommt.
Ich bin auch der meinung es sollte ein clansuite eigenes framework erstellt werden.
In einem anderen Post hab ich ja mal ein Vorschlag gemacht: http://forum.clansuite.com/index.php/topic,3181.0.html

Wenn viele ihre erfahrungen da mit einbringen, denke ich das es sehr gut werden kann.

gruss
paul

[Jens-A. Koch]

Wenn viele ihre erfahrungen da mit einbringen, denke ich das es sehr gut werden kann.

Das gilt auch fürs gesamte System.
Was das CSS Framework betrifft, so müsste man es eher als eine eigenständige Komponente sehen und evtl. sogar ein Verzeichnis dafür bei den Unterprojekten anlegen.
Die im CSS definierten Attribute könnten direkt in einer index.html, die als Demonstration und Test dient, angewandet werden.

[paulbr]

Ich habe das grobe beispiel bzgl. css-framework aus meinem post mal überarbeitet.
Das Framework sollte CSS2 Standard konform sein.

Ein zweites Projekt dann auf HTML5 + CSS3 zu gegebener Zeit, evtl. dafür dann
in der clansuite.config.php ein Flag ob CSS2 oder CSS3 Framework genutzt werden soll  

@Thunder bitte mal auf tauglichkeit checken, du kennst dich da besser aus mit,
meine erfahrungen sind auf dem Gebiet nicht so berrauschend  

Jeder hat so seine eigenen Vorstellungen was den namespace der klassen angeht.
Ich denke hier sollte man auf jedenfall Unterscheiden nach core und themen spezifische
klassen.

Die Core definitionen bleiben in /themes/core/css unverändert, hier sind die grunddefinitionen
auch bzgl. cross browser.
Ein ändern der template.css aus dem core zum anpassen eines themes erfolgt durch vererbung
in der themes template_u, grid_u, form_u usw.
Ich denke das macht Sinn, so bleiben die Standard definitionen als Grundlage für alle Templates erhalten.

Eine index.html zeigt die bereits integrierten definitionen, man sollte hier eine navigation einbauen
um weitere Seiten darzustellen für: formulare, mehrspaltige texte, bilder in texten, etc.

Desweiteren denke ich, das man eine Erklärung bzgl. der funktionsweise und namesnennung der
Master Definitionen benötigt. Das kann man auch in den Textpassagen der darstellung innerhalb der
demoseiten gestalten.


gruss
paul

[paulbr]

Arbeitsgrundlage

Für die Grundausstattung habe ich das mal ergänzt um einen CSS-Builder.

@todo: Ideal wäre wenn man das CSS-Builder Provisorium bei gelegenheit als cli umfunktionieren
würde, damit man den builder direkt, ohne umweg über den browser, starten kann.

Die Core dateien sind weiter unterteilt (gesplittet), ich denke das man so
leichter arbeiten kann, wenn nicht zuviel in einer datei definiert ist.

Mit dem Builder werden die core css dateien komprimiert und in einer
gemeinsamen css datei zusammen geführt.

Importiert wird letztendlich nur noch die core 'csfw.css' oder wie auch immer sie heissen möchte 
Sowie die themenspezifischen css anpassungen aus dem entsprechenden frontend-theme.

@alle Mitglieder: Werft euch ins getümmel und bringt eure ideen zum wohle aller mit ein!

@vain: vlt. sollte man was das clansuite css framework betrifft ein eigene Untersektion im forum widmen,
ich denke das es hier einige themen dies bzgl. geben wird.

@thunder: ich würde mich freuen wenn du das ganze leiten und koordinieren würdest

gruss
paul

[paulbr]

Arbeitsgrundlage

Als Arbeitsgrundlage habe ich die index.html durch eine index.php ersetzt.

Die index.php enthält nun im topframe ein css-menü mit dem dann, wenn diese existieren,
bequem die example seiten durchgeblättert werden können.

Die examples werden im ordner: examples abgelegt, sortiert in unterordner für welches beispiel
das ist.

z.B. Formulare liegen im Unterordner 'form'
die verlinkung erfolgt nach dem shema: index.php?site=form-01
d.h.  die index.php zerlegt den parameter site
       Ordnername=form
       Filename = form-01.html

Der topframe mit dem Menü wird automatisch inkludiert nach dem gleichen shema und ist deshalb
nicht in den einzelnen Beispielseiten enthalten.
Änderungen am Menü sind nur in 'examples/index/index-header.html' nötig.

Hinweis: Ich weiss das die farbe des topframes und des Menübalkens nicht besonders ansprechend
gewählt sind, aber ich legte erstmal Wert auf die funktion selbiger, sowie auf den Kontrast zur Seite selbst.

So genug gearbeitet für heute, bischen abspannen und wow zocken 

gruss
paul

[paulbr]

Neuer Stand des Frameworks!

• index.php sowie headermenü überarbeitet.
• Startseite überarbeitet
• Neue Struktur der Examples Ordner und Seiten.
• Splittung und umbenennung einiger core definitionen
• CssCoreBuilder umbenannt in CssBuilder und in root verschoben
• CssBuilder als librarie umfunktioniert, wird nun in der index.php bei bedarf includiert
• Integration des CssBuilder ins headermenü unter Tools
• Der CssBuilder generiert nun auch die Theme import.css und @importiert darin den Core
• Prozentuale Grid Definitionen hinzugefügt (core_grid.css)
• Menü->Schema: Basis Layout Container demo hinzugefügt
• Menü->Schema: Basis Layout Boxen demo hinzugefügt
• Menü->Schema: Grids in Prozent demo hinzugefügt

gruss
paul

[Jens-A. Koch]

Hallo Paul,

vielen Dank für Deine tolle Arbeit! Der Builder ist eine klasse Idee.
Ich habe leider im Moment zu wenig Zeit, um das CSS-Framework einzupflegen oder etwas am System zu machen. Da Du nun ja doch regelmäßiger Arbeitsanteile beisteuerst, möchte ich Dir nochmal vorschlagen, Dir bei gna.org einen Account anzulegen, damit ich Dir SVN-Zugriff geben kann. So lässt sich die Arbeit besser organisieren und ich werde nicht zum "Flaschenhals". Wir sparen auch Arbeitsschritte, wenn Du Fehler findest und direkt beheben möchtest.

Gruß Jens

[paulbr]

Hallo Jens,

Gut hab ich gemacht: ID:17011

Erwarte aber nicht zuviel, wie gesagt: ich bin noch in der Umdenkphase von PHP4 nach 5.
Zudem bin ich was Clansuite angeht bei weitem noch nicht so vertraut damit.

Wir können ja mal einen Versuch starten 

Clansuite gefällt mir, es ist gut konzipiert und wie ich aus verschiedenen tests mit:
frames (css), java-applet mit parametrisierung aus DB, video einbindung u.a.
feststellen konnte, auch ziemlich flexible und universell einsetzbar.

An folgenden Comunity-Modulen, da ich diese mit für die wichtigsten einer Clan-Webseite halte,
möchte ich mich dann gerne mal ranwagen.

• Forum
• Galerie/Albums Foto+Video
• Private Messages (Post Ein-/Ausgang)
• Live Shoutbox (chat)

Additive

• CSS-Framework weiterentwickeln
• Integration in einem Front-/Backend

Ist zwar erst Milestone 0.2.8 bzw. noch nicht festgelegt , aber ich denke es macht Sinn
sich schon jetzt damit zu beschäfftigen. Braucht ja auch seine Zeit das umzusetzen.

Wo können dann das Framework sowie die Module bis zur Reife abgelegt werden?
  - at-dev/module
  - at-dev/csfw
  - at-dev/csfw-templates


gruss
paul

[Jens-A. Koch]

Hallo Paul,

super Sache! Habe Dir SVN-Access Rechte gegeben.
Daher nochmals Herzlich Willkommen im Entwicklerteam (aber das bist Du ja schon längst).

Erwarte aber nicht zuviel, wie gesagt: ich bin noch in der Umdenkphase von PHP4 nach 5. Zudem bin ich was Clansuite angeht bei weitem noch nicht so vertraut damit.

Nein, ich erwarte nicht viel und verstehe meine Rolle hier auch etwas anders.  Ich denke dabei eher an die bessere Organisation der Zusammenarbeit (und biete daher SVN-Access immer sofort an, wenn Beiträge geleistet werden). Mach Dir daher keinen Kopf!
Wer regelmäßig Arbeitsanteile beisteuert, der macht dies aus eigenem Interesse an der Weiterentwicklung von "Clansuite" als Applikation und dem dahinterliegenden Framework, sowie einzelner Komponenten, die ja auch für eigene Zwecke nutzbar sind.

Wir haben es bislang immer so gehalten, dass alle Entwickler gegen den /trunk arbeiten und committen. Nach Möglichkeit (und ich bin da richtig schlecht drin) soll der /trunk nach einem Commit läuffähig bleiben und die anderen nicht von der Arbeit abgeschnitten werden.

Du könntest aber auch den /trunk in Dein eigenes experimentelles Verzeichnis unterhalb von /branches legen (bspw. /branches/paul). So wäre es auch möglich, die Quellcodeformatierungen in Deiner Version anders zu handhaben. Wenn die Dinge dort lauffähig sind, dann mergen wir die Ideen und Weiterentwicklungen aus /branches/ mit dem /trunk.

Soviel erstmal, Jens

[paulbr]

Hallo Jens

Danke für die Aufnahme 

So wäre es auch möglich, die Quellcodeformatierungen in Deiner Version anders zu handhaben.

Da sehe ich wenig Sinn darin und nur doppelte Arbeit, ich formatiere den Code lieber in der allgemein gültigen.

Nach Möglichkeit (und ich bin da richtig schlecht drin) soll der /trunk nach einem Commit läuffähig bleiben und die anderen nicht von der Arbeit abgeschnitten werden

ja, das kann ich auch ganz gut 

Ich werde wenn ein Modul lokal lauffähig ist, dieses in den /trunk comitten.

Das CSS-Framework unter: /subprojects ablegen oder?

gruss
paul

[Jens-A. Koch]

Das CSS-Framework unter: /subprojects ablegen oder?

Ja - das kann man ja auch ohne Clansuite nutzen und sollte abgetrennt gepflegt werden (index.html mit Beispielnutzungen der CSS Attribute).

[paulbr]

Das Framework ist im jetzt svn!

Ich hab bei mir lokal einen vhost clansuite-csfw.com dafür angelegt.
Vieleicht könnte man das ja sogar in die Toolbar integrieren?

Der Css-Builder liest die css-dateien nun mittels einer cssbuilder.ini ein und verarbeitet sie dann.
d.h. man muss am Builder selbst nichts mehr ändern.
Es braucht nur die jeweilige cssbuilder.ini bei bedarf angepasst werden.
Die cssbuilder.ini gibt es sowohl für den core als auch bei den themes und beinhaltet
zusätzlich zu den css-dateien auch informationen über den core bzw- dem Theme.
Wie z.B. Beschreibung des Theme, Erstellungsdatum, Version, Author
Diese werden als header in die komprimierte import-datei geschrieben.

Eine noch nicht ausführliche Kurzerklärung liegt bereits bei: README.mdown
Sie wird mit fortschritt des frameworks ergänzt.

gruss
paul

[Jens-A. Koch]

Das Framework ist im jetzt svn!

Super Sache!

Ich hab bei mir lokal einen vhost clansuite-csfw.com dafür angelegt.
Vieleicht könnte man das ja sogar in die Toolbar integrieren?

Klar - gute Idee. Die Frage ist, wie wir das am günstigsten machen.
Das subproject-dir liegt ja außerhalb vom trunk.
In Betracht kommt das Goto-Menü für den Link auf das CSS-Framework.
Den Link würde ich nur anzeigen, wenn in den Options "clansuite-csfw.com" oder ein anderer Link für diesen Menüpunkt hinterlegt ist.

Könntest Du mal den Weg beschreiben, wie wir das Framework ins Backend bekommen?
Gemeint ist nicht das Einbinden des CSS, sondern so, dass man den CSS-Builder nutzen könnte.

Gruß Jens

[paulbr]

Hallo Jens

Der CSS-Builder liest die daten aus einer ini datei ein, wobei der pfad ausgehend
vom standort des builders hier angegeben werden muss.
Allerdings wird der Builder dann eine Import datei erstellen in welcher ebenfalls die
core/css/csfw.css direkt mit importiert wird.

Eine andere möglichkeit wäre die:
Den CSS-Builder abzuändern damit er nur die im backend/admin liegenden css files
verarbeitet und in eine import.css bzw. standard.css vereinigt.
Der Builder müsste dann manuell über den browser (bookmark) ausgeführt werden.
So kann man diesen auch direkt ohne änderung in jedes thema ob frontend oder backend
kopieren und braucht lediglich die .ini entsprechend anzupassen.

Ich änder den mal entsprechend ab und lad diesen ins svn themes/backend/admin/css, incl.
der cssbuilder.ini.

Dann brauchst du nur die ini bearbeiten und dort die css-dateien eintragen welche komprimiert werden sollen.

gruss
paul

[paulbr]

ok hab die cssbuilder angepasst und ins svn gelegt.

Die cssbuilder.php erstellt nun innerhalb des themes in dem sie liegt, eine kompriemierte gesamt css datei
welche dann ins template importiert werden kann.

In der cssbuilder.ini habe ich zusätzlich die möglichkeit zum Import externer, also nicht im theme liegenden css-dateien hinzugefügt.
Hier einfach den pfad zu den zu importierenden dateien angeben.
Wenn keine importiert werden soll, leer lassen "".

Der Builder funktioniert innerhalb jedem theme, wenn er und die .ini datei in das /css kopiert
und die .ini entsprechend angepasst wird.

Wichtig:
Alle css-dateien welche verarbeitet werden sollen, müssen den tag @media .... beinhalten.
Im normalfall ist dies @media screen, da ansonsten ein sauberes komprimieren nicht stattfinden kann.
beispiel siehe backend/admin/css dateien.

[Jens-A. Koch]

Die cssbuilder.php erstellt nun innerhalb des themes in dem sie liegt, eine kompriemierte gesamt css datei welche dann ins template importiert werden kann.

Ah, langsam wird mir klar, wie das funktioniert. Danke!
Aber dann wäre doch eigentlich auch ein Modul denkbar, dass die Funktionalität vom CssBuilder hat? Das könnte gut in den Thememanager passen.

[paulbr]

ja das hatte ich in einem der vor posts mal erwähnt, das man hier ein Modul Sinn machen würde, eben wegen dem Templatemanager.

Zumindest wenn die css-dateien im adminbereich editierbar sind, sollte dies passieren.