Holy Grail mit prozentualen Spalten

[Toad]

Hallo.

Ich habe eine lokale Testumgebung in der Version 3.0.1 um das Holy grail Layout von Grund auf zu inhalieren.

Dort habe ich ein Theme erstellt mit Färbung im css von #header, #footer, #container (gelb), #main, #left und #right. Diese haben jeweils identische Artikel bekommen um das Layout sichtbar zu machen.
Im Seitenlayout haben Kopf- und Fußzeile 100px und linke und rechte Spalte 15%. Und mit dieser Prozentangabe beginnt mein Unverständnis. Vorweg: Mit px oder em funktioniert es wie erwartet.
Auf jeden Fall ist das Ergebnis dieses hier:

Bildschirmfoto4.png

(der Footer ist im Bild nicht sichtbar und korrekt unter dem Container)

Die Spalten füllen den Container nicht aus. Das passiert meines Wissens nur mit prozentualen angaben. Soll das so?
Hat irgendwer Erfahrungen damit?





Daran anschließend habe ich beim Export älterer schon immer flexibeler Themes herausgefunden, dass es durchaus einen Unterschied macht in welcher Reihenfolge die Framework-CSS im Seitenlayout eingebunden werden.

Aus mir unerfindlichen Gründen ist die Schrift (Verdana) größer, wenn ich CSS-Reset vor dem Layout-Builder einbinde.
In einem anderen Theme mit webfont ist das nicht so. Dort habe ich aber im body schon die Schriftgröße festgetackert. Das würde ich aber gerne vermeiden. Alle Macht dem User ... Alle anderen Schriftgrößen sind em-Angaben und damit Nachfahren des body. Ich möchte ungern im body die Schriftgröße vorgeben müssen. Die soll der Anwender sich eben selbst aussuchen und der Rest dann relativ dazu hübsch und passend dastehen.

Wie soll es denn logisch sein?

1. Layout-Builder
2. CSS-Reset
sieht mir in allen Browsern kompatibler aus als umgekehrt, wo die Schrift dann größer und unterschiedlicher in den verschiedenen Browsern aussieht.

Warum spielt das überhaupt eine Rolle? Mir ist nicht klar, warum die beiden sich überhaupt beißen.
Das hat übrigens keinen Einfluß auf das oben geschilderte Layout-Problem.





Ich fasse mal Zusammen:
1. Wieso füllen prozentuale Spalten den Container nicht aus?
2. Spielt die Reihenfolge der Framework-CSS Dateien im Seitenlayout eine Rolle? Wenn ja, welche Reihenfolge ist denn die "optimale"?
(Vor allem im Zusammenhang mit der Browserschriftgröße und dessen Einfluss auf em)



Gruß.

[Bennie]

Ich habe mich mit C3 noch nicht so intensiv beschäftigt aber zu den prozentualen Spalten lies doch mal diesen Thread:
https://community.contao.org/de/show...ich-ge%E4ndert

Dort steht u.a.

Vorteil des Holy Grail: Content first.
Nachteil: Es können keine prozentualen Spaltenbreiten verwendet werden!

LG
Bennie

[Toad]

Hallo.

Danke!

Gut, ist eine Behauptung. Gibt es "offizielle" Quellen dazu? Die finde ich nämlich nicht. Ich frag' mal in dem verlinkten Thread nach ...
Grundsätzlich beißt sich so ein Layout nämlich nicht mit prozentualen Angaben:
http://matthewjamestaylor.com/blog/perfect-3-column.htm

