Ich versuch's mal ohne Sarkasmus... Mit $('#dings') liefert jQuery Dir ein "matched set" von Elementen, die die ID `dings` tragen. ABER nicht den kompletten Subtree aus dem DOM, der zu `dings` gehört. Wenn dein `dings` Element also Child-Elemente hat, wäre hier eins der Probleme. $('#dings') liefert Dir darüber hinaus Referenzen auf existierende DOM Objekte, keine Kopie. Darum soll man matched sets von jQuery nicht speichern (oder nur dann, wenn man genau weiß was man tut). Sobald Du das Element mit der ID `dings` durch etwas anderes ersetzt hast, ist dein gespeichertes Set ungültig bzw. die darin referenzierten DOM Elemente schlurfen nur noch grunzend und mit ausgestreckten Armen neben dem DOM her: Es sind heimatlose Zombies und der Garbage Collector wetzt schon die Sense. Sobald deine Variable mit dem gespeicherten Set aus dem Scope geht, oder Du etwas anderes darin speicherst, fällt er über sie her. Drittens ist das Artefakt `$('#dings')` nicht schreibbar. Es ist ein Funktionsaufruf, der Dir einen Wert (das matched set) zurückliefert. In Worten eines C-Compilers formuliert: es ist kein lvalue, ein Begriff, der platt gesagt meint: "etwas, das auf der linken Seite einer Zuweisung stehen darf"[^1]. Die lvalues in Javascript sind Variablen, Property-Referenzen von Objekten und Array-Elemente (hoffentlich war das vollständig). Wenn Du ein einzelnes Element mit allem Drum und Dran sichern willst, dann probier's mal mit ~~~js var savedThingy = $('#dings')[0].outerHTML; // mess around with DOM here, but keep one element with id='dings' $('#dings').replace(savedThingy); ~~~ Müsste eigentlich klappen, die Replace-Methode kann HTML-Fragmente annehmen. Statt `set[0].outerHTML` könnte auch `set.clone()` funktionieren. outerHTML erzeugt HTML Text, clone() speichert DOM Objekte. Beachte den [0] Index bei outerHTML. Das ist ein Attribut des DOM. clone() ist eine jQuery-Funktion die zum matched set gehört. Rolf [^1]: keine Regel ohne Ausnahme: Gibt eine Funktion in C++ eine Referenz zurück die nicht const ist, dann kann `func(x)` doch ein lvalue sein. Aber in JavaScript gibt's das nicht.

Ich versuch's mal ohne Sarkasmus... Mit $('#dings') liefert jQuery Dir ein "matched set" von Elementen, die die ID `dings` tragen. ABER nicht den kompletten Subtree aus dem DOM, der zu `dings` gehört. Wenn dein `dings` Element also Child-Elemente hat, wäre hier eins der Probleme. $('#dings') liefert Dir darüber hinaus Referenzen auf existierende DOM Objekte, keine Kopie. Darum soll man matched sets von jQuery nicht speichern (oder nur dann, wenn man genau weiß was man tut). Sobald Du das Element mit der ID `dings` durch etwas anderes ersetzt hast, ist dein gespeichertes Set ungültig bzw. die darin referenzierten DOM Elemente schlurfen nur noch grunzend und mit ausgestreckten Armen neben dem DOM her: Es sind heimatlose Zombies und der Garbage Collector wetzt schon die Sense. Sobald deine Variable mit dem gespeicherten Set aus dem Scope geht, oder Du etwas anderes darin speicherst, fällt er über sie her. Drittens ist das Artefakt `$('#dings')` nicht schreibbar. Es ist ein Funktionsaufruf, der Dir einen Wert (das matched set) zurückliefert. In Worten des C-Compilers: es ist kein lvalue[^1]. Wenn Du ein einzelnes Element mit allem Drum und Dran sichern willst, dann probier's mal mit ~~~js var savedThingy = $('#dings')[0].outerHTML; // mess around with DOM here, but keep one element with id='dings' $('#dings').replace(savedThingy); ~~~ Müsste eigentlich klappen, die Replace-Methode kann HTML-Fragmente annehmen. Statt `set[0].outerHTML` könnte auch `set.clone()` funktionieren. outerHTML erzeugt HTML Text, clone() speichert DOM Objekte. Beachte den [0] Index bei outerHTML. Das ist ein Attribut des DOM. clone() ist eine jQuery-Funktion die zum matched set gehört. Rolf [^1]: keine Regel ohne Ausnahme: Gibt eine Funktion in C++ eine Referenz zurück die nicht const ist, dann kann `func(x)` doch ein lvalue sein. Aber in JavaScript gibt's das nicht.

Ich versuch's mal ohne Sarkasmus... Mit $('#dings') liefert jQuery Dir ein "matched set" von Elementen, die die ID #dings tragen. ABER nicht den kompletten Subtree aus dem DOM, der zu #dings gehört. Wenn dein #dings Element also Child-Elemente hat, wäre hier eins der Probleme. $('#dings') liefert Dir darüber hinaus Referenzen auf existierende DOM Objekte, keine Kopie. Darum soll man matched sets von jQuery nicht speichern (oder nur dann, wenn man genau weiß was man tut). Sobald Du das Element mit der ID #dings durch etwas anderes ersetzt hast, ist dein gespeichertes Set ungültig bzw. die darin referenzierten DOM Elemente schlurfen nur noch grunzend und mit ausgestreckten Armen neben dem DOM her: Es sind heimatlose Zombies und der Garbage Collector wetzt schon die Sense. Sobald deine Variable mit dem gespeicherten Set aus dem Scope geht, oder Du etwas anderes darin speicherst, fällt er über sie her. Drittens ist das Artefakt `$('#dings')` nicht schreibbar. Es ist ein Funktionsaufruf, der Dir einen Wert (das matched set) zurückliefert. In Worten des C-Compilers: es ist kein lvalue[^1]. Wenn Du ein einzelnes Element mit allem Drum und Dran sichern willst, dann probier's mal mit ~~~js var savedThingy = $('#dings')[0].outerHTML; // mess around with DOM here, but keep one element with id='dings' $('#dings').replace(savedThingy); ~~~ Müsste eigentlich klappen, die Replace-Methode kann HTML-Fragmente annehmen. Statt `set[0].outerHTML` könnte auch `set.clone()` funktionieren. outerHTML erzeugt HTML Text, clone() speichert DOM Objekte. Beachte den [0] Index bei outerHTML. Das ist ein Attribut des DOM. clone() ist eine jQuery-Funktion die zum matched set gehört. Rolf [^1]: keine Regel ohne Ausnahme: Gibt eine Funktion in C++ eine Referenz zurück die nicht const ist, dann kann `func(x)` doch ein lvalue sein. Aber in JavaScript gibt's das nicht.