On Mon, 16 Aug 2010, Jonas Sicking wrote:
>
> I'd like to propose a couple of simple features to make <script>
> elements more useful:
>
> 1. document.currentScript
>
> This property returns the currently executing <script>, if any. Returns
> null if no <script> is currently executing. In the case of several
> nested executing <script>s, it returns the innermost one. This is useful
> for being able to pass parameters to the script by setting data-
> attributes on the script element.
>
> I think jQuery already does things that requires knowing which <script>
> element linked to jQuery, and it approximates this property by getting
> the last element in document.getElementsByTagName("script"), which won't
> work reliably. Especially with features like <script async>.
This feature is trivially implementable using the next one, so I haven't
added it.
> 2. scriptwillexecute/scriptdidexecute events
>
> These events fire right before and right after a <script> is executed.
> This allows a page to override the context a specific script is seeing.
> For example installing compatibility shims for older browsers. Another
> possible use for this is to make ads execute asynchronously. Currently
> this is problematic because a lot of ads use document.write and so the
> content will be lost (or worse) if an async attribute is added to the
> <script> element used to load the ad. Using these events a page can
> override document.write while a specific script is executing and insert
> the written content into the DOM.
>
> (I've written an implementation for firefox for these features here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=587931)
I added "beforescriptexecute" recently, in the context of another thread.
There's already the "load" event that fires after a script executes, but
sadly for internal scripts it is asynchronous which means that timers
might fire between the internal script executing and the load event
firing, which could cause all kinds of wacky things if this was being used
for changing the scripting environment. So I've added an
always-synchronous event to the <script> execution model.
One difference I notice between the spec and the Firefox code is that
per the spec, canceling beforescriptexecute stops the 'load' event as
well. Is this not desired?
Also, I made the events bubble so you wouldn't have to use capture
handlers to catch them on <body> if we later add onbeforescriptexecute=""
handlers (right now you have to use addEventListener() to catch them).
On Tue, 17 Aug 2010, David Flanagan wrote:
>
> Would these event handlers fire even when the type attribute of the
> script was unrecognized? Since scripts can now be used to embed
> arbitrary data, it would be pretty useful to have this kind of hook on
> each script tag for processing that data.
The events only fire if the script is actually going to execute.
On Tue, 24 Aug 2010, Henri Sivonen wrote:
>
> The relative order with onload should be documented.
Done. (Before onload -- has to be since in some cases the onload is
async and it'd be wacked to be sometimes before and sometimes after.)
> > (I've written an implementation for firefox for these features here:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=587931)
>
> By looking at the patch, it seems that insertion the events fire before
> document.write() becomes permitted (if applicable) and after it becomes
> forbidden again. Whether the handlers for these events should be able to
> call document.write() without blowing away has a dependency on the
> resolution of http://www.w3.org/Bugs/Public/show_bug.cgi?id=9984 and the
> relative order of the new events and onload.
The spec (I think, this is complicated!) matches what you describe in:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=9984#c6
...modulo the later discussion about document.write().
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'