[whatwg] Scripting Tweaks

[liorean]

> > 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