nicht angemeldet
Ich hab heute Nacht auch noch zwei Stunden nach ner Lösung gesucht, aber leider gar nicts gefunden ausser Parsen. Was mir dann auch irgendwann aufgefallen ist, ist das was du grade sagst. Wenn du den Inhalt änderst bist du wieder in einer fällig neuen Herarchie.
In vielen Fällen könnte man den Highlighter vermutlich so optimieren, dass er nur Klassen bzw. innerHTML von spans austauscht oder nur Elemente rechts vom Cursor ersetzt, aber für alle denkbaren Edit-Operationen wird das nicht hinhauen. Das Wurzelelement des Editors bleibt allerdings immer gleich, d.h. wenn man der Range irgendwie beibringen könnte, sich immer auf das Wurzelelement zu beziehen könnte es vielleicht klappen.
Wie wird bei dir das Ereignis onchange (oder so) ausgelöst?
Nicht dass ich wüsste. Vielleicht kann man es irgendwie triggern, aber ich hätte im Moment gar keine Idee, was ich damit anfangen könnte. Das Highlighting wird momentan auf onkeyup/onmouseup ausgelöst, was vermutlich ein wenig exzessiv ist, aber für eine dev-Version schon ok.
Aufgeben will ich noch grade nicht.
Naja, ich bin mittlerweile skeptisch. Ich habe mal eine Quick and Dirty-Iterator-Lösung gebaut, die die korrekten spans und offsets aus den childNodes raussuchen kann, wenn ich mit den Werten dann aber folgendes mache:
var new_range = document.createRange();
new_range.setStart(anchor, anchor_offset);
new_range.setEnd(anchor, anchor_offset);
sel.addRange(new_range);
bekomme ich schon in der zweiten Zeile bei etwa der Hälfte aller Cursor-Positionen den Fehler "Index or size is negative or greater than the allowed amount". Lt. Firebug wird das selection-Objekt außerdem ab und zu aus unerfindlichen Gründen auf null gesetzt, d.h. insgesamt ist das Verhalten ziemlich erratisch. Das wird z.T. bestimmt an meinen eigenen Bugs liegen, aber ich frage mich trotzdem, ob diese Features browserseitig überhaupt für dieses Einsatzgebiet verwendbar sind. Quellcode-Editieren und WYSIWYG-Editieren sind halt konzeptionell doch relativ verschieden.