Ich bin eigentlich der Meinung, dass prozentuale Spalten doch sehr "responsive" sind. Pixelbezogene überhaupt nicht ... Das klingt sehr nach "halbstarr" oder 2hier und da responsive". Das ist schon sehr irreführend. Wenn es an der Stelle schon hakt, dann muss man sich über grundsätzliche "responsive or not" Diskussionen und Philosophien ja garkeine Gedanken machen. Ist eh alles nicht wirklich responsive. Alle Argumente dafür sind auch welche für prozentuale Spalten. Alle andere dagegen. Keine Möglichkeit für prozentuale Spalten ist dann ein Argument gegen responsive Design.
Damit widerspricht sich der ganze Ansatz und es wäre wohl besser komplett darauf zu verzichten als den Anwender zu verwirren.

Hmmm.


Jahrelang war alles OK und ich konnte unerwartete Ergebnisse an mir und meinenen Erwartungen festmachen. Aber seit 3.x stehe ich recht oft mit realistischen Erwartungen im Regen. Wegen dem streng logischen Ansatz und dem dadurch Erwartbaren habe ich mich seinerzeit für typolight entschieden.

[BugBuster]

Das Problem ist, wenn man den Layoutbuilder benutzt um die Spalten zu defnieren.
Der sorgt auch im Hintergrund dafür, dass die Holy Grail Berechungen erfolgen, und das geht nur mit Pixeln.

Ich bin der Meinung, wer Prozent Grid will, soll es nehmen, aber dann die Spalten selber bilden damit.
Da bringt natürlich andere Umstände mit sich, je Spalte muss nun ein Artikel angelegt werden, wodurch man auf einer Seite dann immer mehrere Artikel hat die man dann mit Grid Klassen belegt.

Eine Kombination von Layoutbuilder Spalte und Grids hat Leo mal demonstriert, ich habe da auch schon experimentiert, bin aber noch aus Zeitgründen noch nicht durch, auch weil ich ein 16er Grid System nutze.
http://contaogrid.glen-langer.de/contao-3-grid.html

Die Komination Layoutbilder und Prozent Grid habe ich noch nicht untersucht, das folgt dann irgendwann mal. Praktisch wäre es, aber bisher bin ich in Contao 2 auch ohne die Spalten per Layout ausgekommen.

[Toad]

Im Grunde gebe ich dir da Recht.

Es geht aber auch ohne Pixel: http://matthewjamestaylor.com/blog/perfect-3-column.htm
Nach wie vor.

Ich bin der Auffassung, dass man sich nach dem Besucher richtet, aber eben das Design als ganzes übermitteln können soll. Sozusagen eine Win/Win-Situation. Der Besucher hat ein Betriebssystem, einen Monitor (leider damit auch verschiedene DPI, vor allem Mobile sind da ja mit deutlich höheren Werten unterwegs) und einen Browser mit irgendeiner definierten Schriftgröße. Ich fände eine nahezu fixe Hauptspalte in % max/min in px/em) mit Spalten in % (ebenfalls max/min in px/em) am flexibelsten. Es ist ja auch nicht immer Text drin, der mit em dann wohl besser bedient wäre. Wenn ich Spalten weglaasse, verschwende ich auf großen Monitoren Platz, Die Breite kann dann der Lesegewohnheit nicht entsprechen. Wer will denn schon eine neue Zeile 20-30 cm weiter links wieder suchen? Feste Spaltengrößen sind mir dann aber zu inflexibel. Links und rechts gähnende leere und in der Mitte ein (relativ) dünner Streifen text ist es ja auch nicht. Diese Mammutspalten würden auf kleinen Displays ja auch nach unten wegbrechen, selbst wenn da nur ein Hintergrundbild, kleine Bilder o.ä. unwichtiges wie ein Chat drin ist.

Wenn das einzige responsive an dem neuen Layout ist, dass die Spalten sich irgendwann nach unten verabschieden, dann ist das nicht viel. Dann könnte man es vielleicht SEO-friendly nennen, weil die Hauptspalte an erster Stelle im HTML steht. Ansonsten ist es nicht responsiver als das Alte. Es ändert nichts daran, dass ich für verschiedene Geräte verschiedene Seiten gestalten muss.

