CSS-Framework in Contao 3 umstellen?

[leo]

Ich arbeite momentan wieder am Thema "mobile Webseiten" und habe gestern ein paar coole Änderungen dazu committet, u.a. ein verbessertes 12-Spalten-Grid, dass sich responsive verhält (gibt es eigentlich ein deutsches Wort für "responsive"?).

Jetzt würde ich gerne auch das automatisch generierte Seitenlayout responsive machen, so dass die Spalten ab einer gewissen Breite untereinander dargestellt werden etc. Das Problem hierbei: Contao gibt die linke und rechte Spalte vor der Hauptspalte aus, d.h. man hat alles unwichtige oben und die eigentlichen Inhalte unten – ein Problem, dass im Zusammenhang mit SEO schon öfter diskutiert wurde.

Die Lösung heißt "Holy-Grail-Layout" und ist schon lange als Extension verfügbar. Ich würde nun am liebsten das Core-CSS-Framework auf "Holy-Grail" umstellen, wollte aber vorher mal nachfragen, wie hoch ihr das Risiko einschätzt, dass dadurch die Rückwärtskompatibilität verloren geht.

Im Grunde ändert sich nur die Reihenfolge der Spalte im Quelltext und der Rest ist CSS. Müsste eigentlich funktionieren

[andreasisaak]

Ich bin da etwas zwiegespalten. Einerseits würde ich nur ungerne die Rückwärtskompatibilität brechen und alle relevanten CSS-Befehle ändern, andererseits haben Leute die von 2.11.x auf Contao 3 wechseln ganz andere Sorgen. Ich bezweifle immer noch das alles 100% passen wird wenn man das Update einspielt. Da machen diese paar CSS-Befehle auch nicht mehr viel aus.

Was passiert eigentlich wenn jemand die fe_page bearbeitet hat? Die muss mit Contao 3 ja sowieso komplett überarbeitet werden, wie es bei 2.9.x halt auch der Fall war.

[psren]

Ich denke das Risiko hält sich sehr in Grenzen. (Außer bei eigenem fe_page eben, aber das hat man ja immer).

Probleme sollte es nur geben wenn jemand das Contao-Framework mit eigenem CSS überschreibt. Ich habe einige (~10) bestehende Seiten auf HolyGrail umgestellt und konnte bisher kein einziges mal ein Problem feststellen.
Ich würde den Schritt befürworten!

[leo]

Was passiert eigentlich wenn jemand die fe_page bearbeitet hat?

Eine bearbeitete fe_page muss man immer anpassen, wenn es Änderungen gab. Beim Wechsel von 2.11 auf 3 sind zwei Änderungen relevant:

• Das Scheduler-Skript ist jetzt eine eigene Datei
• Bei mobilen Layouts wird das Meta-Viewport-Tag gesetzt

https://github.com/contao/core/commi.../fe_page.html5

[magicsepp]

bin auch dafür....

[psren]

Ja, das sind ja sowieso alle gewohnt dass man ab und an ein eigenes Template anpassen muss. Geht ja aber auch garnicht anderst und wer updaten will bekommt das ja auch hin :-)
Wie gesagt ich kann keine Probleme absehen.

Könnte man eigentlich nicht die Spaltenbreiten als Variable ans Theme übergeben, so dass man das Framework als CSS Datei standartmäßig in jedes neue Theme einbindet?
Dann muss man wenn man das FW nicht braucht einfach die CSS-Datei löschen/im Seitenlayout nicht hinzufügen.

[leo]

Ich glaube, das was Du meinst habe ich gestern comittet.



Wird der Layout-Builder nicht eingebunden, wird das CSS-Framework komplett umgangen.

[Andreas]

Eigentlich dürften die 3 Spalten im Template noch nicht ausgezeichnet sein als left, right und main, sondern so wie bei YAML als 1, 2 und 3. Dann müsste man im Layout die Möglichkeit haben zu entscheiden welche Spalte ich als left, right und main definieren möchte. Default wäre dann (2.11) 1=left, 2=right, 3=main. Holy Grail wäre 1=main, 2=left, 3=right. Das CSS-Framework müsste dann darauf reagieren. Damit wäre Contao dann noch ein ganzes Stück flexibler.

http://www.yaml.de/docs/index.html#yaml-columns

[leo]

Ich habe die Änderungen jetzt mal testweise committet.

https://github.com/contao/core/commi...63377f9b7f72f8

Sollte das nicht funktionieren, können wir sie wieder zurücknehmen.

[xchs]

Ich wollte mir auch mal anschauen, wie man Contao am besten mit Twitter Bootstrap verheiraten könnte. Erste Ansätze gibt's ja bereits...

Bin leider noch nicht dazu gekommen.

[leo]

Das wird auch meiner Meinung nach nicht klappen, denn ein Framework wie Bootstrap muss man richtig integrieren, damit beispielsweise auch das passende HTML-Markup generiert wird.

[ciaobello]

(gibt es eigentlich ein deutsches Wort für "responsive"?)

Hallo Leo
Also mir schlägt Google "reagieren" vor. Adjektive dazu wären dann ansprechbar, empfänglich, interessiert etc.

