CSS-Framework von Contao 3 – was hat sich geändert?
Ich versuche hier einmal, die grundlegenden Änderungen im neuen CSS-Framework im Vergleich zu Contao 2.x zusammenzufassen. Ich habe selbst eine ganze Weile gebraucht, um komplett klar zu sehen.
- Framework-Komponenten im Layout
- interne Stylesheets
- externe CSS-Dateien
- Zusammenfassung aller CSS-Dateien
- Spaltenlayout per Holy Grail
- Das Layout ist jetzt responsive
1. Framework-Komponenten im Layout
Die gewünschten Komponenten des CSS-Frameworks können nun einfach und übersichtlich im Layout aktiviert bzw. deaktiviert werden:
- Layout-Builder:
Fügt die Zeilenhöhen, Spaltenbreiten und Angaben zum "statischen Layout" im head ein, lädt die layout.css, die für die Spaltenanordnung mittels -> Holy-Grail-Technik sorgt, automatisch reduziertes Layout für Bildschirme mit weniger als 768px Breite, siehe Punkt 6. - CSS-Reset:
Lädt die reset.css, die umfassend diverse CSS-Eigenschaften normalisiert, unter anderem werden Abstände angeglichen, Schriftart und Schriftgrößen gesetzt, Listensymbole entfernt ... - Responsive Grid:
Lädt die responsive.css, stellt ein 12spaltiges Grid zur Verfügung, das über Klassennamen wie grid3 oder offset6 genutzt werden kann. Responsive heißt: Auf Bildschirmen von mindestens 980px Breite basiert das Layout auf einer Gesamtbreite von 960px, darunter wird sie auf 744px reduziert. Unterhalb von 768px Bildschirmbreite werden alle Floats entfernt und somit alle Grid-Module untereinander angeordnet. - TinyMCE-Stylesheet:
Wenn aktiviert, werden die dort hinterlegten Styles nicht nur im TinyMCE für das Format-Menü genutzt, sondern auch im Frontend angewendet.
Die Originale der 3 erstgenannten liegen auch in unkomprimierter Fassung im Ordner assets/contao/css. Sie sollten natürlich nicht an dieser Stelle verändert sondern bei Bedarf in eigenen Styles überschrieben werden. Früher mussten Zusätze wie Reset oder Grid manuell geladen werden.
2. Interne Stylesheets
Keine wesentlichen Änderungen meines Wissens, CSS3-Verläufe wurden an eine neue Syntax angepasst
3. Externe CSS-Dateien
können nun im Layout unter "Zusätzliche Stylesheets" ausgewählt werden. Die Einbindung per "Zusätzliche <head>-Tags" oder per fe_page ist somit nicht mehr nötig.
Allerdings: Eine media-Angabe (screen, print, ...) ist hier nicht vorgesehen und muss ggf. in der externen Datei mit @media geregelt werden.
4. Zusammenfassung aller CSS-Dateien
Alle CSS-Framework-Komponenten, internen Stylesheets sowie "Zusätzlichen Stylesheets" werden zu einer CSS-Datei zusammengefasst, um http-Requests zu sparen. Ist in den Globalen Einstellungen die Option "Skripte komprimieren" aktiviert, werden interne Stylesheets komprimiert, die Framework-Dateien sind es ohnehin. Die "Zusätzlichen Stylesheets" werden nicht komprimiert.
Für das Debugging kann es ein Nachteil sein, mit "Zusätzlichen Stylesheets" zu arbeiten, da sich in der zusammengefassten Datei natürlich die Zeilennummern ändern und somit das Auffinden per Firebug o.ä. erschwert wird.
5. Spaltenlayout per Holy-Grail
Die verwendete Technik für Spaltenlayouts hat sich komplett geändert. Geblieben ist der Grundaufbau mit festen Breiten bei den Seitenspalten und einer flexible Hauptspalte. (Die Flexibilität der mittleren Spalte kommt natürlich nur zum Tragen, wenn der #wrapper flexibel ist.)
Vorher: Im 100% breiten #container stehen zuerst die Seitenspalten #left und #right, die jeweils gefloatet werden. Die #main-Spalte ist statisch und hält nach rechts und links per Margin Abstand zum Rand des #container.
Holy-Grail: Der #container ist mittels Padding links und rechts auf die Breite der Hauptspalte reduziert. Innerhalb des #container werden zuerst #main, dann #left und #right aufgeführt. Alle werden nach links gefloatet. Um die Seitenspalten in die seitlichen Padding-Zonen des #container zu verschieben, wird eine Kombination aus negativem Außen-Margin und relativer Verschiebung (linke Spalte) verwendet:
Code:
#right { margin-right: -100%; }
#left { margin-left: -100%; right: 123px} /*je nach Spaltenbreite */
Details: siehe http://alistapart.com/articles/holygrail
Vorteil des Holy Grail: Content first.
Nachteil: Es können keine prozentualen Spaltenbreiten verwendet werden!
[Nachtrag]
Mit wenigen Zeilen CSS könnte man sogar noch equal heights realisieren. Grundgedanke ist, dass der Container zwar mittels linkem und rechtem Padding auf die Breite der Mittelspalte geschrumpft wurde, dieses jedoch genau so gut mit Border oder Margin erreicht werden kann:
Code:
/* equal heights: gleich lange Spalten mit fetten farbigen Borders in der Stärke der Spalten */
#container {
padding: 0;
border-left: 123px solid #fff;
border-right: 234px solid #fff;
}
Code:
/* equal heights: gleich lange Spalten mit Spalten-Trennlinien und Margins in der Breite der Spalten */
#container {
padding: 0;
border-left: 1px dashed #ccc;
border-right: 1px dashed #ccc;
margin-left: 123px;
margin-right: 234px;
}
6. Das Layout ist jetzt responsive!
Der Layout-Builder enthält von vornherein ein Media-Query, das für Bildschirmbreiten unterhalb von 768px den Holy-Grail abschaltet und somit alle Spaltenbereiche in 100% Breite untereinander anzeigt. Auch die #wrapper-Breite wird aufgehoben und passt sich der Bildschirmbreite an. Höhenangaben für #header und #footer entfallen ebenfalls.
Wer das unbedingt verhindern will (was schade wäre), muss die Anweisungen mittels eigenem Media-Query wieder überschreiben. z.B. so:
Code:
/*Layout-Builder Media-Query überschreiben */
/*in diesem Beispiel ist #left 200px und #right 250px breit */
@media (max-width:767px)
{
#wrapper {
margin: 0 auto;
width: 960px;
}
#header {
height: 240px;
}
#footer {
height:100px;
}
#container {
padding-left: 200px;
padding-right: 250px;
}
#main, #left, #right {
float: left;
}
#main {
width: 100%;
}
#left {
width: 200px;
right: 200px;
margin-left: -100%;
}
#right {
width: 250px;
margin-right: -100%;
}
}
CSS-Framework von Contao 3 – was hat sich geändert?
Soweit ich mich erinnern kann, lässt sich für externe CSS Dateien schon einen Media-Type definieren. Ich weis allerdings nicht genau wie der Syntax ist, aber das müsste zumindest in einem GitHub Ticket stehen.
Equal heights und Holy Grail
Eine gute und einfache Lösung für die Optik von gleich langen Spalten ohne Einsatz von Grafiken habe ich oben nachgetragen. Die Anregung dazu fand ich im CSS-Buch "Fortgeschrittene CSS-Techniken" von Corina Rudel und Ingo Chao.
AW: CSS-Framework von Contao 3 – was hat sich geändert?
Der Haken ist doch im Grunde da. Das layout-CSS weglassen, fertig.
Ich denke langsam, dass es bei den layoutbuilder doch eher um Begriffligkeiten geht.
Jeder meint was anderes, aber jeder meint auch das Gleiche zu meinen.
Einige andere Begriffe und Konzepte im Contao-Slang sind auch verwirrend. Artikel und Inhaltselemente z.B. wobei für mich ein Artikel eigentlich begrifflich ein Inhaltselement einer Seite darstellt.
Dann habe ich da ein gewisses Problem mit Theme & Layout. Pro Seitenatruktur kann ich eigentlich nur ein Theme verwenden, da Module ja auch Inhaltselement sein können und diesen ziemlich egal ist in welchem Theme sie stecken. Sie ändern ich in einem "Artikel" nicht wenn sich das Theme ändert. Verlinken von Modulen geht ja auch nicht. Man muss sich für ein Modul aus einem Theme entscheiden. Das hat mich dazu bewogen jetzt immer ein Globales Theme für Module als Inhaltselebts eines Artikels zu nutzen und diese nicht in das Theme des Layouts zu packen.
Das eigentliche Theme ist für mich das Layout. Die Module gehören eigentlich ausserhalb des Themes.
Ist aber nur meine Meinung.
So oder so. Die Begriffe und unscharfen Definitionen helfen nicht gerade in Diskussionen über diese Features. Das führt zu unterschiedlichen Wahrnehmungen des Themas und zum Teil völligem aneinander vorbei reden.
Man gewöhnt sich zwar an alles, aber A hat sich schon gewöhnt und B noch nicht und nutzt die Begriffe wie im allgemeinen Sprachgebrauch.
Ich bin dann mal fertig mit philosophieren. Bin eh voll vom Thema ab.
Gruß.
AW: CSS-Framework von Contao 3 – was hat sich geändert?
Sollten Themes dann nicht neben Modulen, CSS und Layout nicht auch die Seitenstruktur enthalten?
Mehrere Themes könnten Benutzer-Vorlieben-Responsive gestaltet werden. Auch z.B. um neben universellen Seiten eben auch welche mit Modulen für Menschen mit Einschränkungen zu erstellen. Da können durchaus auch verschiedene Module als Inhaltselement vorkommen.
Mal abgesehen davon, dass ich es nicht soo weltfremd empfinde dem User die Möglichkeit nicht nur zu geben, sondern auch praktikabel zu machen.
Richtig wäre:
Eine Seite kann mehrere Inhalte haben. Unter anderem Artikel.
Jetzt ist es so: Eine Seite kann mehrere Artikel haben und diese wiederum Inhaltselemente.
Ist ein Artikel im Wortsinn kein Inhalt?
Das Wort Theme ist ebenfalls irreführend. Im Allgemeinen wird man annehmen, dass man damit verschiedene Themes für eine Seite erstellen kann, weil es überall so genutzt wird. Das ist aber de Fakto das Layout.
Für mich wäre es so richtig:
Seite: Struktur, Inhalt=Artikel, Stylesheets, Module, Theme=Layout.
So kann man auch mit nicht Contaoanern oder Neulingen ohne Verwirrung sprechen. :)
AW: CSS-Framework von Contao 3 – was hat sich geändert?
Das ist.mir so aufgefallen, als ich mein lokales Theme exportiert habe und Online importiert. Zwischen Inhalt und Theme bestehen eben Abhängigkeiten aufgrund von Modulen die man als Inhaltselemente Nutzen kann.
Deshalb ja auch die Idee, dass ich Module, die in Artikeln sind in ein globales Theme auslagere. So kann ich lokale Themes ohne Probleme Online stellen. Damit ist die Abhängigkeit gelöst. Das globale Theme gehört bei mir damit untrennbar zum Inhalt. Das eigentliche Theme ist dann unabhängig.
Ideal wäre es, wenn man die Module Global definieren könnte und diese dann in die Themes verlinkt. Dann könnte man durchaus mehrere Themes parallel nutzen. Die genutzten Module könnten dann, ähnlich wie die Templates behandelt werden. Überhaupt finde ich, dass das Template-Modell Recht gut dafür geeignet ist. Wäre schön, wenn Module ähnlich gehandhabt werden könnten.
Um es auf die Spitze zu treiben, wäre es unglaublich cool, wenn man so ein global definiertes Modul verlinkt im Theme sogar überschreiben könnte. Also die Einstellungen.
Ähnlich C++.
Global:
Modul Navigation menu <- enthält die ID
Im Theme:
menu Topmenu < enthält die Einstellungen
menu Sidemenu ... Etc
Dann im Layout:
Topmenu Kopfzeile
Sidemenu linke Spalte
Im Artikel als Inhaltselement:
menu Embeddedmenu < Einstellungen
Sorry, doof erklärt. Kann ich auch besser, aber nicht per Handy. Geht auch etwas zu weit.
Gruß.
AW: CSS-Framework von Contao 3 – was hat sich geändert?
Mir fällt gerade auf:
Wenn Inhaltsmodule anhand des Namens identifiziert werden würde, dann wäre das simpel gelöst. Muss halt nur der Name stimmen. Wie bei Templates.