Mich stört eben, dass in einem default-layout diese Beschränkung besteht. Vor allem wenn es sich responsive nennt. Da erwartet man dann schon, dass es möglich wäre. Und im Grunde ist es das auch, wie der Link oben zeigt.

Na ja, was soll 's. Muss ich den layoutbuilder eben raus schmeißen, damit ich responsive designen kann. Das enttäuscht mich etwas ...

[BugBuster]

Es geht aber auch ohne Pixel: http://matthewjamestaylor.com/blog/perfect-3-column.htm
Nach wie vor.

Das sieht mir aber dann doch so aus als wenn das möglich wäre mit contao. wenn man die inside divs da mit einbezieht.
Da werde ich mich mal mit beschäftigen über Weihnachten.

[FloB]

… und dann bitte ein Ticket schreiben

[BugBuster]

Wozu? Contao 3 bringt ja kein prozentuales Grid mit. (Mit gutem Grund? Werden wir sehen,,,)
Es ist davon auszugehen, das man Layoutbuilder Angaben im Kopf der HTML Seite im eigenem CSS überschreiben muss. Das muss man ja jetzt bei der Kombination Pixel Grid und Layoutbuilder auch schon.

[Toad]

Übrigens: Die Sache mit der Schriftgröße und Reihenfolge der Dateien im CSS-Framework ist immer vorhanden wenn man die Browsereinstellung nicht direkt im body überschreibt.

CSS-Reset zuerst = größere Schriften
Layout-Builder zuerst = kleinere Schriften

Was soll das? Und warum überhaupt? Ist da nicht zu viel im Layout-Builder was da nicht reingehört, wenn es Schriftarten beeinflußt? Oder wie passiert das dann?


Ich werde auch über Weihnachten noch eine Menge experimentieren. Kämpfe derzeit damit, dass das neue Layout ein wenig empfindlich auf Margin/Paddings im Bereich #left, #main, #right, sowie .inside reagiert. Das war mal universeller, stabiler und einfacher zu handhaben. Früher war mit einem css-Statement schon viel Default-Aussehen gesetzt. Nun zerfledere ich mit dem gleichen Ansatz das Layout.

Die Vorhersagbarkeit des Ergebnisses der CSS-Statements im Bereich der Layout-DIVs ist irgendwie gesunken, behaupte ich mal einfach so.

[FloB]

Wozu? Contao 3 bringt ja kein prozentuales Grid mit. (Mit gutem Grund? Werden wir sehen,,,)

Wurde nicht offiziell kommuniziert, dass prozentuale Spaltenbreitenangaben nicht mehr möglich sind? Dann sollte man ein entsprechendes offizielle Gegenstatement veröffentlichen.

[Toad]

Ich experimentiere gerade mit dem Grahl. Möglich ist es. Soviel kann man sagen. Warum es nicht im Layoutbuilder implementiert ist wird sich zeigen.
Jetzt müsste ich nur mehr Zeit haben. Wird vor dem WE wohl nichts. Hab allerdings ein Gesamtkunstwerk im Sinn, dass nach meinem Verständnis universell genug ist. Kann es ja dann als Theme anbieten. Oder besser ein ThemeTemplate.
Es wird mit zentriertem Topmenü und Submenü im #main daherkommen und je nachdem wie man die NavModule konfiguriert kann es auch verschachtelte Menüs anzeigen. Das Menü ist schon fertig und Recht simpel und verständlich, übersichtlich und verständlich.
Das Topmenü ist mit den runterrutschenden Spalten beim Holy Grail ideal und platzsparend. Durch die Zentrierung immer über dem Hauptteil und prozentuale Spalten irritieren dann nicht.

Aber die müssen ja erstmal prozentual werden ...


Gesendet von meinem HTC Desire S mit Tapatalk 2

[BugBuster]

