CSS: .widget_container .widget_container

[JNK]

Hallo zusammen,

hat jemand eine Ahnung, was das tut? Abgesehen davon, dass es Ärger macht, wenn man colspan innerhalb von Groups benutzen will oder Elemente in Groups nebeneinander setzen möchte?

Ich habe das jetzt im pure und im pitchblack ausprobiert und kann keine negativen Auswirkungen feststellen, wenn ich das einfach lösche...

Gruss,

der Jan

[Chris M.]

Hm, auf einen .widget_container in einem .widget_container reagieren?

[JNK]

Ja, das ist mir klar. Aber mir ist kein Unterschied im Ergebnis aufgefallen, ausser innerhalb von groups. Und da hat das eher kontraproduktiv gewirkt, weil es Einspaltigkeit innerhalb einer group erzwingt. Wenn man das weglässt, kann man wunderbar groups mit Spaltenbreiten versehen und darin auch mehrere Widgets nebeneinander setzen.
Gruss,

der Jan

[Chris M.]

Die Einspaltigkeit in der Groups war genau das Ziel, warum ich das eingebaut hatte.

Es stammt aus Zeiten des harten zweispaltigen Designs. Und da hatte .widget_container bewirkt, dass das Widget eine Spalte = halber Bildschirm breit war. Hat man nun ein Group, dann wäre es im Group auch nur halb breit gewesen => In einer Group hätte es ohne diese Regel zwei Spalten = 1/4 Bildschirm gegeben.

Fazit:
Wenn Du das mit colspan anders lösen kannst, kannst du diese CSS-Regel ruhig entfernen.

[JNK]

Das lässt sich natürlich relativ einfach lösen, wenn Gruppe und widget nur "colspan0" gross sind. Etwas schwieriger wird es, wenn die Gruppe z.b. colspan9 (also 75%) der Seitenbreite gross ist. Wie gross sollen dann die Widgets darin sein?

Im Prinzip ist das im Augenblick so:

Ich mache eine Gruppe mit z.B. colspan6, dann ist die 50% der Bildschirmseite gross. Ein Widget mit colspan6 da drin ist dann 25% der Seite gross, eben 50% der Gruppe. Verpasse ich dem Widget colspan12, ist das Widget wieder 50% der Seite gross.

Das ist zwar eigentlich ganz einfach, aber vielleicht nicht so gut zu verstehen. Auf der anderen Seite, ist es vielleicht der Weg, um dem Editor vernünftig die Gruppen beizubringen: Er sollte eine Gruppe einfach als Sub-Page verstehen, mit denen kann er ja auch umgehen. Faktisch werden sie von der templateenginge ja auch so behandelt, was die Nummering der Pfade angeht z.B.

Gruss,

der Jan

[Chris M.]

Jetzt muss ich nochmal wiederholen, dass ich mir den Colspan-Code noch nicht angesehen habe...

Naiv wäre ich davon ausgegangen, dass eine Group so viele Spalten enthält, wie sie selbst breit ist.
D.h. eine Group mit colspan6 hat eine halbe Seite. Und ein Widget mit colspan6 da drinnen nimmt die ganze Breite der Group ein - also auch 50% der Seite.

[JNK]

Ich teste noch, aber ich denke, ich habe die Lösung gefunden. Widgets sind jetzt immer exakt gleich breit, egal, ob sie in eine Gruppe stehen oder nicht, d.h. ein colspan6-Widget hat immer die halbe Bildschirmbreite, ein colspan1 immer 1/12 der Bildschirmbreite.

Einzige Einschränkung, und da weiss ich nicht so recht, wie es dnen werden soll:

Wenn die group padding oder margin hat, ist in einer halb-seitigen-Gruppe weniger Platz als 1/2 Bildschirmbreite. Wie soll es sich denn da verhalten?

Um das Problem zu präzisieren: "width" in % bezieht sich immer auf das Eltern-Element. "width" in px ist absolut. Bei width in % taucht eben o.g. Problem auf, dass in einer Gruppe 50% etwas anderes ist als ausserhalb einer Gruppe. In px gibt es das Platzproblem, wenn die Gruppe paddings oder margins hat.

Es ist KEIN Problem, das einmalig beim Aufruf richtig zukriegen, das kann man perfekt ausrechnen. Etwas schwieriger wird es, wenn man das dynamisch anpassen möchte, weil dann die px bei jedem Resize neu berechnet werden müssen. Das ist gloabl unproblematisch, schwieriger ist es eben bei geschachtelten Elementen variabler Breite.

