Neues Feature: colspan/rowspan

[makki]

Könnte man einen Build machen, der das so macht und das dann testen?

"svn checkout" oder "svn up" ?
Das ist hart, ja. Aber selbst mir fällt es schwer da immer dranzubleiben, da wird halt entwickelt - und das ist auch gut so, ein Release wäre schön und ich gehöre sicher zu denen die das am meisten wollen aber derzeit ist höchstens mit einem "diese config funzt mit diesem #svn" geholfen
Chris&Jan sind da aktuell zu schell, da gibts 20 neues bevor ich gucken kann

Makki

P.S.: ein Release anzustreben, also Feature-freeze, wär aber schon mal wieder an der Zeit, ich würde vorschlagen Chris' Planet und colspan/rowspan zu settlen und dann raus damit, es wurde eine ganze Menge erreicht!

[Chris M.]

Ich hatte das erst so (fest berechnet in px), aber das ist nicht ganz trivial, weil es bei jedem Window-Resize neu berechnet werden muss. Und es gibt ein Problem innerhalb von Groups, die nicht "no widget" sind, weil colspan hier anders breit sein muss als ausserhalb, weil sonst die Elemente nicht in die Group passen.

Die Frage ist, wieviel Rechenpower wir auf den Clients haben, wenn es kein Problem ist, einmla komplett das DOM durchzupflügen, würde ich stark für "colspan wird mit festen px berechnet und beim resize angepasst" plädieren.

Ich denke man darf davon ausgehen, dass die Systeme deren Window Resizebar ist auch ausreichend Rechenpower haben. Bei Mobil-Geräten ist ein Resize (abgesehen vom initialen) eher selten...

Das mit den Groups ist aber natürlich so eine Sache. Wenn man sich z.B. die bei Planet ansieht ist da links und rechts Dekoration, die zulasten einiger oder alle Sub-Elemente gehen muss.
Hier dürfte IIRC auch noch nicht geklärt sein, ob die Widget-Trennung in den Groups sich dem globalen annähern sollen (zu Lasten der linken und rechten Spalte) oder auch gleichmäßig verteilt sein sollen.

Und wenn das geklärt ist: es gibt ja auch Groups in den Groups...

[greentux]

Könnte man einen Build machen, der das so macht und das dann testen?

[JNK]

colspan: Das ist in der Tat ein Problem. Bei mir sind 1/12 137px, 1/6 aber 275px, macht auf eine ganze Seitenbreite dann halt 3px Unterschied. Fest berechnete colspans häten das Problem nicht und würden dann rechts (oder links) entsprechend ein paar Pixel leeren Raum haben-

Ich hatte das erst so (fest berechnet in px), aber das ist nicht ganz trivial, weil es bei jedem Window-Resize neu berechnet werden muss. Und es gibt ein Problem innerhalb von Groups, die nicht "no widget" sind, weil colspan hier anders breit sein muss als ausserhalb, weil sonst die Elemente nicht in die Group passen.

Die Frage ist, wieviel Rechenpower wir auf den Clients haben, wenn es kein Problem ist, einmla komplett das DOM durchzupflügen, würde ich stark für "colspan wird mit festen px berechnet und beim resize angepasst" plädieren.

Gruss,

der Jan

[Chris M.]

Ah danke, damit geht's. Seit Revision 874 wird's nun auch in der Demo-Config verwendet

PS: Was man leider gut sehen kann, ist dass es noch leichte Darstellungsprobleme durch margins und/oder Rundungseffekte gibt, da je nach Anzahl der Elemente pro Zeile diese in Summe unterschiedlich lang sind.
Für'n rowspan hab ich's im Code bereits gefixt (Revision 873)

PPS: Im Rahmen vom Planet-Design habe ich auf die harte Tour gelernt, was man eigentlich auch hätte lesen können: Benutze nie das Style-Attribut der HTML-Elemente. => Evtl. hier die width:...% in colspan-Klassen ändern?

[JNK]

Nachtrag:

A1 B1 C1 
A1  X C1 
A1