Das es nicht geht ist nur die halbe Wahrheit.
Der Layoutbuilder erkennt, wenn jemand die das Contao Core Responsive Grid einbindet und macht in dem Fall und das jemand Spalten definiert eine Sonderberechnung damit das Holy Grail wieder stimmt.
Quasi das was Leo als Beitrag auf Contao.org gepostet hat, wie man das kombiniert, macht der Layoutbuilder mittlerweile automatisch.
Der kann aber nur mit seinem eigenem Pixel Grid umgehen.

Nimmt man ein eigenes, wie z.B. mein 1140er mit 16 Spalten, geht das schon nicht mehr automatisch und man muss selber Hand anlegen. Bei prozentualem Grid natürlich erst Recht.
Ich denke mal, daher kommt die Aussage, mit Prozent Grid gehts nicht.
Mit allerneusten CSS3 Features könnte man da noch etwas automatisieren, sofern ich das richtig verstanden habe, kann man mit CSS3 auch rechnen :-)

Aber es gibt sicherlich noch eine andere Möglichkeit, wie Toad ja wohl schon getestet hat.

[FloB]

… sofern ich das richtig verstanden habe, kann man mit CSS3 auch rechnen

property:calc(15%-3px);

(jetzt mal so aus dem Kopf)

Ist sogar relativ gut implementiert (tlw. mit Prefix): http://caniuse.com/#search=calc

[Toad]

Ich muss nochmal nachhaken wegen der reihenfolge der Framework-CSS Dateien (cccreset, layoutbuilder) und den unterschiedlichen Schriftgrößen.
Kennt niemand das Problem?

[Toad]

Komisch. ich verstehe nicht warum ich der Einzige binb der sich wundert.

in der layout.css findet sich folgendes:

/**
 * Fix some font issues
 */
body {
    font-size:100.01%;
}
select,input,textarea {
    font-size:99%;
}

Was hat das da drin zu suchen?
1. "fixed" es nichts was mit dem layout zu tun hat, zweitens beißt sich das mit der reset.css


Hä????

[plastiko]

in der layout.css findet sich folgendes:

/**
 * Fix some font issues
 */
body {
    font-size:100.01%;
}

Das ist ein alter Bug-fix bei Schriftvergrößerung im IE6. Eigentlich würden 100% reichen. Die .01% wurden hinten dran gehängt um einen anderen Bug in sehr alten Operas zu umgehen.

[Toad]

OK.

Gehört das dann nicht in die reset.css?


Im Firefox ändert sich dadurch nämlich was. Die Reihenfolge von reset.css und layout.css ist nicht beliebig. Die beiden passen nicht zueinander.


Hat das wirklich noch niemand bemerkt?

[plastiko]

Gehört das dann nicht in die reset.css?

Ich denke sowas sollte jeder selbst in sein css schreiben oder ebend nicht.
Der IE6 wird doch auch sonst nicht mehr unterstützt.

[Toad]

Es ist aber im layoutbuilder ...

[Toad]

Aber wieder zurück zum holy grail.

Der Haken an den Layouts von http://matthewjamestaylor.com/blog/perfect-3-column.htm im Gegensatz zu denen in contao ist, dass diese nicht ab einer bestimmten Größe (Verkleinerung, Body-min-width) untereinander flutschen. Ich denke aber, dass das noch zu machen ist. Ausserdem denke ich eher daran den contao-layoutbuilder zu benutzen und darin prozentuale Spalten zu realisieren.

Prozentual wäre das. mit zwei divs mehr im template und ohne layoutbuilder, dafür einer layout.css

Ich hänge das bisherige mal an. Für heute reicht es. WE kommt ja bald.
Im Grunde ist das so Käse und nicht im Sinne des Erfinders. Ein erster Entwurf am contao-Layoutbuilder vorbei und noch weniger responsiv. Das Gegenteil ist das Ziel.

Bildschirmfoto5.png

[BugBuster]

Per Default, mal ausgehend von der Demo und aus vergangenen Zeiten, wird die reset aber nicht verwendet.
(das grid und das reset dazu musste man sich für die C2 selber downloaden)

