[whatwg] <script> features

[John J Barton]

whatwg-request at lists.whatwg.org wrote:
> Date: Mon, 16 Aug 2010 21:15:35 -0700
> From: Jonas Sicking <jonas at sicking.cc>
> To: WHAT Working Group <whatwg at whatwg.org>
> Subject: [whatwg] <script> features
> Message-ID:
> 	<AANLkTin3t5ZB4DrUxJ8WS_hiuSgs3pMoZL8WOgRTCkfq at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi All,
>
> 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 wonder if you mean: "This property returns the <script> tag defining 
the currently executing top-level function"?
So for:
<script>
var foo = function() {
alert("a foo");
}
foo();
window.addEventListener("load", foo, false);
</script>
the property will be null until the <script> tag is parsed and passed to 
the compiler. Then the property will point to the script tag during the 
execution of the outer or top level function which defines foo, calls 
foo, and sets foo as a load handler. Then the property is null again. 
When the load event runs, the property is null.

> 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>.
>
> 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.
>   
But by the time the functions execute, the environment of compilation 
has already been bound into the functions. I think you want the event 
*before* compilation.

If this kind of event were provided for all compilations, Javascript 
debugging would make a quantum leap forward in performance and 
reliability. Firebug, for example, uses egregious hacks to fake these 
events on the mozilla platform.

jjb