A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
Talk:Script Execution Control
Jump to navigation
Jump to search
Discussion for 2.2.1.4 Limitations
Events (eg. onload) fired on preloading script elements can not be captured by the document, because the node is not in the DOM tree during preloading.
- true, but this seems like pretty inconsequential. no valid use-case has been presented where this type of event handling would be superior than element-binding event handling, for the use-cases under consideration. Getify 23:31, 3 March 2011 (UTC)
- This breaks from a fairly consistent API design across DOM elements; that's not inconsequential. The use cases are the same as any event capturing (eg. event delegation, logging). Glenn
- But almost every script loader I've ever seen or heard of uses direct script element event binding, not DOM event propagation, to listen for "onload" or "onreadystatechange". I'm only saying that it's trivial because this is not how script loaders do it, and so it's not a necessary use-case for the "preloading" that script loaders like LABjs or ControlJS want to do. What you're suggesting *could* have validity as extra benefit, but it's unfair to label it as a limitation or detraction from these 2 proposals, because in all fairness, noone's actually doing that now with any of the script load events. Just write up your third proposal, and include DOM event propagation as an additional benefit. Getify 19:19, 4 March 2011 (UTC)