Nimmt man ein Grid, dannn auch reset aber nicht den Layoutbuilder. (ich will ja gridden, warum sollte ich das doch wieder mit dem Layoutbilder machen)

Die ganzen Probleme die Ihr hier habt treten nur auch wenn man alles nimmt und sich nun wundert, warum das nicht geht. So ist das ebend nicht konzipiert.
Dann muss man halt damit leben und sich anpassen. Man kann es nicht jedem recht machen.

[Toad]

Ich möchte bloß den Layoutbuilder fürs Layout und die reset.css fürs reseten nutzen.

Der Layoutbuilder fuchtelt aber an Schriften rum. Was auch immer das mit dem Layout zu tun hat.
Die reset.css soll doch bloß für browserübergreifende Gleichheit sorgen.
Die layout.css fürs layout.

Ich möchte garkein Grid. Nutze diese css auch nicht. Ich möchte bloß ein prozentuales Layout mit spalten die, wenn eine gewisse min-Breite erreicht ist unter #main klappen. Layoutbuilder, aber mit prozentualen Spalten.

reset und layout hat meines erachtens nichts miteinander zu tun. warum soll man die nicht kombinieren können? oder anders: Ist es nicht Sinnvoll die reset.css vor jeglichem layout nutzen zu können? Oder noch anders: Was fuchtelt die layout.css denn an Schriften rum, die eine reset.css wieder gerade rücken muss, bzw. warum verbiegt die layout.css Schriftgrößen die vorher mit der reset.css geradegerückt wurden?
Zumindest was die Schrift angeht, leuchtet mir die gegenseitige Beinflussung nicht im geringsten ein.

Insgesamt neige ich bei solchen Ungereimtheiten dazu weder layoutbuilder noch reset, noch irgendetwas von contao für das Layout zu nutzen wenn sich darin kein Sinn erkennen lässt. Das führt in die Irre und verschwendet Zeit.

[electricarts]

Hallo Toad,

dann nimm doch den gesamten CSS Part aus Contao raus und nutze es „nur“ für den Inhalt. Dafür ist meiner Meinung nach ein „Content Management System“ ja auch da. Heißt ja auch nicht „Layout Management System“.

Binde den gesamten CSS Part selbst ein (zumindest ein gutes CSS Framework was im Bereich responsive alles richtig macht gibt es ja) und ändere evtl. die fe_page entsprechend ab.


Viele Grüße


Mario

[Toad]

Klar kann ich alles weglassen. Ich kritisiere hier aber Bestandteile. Wir sind zwar alle hier Lösungsorientiert, aber den Gegenstand der Kritik weglassen, bzw. ignorieren ist eine sehr universelle Lösung. Das gilt ja immer.

Wenn man Armut in der Welt kritisiert wäre die Lösung auch anwendbar. Einfach ignorieren. Mit der Kritik will man aber doch am Gegenstand dieser Kritik arbeiten. Zunächst darüber reden. Meinungen austauschen und das Ganze dann auf einen besseren Weg bringen.

Der Gegenstand der Kritik ist eben: Die beiden css-Dateien. Nicht akzeptierte Lösung: weglassen.
Ein gutes Beispiel ist das Breadcrumb-Modul. Ansetelle der einfachen Äanderung auf das alte Modul wird ständig rumdiskutiert, ebenfalls in Richtung weglassen, ignorieren, Extension nehmen, ...
Das ist doch eine sehr konservative Einstellung. Der Tst-Zustand gilt als heilig und es dreht sich um Argumente, warum das so ist und verteidigt das dann? Mit dem Ergebnis, dass man es doch weglassen kann?

Klar. Kann man. Und das Posten hier kann man sich auch sparen. Dann ist und bleibt die heile Welt rund.

[electricarts]

Hallo Toad,


