Abschnitt bei zu vielen User-Informationen

Hm, ich find's auch nicht sehr schön gelöst, dass dort einfach alles angezeigt wird. Oder kann man das irgendwo doch konfigurieren?

Nur per CSS anpassen...

Quote from Black Rider

Nur per CSS anpassen...

Ich habe den Eindruck, dass wir uns schon in Beta 7 befinden, aber das halbe System noch gar nicht fertig ist.

Moin,

Quote from Matrikular

Ich habe den Eindruck, dass wir uns schon in Beta 7 befinden, aber das halbe System noch gar nicht fertig ist.

Fertig (nach Woltlabs eigenen Maßstäben) wohl schon. Vieles ist aber nicht richtig bis zum ende durchdacht. Man stößt immer wieder auf Dinge, die umständlich sind, nicht durchgängig in allen Bereichen gleich umgesetzt sind, die nicht wirklich intuitiv sind, bzw. unmittelbaren Feedback nach Funktionswahl vermissen lassen, die auf einmal nicht mehr richtig funktionieren, weil eine 'Rahmenbedingung' durch den User nicht bzw. wegkonfiguriert wurde. Tja...

display: inline-block; wäre für diese Stelle wohl auch angebrachter.

Quote from Matrikular

Ich habe den Eindruck, dass wir uns schon in Beta 7 befinden, aber das halbe System noch gar nicht fertig ist.

Rein technisch betrachtet geht es bei einer solchen Anzeige nicht anders, d.h. es muss einen Maximalwert geben, ab dem sich der Bereich nicht weiter vergrößert. Anders möglich wäre es nur mit JavaScript, der die jeweiligen Höhen von den Einträgen links und rechts vergleicht und dann für die jeweilige Zeile das höhere der beiden angibt.

Was da jedoch sinnvoller ist, liegt auf der Hand, denke ich.
Entweder als sollte man WoltLab das Ändern der Maximalhöhe vorschlagen oder aber ein komplett neues Design. Dieser Beitrag hier gilt indes nur der Information, denn ich habe den Eindruck, dass alles, was ich sonst hier sage, sofort als "von WoltLab" angenommen wird, was nicht der Fall ist.

@InitArt
Grundidee gut, in der Praxis aber nicht umsetzbar. In meinem Fall z.B. hat die Liste eine Breite von 855px, die jeweiligen Listenelemente 50%, macht jedoch 427,5px. Da es keine halben Pixel gibt, wird auf 428px aufgerundet und das jeweils rechte Element passt nicht mehr in die Zeile.

Quote from Black Rider

@InitArt
Grundidee gut, in der Praxis aber nicht umsetzbar. In meinem Fall z.B. hat die Liste eine Breite von 855px, die jeweiligen Listenelemente 50%, macht jedoch 427,5px. Da es keine halben Pixel gibt, wird auf 428px aufgerundet und das jeweils rechte Element passt nicht mehr in die Zeile.

Entweder ich verstehe es nicht oder es ergibt keinen Sinn, worin liegt der Unterschied bei einem float und einem inline-block mit 2 x 50 %?
Mehr oder minder produktives Beispiel: http://codepen.io/InitArt/pen/Jgfhy

Bei float sind die Elemente "lose", d.h. sie können sich überlagern, was hier bei einer ungeraden Zahl auch geschieht. So ist der linke Bereich zu 428px sichtbar, der rechte aber nur zu 427px. Ergibt dann zusammen die veranschlagten 855px.
Bei einem inline-block werden sie jedoch nicht überlagert, wodurch es letztendlich auch nicht passt.

Ich kann es noch immer nicht nachvollziehen, habe es mit dem aktuellen Chrome, Opera 12, FF 23 und IE 10 getestet, die Browser berechnen die Breite richtig.
http://codepen.io/InitArt/pen/lgwAu

Bedenkst du das box-sizing?

Im Chrome lässt sich das wunderbar nachvollziehen, wenn man hier in der Mitgliederliste beide floats entfernt und stattdessen display: inline-block setzt. Bei ersterem zeigt Chrome beide nebeneinander an (erste Breite wird ab-, zweite aufgerundet), bei letzterem untereinander, da sie nicht nebeneinander passen (beide Breiten werden aufgerundet).
Safari wiederum zeigt bei mir in beiden Fällen jeweils zwei Benutzer nebeneinander an, da hier interessanterweise wohl abgerundet wird.

