Bjoern Hoehrmann wrote:
In the typical browser implementations authors are propbably un- likely to appreciate if they get it only after the screen has been up- dated with out of sync data.
The screen? Or the layout data? Or the script-accessible DOM (whatever that may mean)? Probably not the last of these, I guess.
You could also make a XHR implementation that transfers data at 1 bit per hour; while such an implementation would be conforming, it would be practically useless for all intents and purposes
Sure.
So what is it that needs to be defined? The precise moment when the event must occur at the latest? As you note above, the draft already has a vague reference to "rapid succession" that sets expectations; why would it need to say more?
Because as things stand, it's impossible to tell a conformant implementation (one that fires DOMSubtreeModified rarely) from one that never actually fires DOMSubtreeModified? At least not with a finite-time test.
You could introduce some verbiage about DOMSubtreeModified firing the next time the browser is "idle" (whatever that means?) after the mutation has happened. That would be a little clearer, as long as you ignore the possibility of sync network operations and modal dialogs. Should this event fire while an alert is up? Should it fire in the middle of a sync XMLHttpRequest call? Note that layout changes _can_ happen in both cases.
-Boris