das hat nichts mit Resignation oder konservativ sein zu tun. Es wurde eben beschlossen, dass Contao einen Layout-Part hat. Und leider verfolgt Contao hier, wie viele andere Frameworks meiner Meinung nach auch, den falschen Ansatz. Aber ich denke nicht, dass sich daran mittelfristig was ändert.

Also bleibt nur, diesen Layout-Part komplett abzuschalten, um nicht mit anderen Frameworks zu kollidieren. Ich setze Contao ein, weil es für mich das beste CMS am Markt ist. Für die Layouterstellung (also einen Teil davon) gilt das nicht. Also lasse ich den weg. Welche Alternative kann es dazu noch geben?


Viele Grüße


Mario

[Toad]

Irgendwie wahr. Aber traurig.

[karo]

hallo!

ich häng mich mal hier an. hab ebenfalls problem mit dem holy grail - prinzip und bin mir nicht sicher wie ich es lösen soll
mein Design schaut so aus:

- Header: Logo + Menu
- Links : Untermenu
- Main: Inhalt
- Footer

ich wollte links+main prozentual einstellen was ja sinnvoll ist wenn man das ganze fluid gestalten möchte
es geht schon, aber nicht besonders gut. und es haut irgendwann das layout zusammen.
ich versteh nicht warum das nicht vorgesehen ist >> vor allem wenn das nicht geht dann sollte es auch die auswahl prozent nicht geben.
(hier gehts dann erstmal um desktop bildschirme und ipads - bei kleineren geräten muss ich mir dann was anderes überlegen > navigation zum aufklappen oder ähnliches >> jedoch sollte es erstmal auf großen geräte fluid sein - und das funktioneirt nicht)

ich finds richtig schwierig die probleme niederzuschreiben.

eines ist zb: dass wenn mein linker bereich 21% ist
dann passt das #left {margin-left:-100%;} nicht, was von contao gegeben wird. wenn ich es umschreibe auf "-112%" passts ein bisschen besser.
ein gröberes problem hab ich mit dem max-width vom container > der schlägt nicht an (im header funktioniert er)
(und ja ich brauchs extra beim container, header, footer - weil der footer 100% sein muss)

wie könnte ich das ganze sonst lösen??
das Layout hat nicht immer links die navigation (kanns also nicht direkt ins template in ein div reinpacken)

sehr verwirrend das ganze
viell könnt ihr es für mich etwas entwirren... =)

lg karo

[BugBuster]

Prozentuales Layout + Contao Holy Grail (Layout Builder) ist nicht möglich. Zumindest habe ich ohne Core Anpassung bzw. ohne per CSS "drüber-zu-patchen" noch nichts hinbekommen.
Das heißt aber nicht, das es nicht geht, nur wie hier schon erwähnt, muss das Layouten dann selber getan werden.

Wenn ich diese Anleitung hier sehe, fehlt es Contao an einem DIV im FE Template, dann könnte es gehen. (vom Prinzip her)
http://matthewjamestaylor.com/blog/perfect-3-column.htm

[karo]

hey! danke für den tipp!
hat geklappt!!! =))))
sehr cool...
das wär doch was fürs contao-core?

[BugBuster]

Kann man deine Umsetzung irgendwo sehen?

[Andreas]

OK.

Gehört das dann nicht in die reset.css?

Im Firefox ändert sich dadurch nämlich was. Die Reihenfolge von reset.css und layout.css ist nicht beliebig. Die beiden passen nicht zueinander.

Hat das wirklich noch niemand bemerkt?

Hi Toad,

habe ich jetzt erst entdeckt, ich sehe das so ähnlich wie du. Ich hab das mit den Schriftgrößen erst jetzt entdeckt.


Ja, die logische und natürliche Reihenfolge sollte so sein