Das nächste Element würde nicht mehr rechts passen (weil wir nur drei Spalten haben. Wenn das zwei hoch ist, dann sieht das so:

A1 B1 C1 
A1  X C1 
A1 C2
X  C2

Und entsprechend zwei weitere:

A1 B1 C1 
A1  X C1 
A1 C2 B2
X  C2 C3
X  X  C3

Jeweils die X gehen nicht. Mit eine colspan1, rowspan 3 Gruppe als zweites Element hinter A1, die B1 und C2 enthält, sollte es aber möglich sein, sowas zu machen.

A1 B1 C1 
A1 C2 C1 
A1 C2 B2
C3
C3

Damit man den "Trick" nicht sieht, habe ich das "nowidget" in die Groups eingefügt, dann sollten die nur Gruppieren und keine Rahmen malen.

Gruss,

der Jan

[JNK]

Hallo Jan,

mit Revision 863 habe ich der Demo-Seite mal eine colspan/rowspan-Subseite spendiert. Dabei habe ich leider merken müssen, dass ich gerade die Verwendung des rowspans noch nicht ganz verstanden habe (oder dort ein Bug ist):
Ich wollte in dem unteren Teil die gleiche Struktur wie oben bei den colspans als rowspan (d.h. gedreht) implementieren - aber bekomme das nicht hin...

Kannst Du mal schaun?

Ich sehe was Du meinst, und es gibt keine (einfache) Lösung dafür. Das liegt an der automatischen Platzierung: DIVs werden immer soweit links wie möglich und so weit oben wie möglich platziert, d.h. (dreispaltig, wegen der Übersicht)

A1 B1 C1 
A1  X C1 
A1

der mit X markierte Platz ist für die Platzierung für immer verloren. Deswegen kannst Du nicht das 2. rowspan6 "vor" dem zweiten rowspan4 platzieren, die zwei Reihen sind verloren. Auf der anderen Seite kannst Du nicht das zweite rowspan6 vorher platzieren, weil ja rechts davon noch genug Platz ist.

Du müsstet nowidget-Groups darumbasteln, dann könnte es klappen.

Gruss,

der Jan

[Chris M.]

Ich hatte mich mal daran versucht, aber dann war nochmehr kaputt als vorher. Steht das bei irgendjemandem auf der ToDo-Liste?

Ja, stand auf meiner, die hab ich aber irgendwo verloren (klingt besser als vergessen/verdrängt...) - ist jetzt in Revision 866 gefixt.

[ctr]

Ah, da muss die XSD wohl noch angepasst werden...

Ich hatte mich mal daran versucht, aber dann war nochmehr kaputt als vorher. Steht das bei irgendjemandem auf der ToDo-Liste? Vor der Syntax-Änderung funktionierte es wunderbar :-(

[JNK]

Gucke ich mir morgen an.

[Chris M.]

Hallo Jan,

mit Revision 863 habe ich der Demo-Seite mal eine colspan/rowspan-Subseite spendiert. Dabei habe ich leider merken müssen, dass ich gerade die Verwendung des rowspans noch nicht ganz verstanden habe (oder dort ein Bug ist):
Ich wollte in dem unteren Teil die gleiche Struktur wie oben bei den colspans als rowspan (d.h. gedreht) implementieren - aber bekomme das nicht hin...

Kannst Du mal schaun?

[Chris M.]

Nur?!?!!?!?? - Du hattest eine ungültige XML-Datei erzeugt, es hätte die Welt untergehen können!

Jetzt sollte so ein Fehler besser angezeigt werden

[Chris M.]

gelesen, das die SVN Version grundsätzlich auch länger "broken" sein kann.

Der Editor: ja - was aber weniger am Editor selbst als an mangelnden Entwickler-Ressourcen liegt.

[greentux]

Ok dann passt das ja. Ich habe nur schon hin und wieder, vermutlich nicht von Dir, gelesen, das die SVN Version grundsätzlich auch länger "broken" sein kann.
Also wenn SVN grundsätzlich ok siehts doch ganz gut aus.

[Chris M.]

Es würde jedenfalls auch dem "release often, release early"-Grundsatz etwas bringen, der vielen anderen OSS-Projekten hilft, frühzeitig auch unbedarften Nutzern eine SW an die Hand zu geben, die dann ausführlicher getestet werden würde.

Hast Du hier - das ist die SVN Version.

Anspruch an SVN ist immer, dass es grundsätzlich läuft, sonst sollte nicht commitet werden. (Seltene und bewusste) Ausnahmen werden hier vorher angekündigt - und wenn's schief gegangen ist, kann man's hier auch meist lesen.