Hinzukommt: Was ist denn richtig? Beispiel:

Angenommen ich habe ein prinipiell 4-spaltiges Design und eine Breite von 1200px, das heisst ein Element sind 25% oder 300px.

Jetzt mache ich eine Gruppe mit colspan9 (also 75% Bildschirmbreite oder 900 px).

Wie breit ist jetzt ein "normales" Element?

Ausserhalb der Gruppe wäre es 300px breit. Dann hätte ich innerhalb der Gruppe ein 3-spaltiges Design.

Behalte ich 4-spaltig in der Gruppe bei, dann wird es 225 px breit. Das sieht dann etwas seltsam aus, wenn die Gruppe über oder unter drei normalen Widgets platziert ist.

Comments?

Gruss,

der Jan

[Chris M.]

Es ist KEIN Problem, das einmalig beim Aufruf richtig zukriegen, das kann man perfekt ausrechnen. Etwas schwieriger wird es, wenn man das dynamisch anpassen möchte, weil dann die px bei jedem Resize neu berechnet werden müssen. Das ist gloabl unproblematisch, schwieriger ist es eben bei geschachtelten Elementen variabler Breite.

Daher Vorsicht bei Pixel-Genauen Layouts. Und mein Wunsch nach dem calc()...

Hinzukommt: Was ist denn richtig?
[...]
Comments?

Angenommen (dürfte ziemlich Worst-Case sein) man hat ein Group über 3 Spalten mit drei 1-spaltigen Widgets drinnen. Genau so sind 1-spaltige drüber und drunter.
Außerdem angenommen, das Design lässt zwischen den Widgets nicht genug Platz, dass der Group-Rahmen kostenlos reinpasst (alternativ: wir haben so viele Groups ineinander geschachtelt, dass der Platz ausgegangen ist).

Spontan fallen mir zwei Lösungen ein:

• Alle internen Widgets werden etwas schmaler
  => Die Trennung zwischen den Widgets passt nicht mehr zu denen da drüber und da drunter
• Nur das linkeste und rechteste innere Widget wird etwas schmaler
  => Die Trennungen passen, aber die Widgets sind nicht mehr gleich groß

=> Beides mal mehr oder weniger doof


Wenn keiner eine gute Idee hat, würde ich fast zur aufwändigsten zu implementierenden Lösung raten: beides. Jedes Design darf sich dann aussuchen, was am besten passt.

[greentux]

btw... kann man Groups in Groups mittlerweile als "supportet" ansehen? Ich erinnere mich, das es bei mir zwar im Grunde funktioniert hat, Chris doch aber meinte, das das eher Zufall war

[Chris M.]

btw... kann man Groups in Groups mittlerweile als "supportet" ansehen? Ich erinnere mich, das es bei mir zwar im Grunde funktioniert hat, Chris doch aber meinte, das das eher Zufall war

Ist von mir ungetestet...
Und so lange der Editor keine Groups kann, sind die Unsupportet - erst recht die Schachtelung.

Aber Ziel ist es.

[greentux]

Heisst das, supportet ist nur, was der Editor kann?

[Chris M.]

Heisst das, supportet ist nur, was der Editor kann?

Tja, was ist "supportet"?

Offiziell supported wird beim Release(!) nur das, was auch der Editor kann.

Denn für alles andere braucht man mehr oder weniger Expertenwissen.
Ziel ist aber natürlich alles was geht auch im Release verfügbar zu machen - aber wer das SVN nutzt, muss halt leidensfähig sein....

[greentux]

Ich trenne für erstmal Visu und Editor. Von daher ist "supportet" für mich, was halt auch per xml geht...
Vermutlich steigt die Zahl der SVN Nutzer täglich an, während die Releaseanwender weniger werden

[Chris M.]

Von daher ist "supportet" für mich, was halt auch per xml geht...

Nach dieser Definition ist alles im SVN immer supportet, Ausnahmen bestätigen diese Regel.

Alles was man in's SVN eincheckt sollte lauffähig sein. (Und mindestens nichts kaputt machen...).

Für die Groups-im-Group heißt dass, entweder es ist supportet oder ein Bug weil's nicht unterbunden ist oder ein Bug weil's nicht funktioniert. Im SVN muss man immer mit Bugs rechnen - wer das nicht will, muss auf's Release warten...