- From: liorean <liorean@gmail.com>
- Date: Sat, 19 May 2007 07:37:40 +0200
> > On Wed, 20 Apr 2005, Dean Edwards wrote: > >> 1) Mozilla's DOMContentLoaded event is very handy. It fires when a > >> node's content has been loaded and parsed (the DOM has been > >> constructed). This is much better than the standard onload event as > >> it > >> doesn't wait for binary content to also load. > On May 18, 2007, at 3:40 PM, Ian Hickson wrote: > > Added. On 19/05/07, Maciej Stachowiak <mjs at apple.com> wrote: > FYI this was considered and rejected by the Web API Working Group at > W3C for inclusion in DOM Events, I believe because there did not seem > to be a truly valid use case (a popular use of this event is for late > binding of script, but given the event definition and the existence of > incremental rendering you can't actually be guaranteed the event will > fire before any content has rendered - XBL2 potentially provides a > better solution). I suggest referring to these discussions. True, but what is wanted by scripters isn't that it triggers before any rendering takes place at all, what is wanted by scripters is to not have to wait for external content to load, in difference to the load event. The important factors are that the DOM is not incomplete and that it takes place as soon as possible, not that rendering hasn't started - because most often it's wanted specifically for DOM manipulation. > Also, <script defer> as defined in HTML5 gives you the exact same > capabilities as DOMContentLoaded: "If the defer attribute is present, > then the script is executed when the page has finished parsing." I'm > not sure it's necessary to add a second way to do the same thing, > given that the thing in question is somewhat suboptimal anyway. Well, some issues with that: - It makes our script dependent on HTML. We'd have to split the script into several HTML elements. - We cannot rely on being able to create and add deferred scripts to the DOM before the DOM is already complete, so it doesn't allow for dynamically adding (before the DOM has is complete) code that modifies the DOM after it has been completed. > That being said, I don't think it's a huge problem to add it, but you > may want to review the arguments raised in the Web API WG. The lack of this feature is a real problem for scripters and is the cause for a large number of blog posts and empirical studies of current browser behaviour to create a single common way to achieve the effect, something that lack of browser interoperability hasn't fully achieved so far. -- David "liorean" Andersson
Received on Friday, 18 May 2007 22:37:40 UTC