Trotzdem hab ich ne Idee zur Lösung:
Setz eine
window.setTimeout()
-Schleife ein.
Kein schlechter Gedanke, aber das wird nicht verlässlich funktionieren. Wenn man mit JavaScript eine HTML-Klasse vergibt, dann unternimmt der Browser sofort einen blockierenden Reflow. Der TO braucht die Abmessungen unmittelbar danach. Denn beim nächsten Reflow könnten die Element-Abmessungen schon wieder andere sein. Mit setTimeout() reiht man einen asynchronen Task in den Event-Loop ein, man hat keine Kontrolle darüber, dass es sich dabei um den Task handelt, der als nächstes ausgeführt wird. Es können diverse andere Tasks dazwischen kommen, zum Beispiel von einem setTimeout()-Aufruf an einer anderen Stelle im Skript, von einem Klick, den der Benutzer ausgeführt hat, oder von einer AJAX-Antwort, die inzwischen eingetroffen ist. Jeder dieser Tasks kann wiederum durch DOM-Manipulation weitere Reflows auslösen.
setTimeout() wird hier also nicht den gewünschten Effekt haben (zumindest kann man sich darauf nicht verlassen). Das Positive daran ist, dass man setTimeout gar nicht benötigte, wie gesagt, findet der Reflow blockierend und unmittelbar in Folge der DOM-Manipulation statt, es ist möglich mit der nächsten Anweisung sofort die neuen Abmessungen auszulesen. Das führt natürlich zu der Frage, warum der TO trotzdem ein Szenario beobachtet hat, in dem das nicht der Fall zu sein schien. Das Mysterium können wir nur lüften, wenn wir den fraglichen Code zu Gesicht bekommen.