Somit wäre es ein reagierendes layout

ciaobello

[psren]

eingedeutscht würde ich "selbstanpassend" wählen :-D

[andreasisaak]

Ich würde es so lassen, jedem Webentwickler ist das ein Begriff. Ist nun mal ein Fachbegriff und hat nichts mit denglisch zu tun Oder wie würdet ihr Progressive Enhancement übersetzen?

[psren]

Naja, es geht ja nicht nur um Webdesigner sondern auch um Kunden.

"Ich will dass es auf dem iPhone läuft" => "ja das machen wir so, dass es sich von selbst an den Bildschirm anpasst"

Versteht jeder "Depp". Responsive Design sagt dem Malermeister XY wohl eher weniger was (schlechtes Beispiel)

[andreasisaak]

Und wie magst du das jetzt nennen? Selbst anpassbares Webdesign? Halte ich für noch verwirrender weil der Malermeister dann nicht mal bei Google danach suchen kann ohne 0 Ergebnisse zu erhalten Bei "Responsive Webdesign" findet er wenigstens etwas und kann sich zur Not näher damit befassen. Ansonsten reicht den meisten ja auch flexibles Design - dann wissen sie das es anpassbar ist und sich für fast jedes Gerät eignet. Den genauen Unterschied müssen die meisten eh nicht wissen, meiner Meinung nach.

Ich habe schon lange damit aufgehört dem Kunden selbst gebaute Wörter vorzusetzen nur damit er es versteht. Wenn ich Xbox spiele, dann ja auch mit einem Controller und nicht mit einer "mobilen Steuerung". Und das verstehen ja auch viele Kunden wenn sie einen auf die Xbox im Büro ansprechen. Komisch

[plastiko]

Die Equal-height columns könnten die Anker (#skipNavigation) im ff unerreichbar machen.

#container {
	overflow:hidden;
}
#main,#left,#right {
	float:left;
	position:relative;
	padding-bottom:1000em;
	margin-bottom:-1000em;

http://www.positioniseverything.net/...lheightanchors

Mit Anker/id in der url:
http://www.positioniseverything.net/...anchors#target

[leo]

Könnten sie nur oder machen sie die Anker unerreichbar?

Ich habe übrigens die Music Academy jetzt auch noch angepasst und ein mobiles Layout erstellt:



Das mobile Layout unterscheidet sich nur dadurch, dass weniger Module geladen werden und die Navigationen in den Footer rutschen. Man hätte es aber auch nur über CSS lösen können (wobei Elemente mit display:none trotzdem geladen werden!).

[plastiko]

Könnten sie nur oder machen sie die Anker unerreichbar?

Die Anker selber nicht immer. Aber Inhalte werden fast immer abgeschnitten wenn das Sprungziel innerhalb der Equal-height Spalten liegt (zumindest im ff).

[leo]

Hm, das ist mir jetzt ein bisschen zu abstrakt. Könntest Du ein Ticket aufmachen und dort beschreiben, wie man das Problem reproduziert? Am besten auf Basis der Music Academy.

[plastiko]

Ein Beispiel:
Bei einem Sprung auf #breaking_news verschwinden Inhalte in den Spalten #main und #left



Ähnliches würde passieren wenn mod_navigation in #left eingebunden wäre und auf #skipNavigation1 gesprungen wird.

Ohne "Equal Height Columns" besteht das Problem nicht:

#main, #left, #right {
    float: left;
    /*margin-bottom: -1000em;*/
    /*padding-bottom: 1000em;*/
    position: relative;
}

Edit:
Als CSS-Framework habe ich Layout-Builder aktiviert.

[Dani]

Ich wäre auch dafür.

[leo]

Ist das nur in Opera der Fall? Hast Du die neueste Version?

[plastiko]

Mein Opera ist nicht ganz neu (11.62.)
In anderen Browsern sieht es aber genauso aus:

• ff 11.0
• IE 9
• chrome (aktuell)
• Safari 5.0.1 (windows)