1. reset.css - Auffangen von Browserunterschieden und um eine Basis für mein CSS zu schaffen
2. layout.css - schafft die header, footer und Spaltendarstellung stabil in allen Browsern
3. grid.css - bietet die Möglichkeit Bereiche in Spalten aufzuteilen
4. form.css - erleichtert das schwierige Gestalten von Formularelementen browserübergreifend
5. mein.css - custom Design

Wenn überhaupt, gehört font-size: 100% ins reset, kann man sich auch ganz sparen, 100.01% ist alter Quark.

font:12px/1 "Lucida Grande","Lucida Sans Unicode",Verdana,sans-serif;
gehört nicht ins Reset, sondern in mein.css (habe ich bei mir noch nie gesehen, da das ja wieder von layout.css überschrieben wird.)

color:#000;
Gehört ins reset, dann aber auch background-color:#fff, für Leute, die mit einem schwarzen Theme mit weißer Schrift in Windows unterwegs sind, die sehen sonst nämlich nichts.

Das gallery-CSS gehört auch nicht ins layout.css, aber ich kann Leo F. verstehen, er wollte wohl nicht zu viele CSS-Dateien anbieten.

Ich finde die Holy-Grail-Lösung auch nicht gut. Jetzt kann man kein Submenu mehr in die linke Spalte machen, es sei denn, es ist einem egal, dass das Submenu unter dem Inhalt kommt. Die Holy-Grail-Lösung von YAML finde ich übrigens viel stabiler und einfacher zu formatiern als die von Alistapart. Die geht übrigens auch mit px oder %. Außerdem könnte man ja auch direkt gleich lange Spalten machen, wie mit den Equal Heights Grids von YAML.

Ich hatte das mal angebracht, dass man die 3 Spalten nicht left, right und main, sondern 1,2 und 3 nennt und dann im Layout auswählen kann, welches die Hauptspalte die linke und die rechte ist. YAML macht das auch so, ich finde das macht Sinn. Früher war mir egal, in welcher Reihenfolge die im Quelltext stehen, aber auf nem Smartphone finde ich das schon wichtig was zuoberst und zuunterst kommt, je nach Projekt bzw. Design.

Das Pixel basierte Grid finde ich auch nicht gut, da es 2 unterschiedliche max-Breiten anbietet, je nachdem wie breit das Browserfenster ist. Am besten wäre, ich gebe ne feste max-Breite für mein Layout an und wenn der Viewport kleiner ist, schiebt es sich halt zusammen und die Grid-Spalten (oder auch die Layoutspalten) passen sich dann prozentual an, bis sie auf Smartphones untereinander erscheinen.

Ich hatte mir vor ein paar Monaten das Grid von Contao mal auf Prozent umgeschrieben und nur mit einer max-Breite, hatte ich aber noch nicht im Einsatz. Sag Bescheid, falls du es mal sehen möchtest, dann werde ich mal auf die Suche gehen.

Wie man sieht, ist noch einiges im Argen mit dem Contao CSS, das hängt hauptsächlich mit den komplizierten Berechnungen für das Layout zusammen. Meiner Meinung nach sollte man ganz auf die Angabe von Breiten und Höhen im Layout verzichten. Da kann man lieber eine oder mehrere vorgefertigte CSS-Dateien anbieten, die man sich dann anpassen kann. Man muss ja sowieso das CSS bearbeiten.

[Spooky]

Der Layout Builder ist ohnehin nur ein "Zusatzfeature" von Contao, dass einem nicht so versierten Entwickler den Aufbau einer Seite vereinfachen und verschnellern soll. In so fern kann dieses Feature auch nicht ideal für jeden erdenklichen Einsatz gemacht werden. Wenn man gewisse Dinge wie prozentuale Spalten (wofür man sowieso von Haus aus kein Holy Grail Layout braucht, auch wenn man content first haben will) oder kein Responsive Layout haben will, oder überhaupt irgendetwas haben will, dass von jeglicher Norm abweicht, muss man eben auf den Layout Builder von Contao verzichten und es ganz einfach selbst umsetzen.