- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Tue, 09 May 2006 11:57:15 -0500
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- CC: www-archive@w3.org
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
Received on Tuesday, 9 May 2006 16:57:31 UTC