Anfangs (#17) glaubte ich noch, das passiert nur im ff.

[pmmueller]

Nur zum Sagen: Mit "Holy Grail" verliert man wahrscheinlich komplett die Unterstützung für IE7.

Schaut euch die "Holy Grail-Testseite" mal im IE9 an und geht dann über F12 Entwicklertools in den Browsermodus für IE7. Die Spalten werden laaaang und der Footer ist weg.

Darum hatte Dirk Jesse die Geschichte mit den gleichlangen Spalten nicht in YAML integriert (Blogpost zu IE7 Beta 2, im viertletzten Absatz).

Nachtrag
Alex Robinson hat auf positionisverything.net in seinem Artikel zu "In Search of One True Layout" einige Probleme mit seiner Methode gleichlanger Spalten dokumentiert.

• Appendix J Problems with the Equal Height Columns method

Punkt 1 ist dort "Linking to anchors in elements within the containing block". Meines Wissens basiert "Holy Grail" auf der gleichen Methode und dürfte damit dieselben Probleme haben (siehe oben, #19).

Also ich weiß nicht, ich würde es glaube ich nicht tun. Höchstens als Option.

Und noch'n Nachtrag
Habe die neueste Beta mal installiert und werde mir das alles mal genauer anschauen, bevor ich hier irgendwelche voreiligen Schlüsse ziehe. Da guckt man mal ein paar Wochen nicht hin und schon hat sich beim CSS-Framework kanonenmäßig viel geändert

[Andreas]

Mit YAML wär das nicht passiert Kommt halt auf das richtige CSS an. Spontan würde ich sagen, da fehlt ja auch der Clearer in der letzten (3.) Spalte.

Schau dir mal das hier an http://builder.yaml.de/ Stell auf 2-1-3, also die erste von den 3 Spalten in der Mitte, was anderes ist Holy-Grail ja nicht, als das von 3 untereinander liegenden DIVs die erste als Spalte in der Mitte präsentiert wird. Und das geht hier auch im IE7.

[Andreas]

Zur gleichen Spaltenhöhe: Meiner Meinung nach brauchen wir das nicht, haben wir bis jetzt auch nicht gehabt. Wer möchte kann mit JS die Höhe des 3. untersten DIVs (in 2.11.4 als mittlere Spalte benutzt, bei Holy-Grail als z.B. rechte Spalte benutzt) ausmessen und den anderen beiden DIVs zuweisen. Der unterste DIV ist immer der längste. Revidiert bzw. eingeschränkt in #29

[plastiko]

Zur gleichen Spaltenhöhe: ..., haben wir bis jetzt auch nicht gehabt.

Zumindest ist #main immer die höchste Spalte. #clear rutscht unter die Floats (#left und #right).
Nur wird dieser Effekt kaum für Hintergrundfarben genutzt.

[Andreas]

Zumindest ist #main immer die höchste Spalte. #clear rutscht unter die Floats (#left und #right).
Nur wird dieser Effekt kaum für Hintergrundfarben genutzt.

Wenn das oberste DIV für #main verwendet wird (holy grail), ist sie nicht mehr die höchste. Immer der letzte DIV (Revidiert bzw. eingeschränkt in #29), der auch das Clearing besitzt und soviel ich weiß weiterhin besitzen muss/sollte.

[plastiko]

Ich meinte das derzeitige Framework.

[Andreas]

Schade, dass es die Layoutbeispiele von YAML nicht mehr online gibt. Hier der Download http://www.yaml.de/download/release_...331_110618.zip Die Examples sind da drin.

Da kann man mit Klick den Spalten Text hinzufügen und sieht, dass die 3. immer mit nach unten gezogen wird. Aber sich seh grad, dass das nur in den Layouts mit dem ersten DIV in der Mitte (holy grail) grad nicht der Fall ist, also obige Aussage mit längster Spalte zurück.

[pmmueller]

Das mit dem Holy Grail ist ja schon recht fortgeschritten und scheint soweit ja alles gut zu funktionieren.

Was mir aber aufgefallen ist, dass der Skiplink zum Überspringen der Navigation nur noch begrenzt sinnvoll ist, denn der bringt einen ja nur noch zum Footer bzw. zur rechten Spalte.

Stattdessen wäre ein Skiplink weiter oben, der dann "Zur Navigation" springt, vielleicht ganz sinnvoll. Was haltet ihr davon?

[MacKP]

Stattdessen wäre ein Skiplink weiter oben, der dann "Zur Navigation" springt, vielleicht ganz sinnvoll. Was haltet ihr davon?

Hallo pmmueller,
da ich eigentlich immer mit Yaml arbeite, baue ich sowas auch immer ein bei meinen Seiten.
Ich habe schon sehr lange überlegt wie man sowas per Modul für Contao machen könnte... Das Problem ist einfach, das man sowas nicht automatisch hin bekommt. Wenn sowas für jede Navigation generiert werden würde, dann hätte man direkt auch Sciplinks zu unwichtigen Navigationen etc.
Egentlich müsste man im Seitenlayout so eine Stelle markieren können und/oder bei dem Modulen ankreuzen können wofür ein Skiplink erstellt werden soll. Dazu dann noch eine Texteingabe (mehrsprachig) was da stehen soll.

Und ich muss sagen, wenn man dann mal drüber nachdenkt, dann hat man das einfacher und schneller im fe_page rein geschrieben *g*

Viele Grüße

[plastiko]

Stattdessen wäre ein Skiplink weiter oben, der dann "Zur Navigation" springt, vielleicht ganz sinnvoll. Was haltet ihr davon?

Oft ist die Navigation aber schon ganz oben.

Ich weiß nicht ob ich mit der aktuellsten Version herumprobiere. Aber ich habe nach wie vor den Eindruck, daß es unmöglich ist, sauber in eine der Spalten zu springen (die erwähnten "Equal-height columns"). Dabei ist es egal wo der Skiplink sich befindet.
In der Music Academy kann man das zunächst nicht sehen weil

1. Das Sprungziel nicht in den Spalten liegt
2. Es absolute positioniert ist

Ich versuche noch einmal das Problem mit einem html-dummy (sichtbarer Skiplink / Sprunkziel):
http://html-dummy.red-rod.net/contao3b1-holygrail.html