jQuery addClass - neue Elementabmessungen

[1unitedpower]

var i = 0;
$(document).ready(function(){
  console.log(i++); // Diese Zeile wird nach der anderen console.log-Zeile ausgeführt
});
console.log(i++); // Diese Zeile wird vor der anderen console.log-Zeile ausgeführt

Ja, danke für die Erklärung. Folglich handelt es sich bei meinem ursprünglichen Ansatz aber ja nicht um einen asyncrhonen Task, richtig?

Ich kenne deinen ursprünglichen Ansatz ja nicht. Ich kann dir nur die Theorie erläutern und an isolierten Showcases demonstrieren.

Für den JavaScript-Teil in deiner Frage ist das irrelevant, der Reflow findet statt, weil eine HTML-Klasse vergeben wird. Welche CSS-Regeln nun konkret angewendet werden müssen, entscheidet sich während des Reflows und kann nicht auf magische Weise vom Browser voraus geahnt werden.

Soweit die Theorie (von der ich ja bislang auch immer ausgegangen bin). Und ich weiß ehrlich gesagt nicht, wie ich solch ein Browser internes Verhalten "prüfen" soll!?

Zwei solcher Testfälle habe ich dir bei jsfiddle ja nun schon vorgekaut. Ansonsten kannst du solche Details von den Browserherstellern erfahren, einen enstrpechenden Verweis habe ich dir ja schon zukommen lassen.

Ganz "offensichtlich", dauert es aber in diesem Fall ja länger, bis das Element seine neuen Abmessungen hat, bzw. per JS Abfrage zurückliefert.

Nein, ganz offensichtlich nicht.

Ja, schon klar. Das ist aber beabsichtigt. Denn nachdem das Multicolumn-Layout angewendet wurde, wird das Element ja (logischerweise) breiter. Und dann brauche ich die 'scrollWidth', während ich vorher die ursprüngliche Breite ermittele, die dann der Spaltenbreite (column-width) entspricht.

Was ich oben damit sagen wollte ist, dass die direkt anschließende scrolledWidth Abfrage nicht den "korrekten" Wert zurückliefert.

Doch, das tut sie. Ich habe nun mal an verschiedenen Zeitpunkten gemessen:

1. Direkt nach dem Reflow, also unmittelbar nachdem die Klasse gesetzt wird
2. Im nächsten Animations-Task (requestAnimationFrame)
3. Eine Sekunde verzögert, also mit aller Wahrscheinlichkeit nach dem der Browser die Änderungen auch gezeichnet hat. (setTimeout)

Jedesmal erhalte ich den Wert 281 für scrollWidth. Überzeuge dich selbst von den Testergebnissen: http://jsfiddle.net/t98kgqer/1/ (Nicht vergessen die JavaScript-Konsole zu öffnen, um die Ausgabe zu sehen)

Offensichtlich erwartest du einfach einfach einen falschen Wert.

Nein, zuverlässig ist die Messung mit Sicherheit nicht, die Gründe dafür habe ich ja schon erklärt. Es sind zufällig die erwarteten Messwerte, weil kein anderer asynchroner Task dazwischen funkt. Sogesehen ist dieser Workaround eine tickende Zeitbombe. Der nächste Klick vom Nutzer, die nächste Ajax-Abfrage oder die nächste Code-Änderung wird hier zu unerwartetem Verhalten führen.

Deshalb habe ich es doch extra in eine rekursive Funktion gepackt!

Ich verstehe den Zusammenhang nicht, zu dem was ich erklärt habe. Was wolltest du mit der Rekursion bezwecken?

Aber nun gut, dann habe ich also 2 Fragen:

1. Wieso liefert die direkte Abfrage von scrollWidth nicht das richtige Ergebnis

Tut sie doch. Siehe das jünge Fiddle-Beispiel.

2. Wie ermittele ich zuverlässig die scrollWidth?

Genau so, wie du es jetzt schon tust. Du erwartest aber offensichtlich einen abweichenden Wert, der in deinem späteren Programmablauf auch wirklich eintritt. Dieses Eintreten des Wertes ist aber keine Folge dieser Klassenzuweisung. Du wirst in deinem Programm noch eine andere Stelle haben, die den Browser dazu veranlasst, das Layout neu zu berechnen, also einen Reflow vorzunehmen. Das ist die Stelle die du rausfinden musst, und dort muss du die Abmessungen nehmen.