--

Bei deinem Beispiel oben sind im Safari übrigens in der ersten Zeile beide 427px breit, stattdessen habe ich rechts einen Pixel nichts (Hintergrund von .row auf grün macht mir einen weiteren, grünen Rand ganz rechts).

Warum probierst du es nicht einfach am Live-Beispiel, nämlich innerhalb des Frameworks? Nur dann ist es auch wirklich so, wie es dann im Realen auch ist.

Quote from InitArt

Bedenkst du das box-sizing?

Mit box-sizing hat das alles rein gar nichts zu tun.
Sofern du nicht direkt einen Rahmen oder einen Innenabstand ist, was auch nicht der Fall ist, ist selbiges nämlich in diesem Fall bedeutungslos.

Ich würde hier nicht posten, hätte ich es nicht ausprobiert
Das mit dem box-sizing ist wohl war, trifft allerdings nicht auf mein Code Beispiel zu.
Auch die font-size beachtet? Das Elternelement bedient sich 0 und das Element an sich 16px bzw. 1rem. Wobei auch das nichts mit der Breite des Elements selbst zu tun hat...

Dann macht Chrome da etwas anders als Firefox (wobei die Chrome-Engine dafür bekannt ist, Elementgrößen falsch zu berechnen).
Zumindest bekommst du es mit deinem Vorschlag effektiv nicht fehlerfrei in allen modernen Browsern hin.

Quote from Black Rider

Dann macht Chrome da etwas anders als Firefox (wobei die Chrome-Engine dafür bekannt ist, Elementgrößen falsch zu berechnen).
Zumindest bekommst du es mit deinem Vorschlag effektiv nicht fehlerfrei in allen modernen Browsern hin.

.containerList.doubleColumned {
  width: 855px;
  font-size: 0;
}




.containerList.doubleColumned > li,
.containerList.doubleColumned > li:nth-child(even) {
  float: none;
}




.containerList.doubleColumned > li {
  display: inline-block;
  font-size: .8rem;
  vertical-align: top;
}

Der Code passt natürlich nicht auf alle Media Queries...

Meine Testergebnisse (direkt im Framework) sagen noch immer etwas anderes:
IE 10: 427.5px (IE halt...) beidseitig, wird richtig dargestellt
FF 23: 428px beidseitig, wird richtig dargestellt
Chrome : 428px links, 427px rechts

Auf meinem iPhone funktioniert es ebenfalls. Ich denke nicht das es bei Android / Blackberry großartig anders aussieht.
Habe ich eine Browser Engine vergessen?

Hast du eine Quelle zu dem von dir geschilderten Verhalten von inline-block? Der white-space von 4px trifft nicht zu, wenn die font-size des Elternelements auf 0 gesetzt wird oder zwischen den HTML-Tags keine Leerzeichen gesetzt werden.

Okay, das mit dem font-size habe ich nicht beachtet. Das ist aber auch nicht mehr als ein "dirty fix", denn etwas auf eine Schriftgröße von 0 zu setzen ist einerseits nicht schön, andererseits gibt es so etwas wie "rem" sonst überhaupt nicht im Framework, was es dann wieder inkonsistent macht.

Außerdem gibt dieser Vorschlag noch ein anderes Problem:
Der kleinere der beiden Inhalte einer Zeile ist dann immer noch kleiner, dadurch ist die Hintergrundfarbe nicht über den kompletten Bereich, sondern es kommt die Hintergrundfarbe der containerList zum Vorschein. Das ist weder im Standardstil hübsch, noch einfach zu designen in anderen Stilen. Da ist es mir aktuell wesentlich lieber.

Quote from Alexander Ebert

Chrome
rundet immer auf.

Ehrlich? Bei den Problemen, die ich so im Alltag gesehen habe, ist es eher immer das Gegenteil. Zumindest bei den Höhen von Elementen ist es so. Alle Browser haben den richtigen Wert, nur Chrome hat 1px weniger.

Wenn man diese Lösung verwenden möchte, gehört natürlich noch mehr dazu als nur dieses einfache Grid-System. Die Font-Size kann auch in pixeln angegeben werden, em funktionieren natürlich nicht mehr. Alternativ kann man auch einfach die Leerzeichen im HTML-Code weglassen, siehe oben das Hauptmenü vom WBB 4.

Sorry, aber wie kann das "wie gewollt" funktionieren? Das ist doch absoluter Mumpitz.