[whatwg] <script> features

[Jonas Sicking]

On Tue, Aug 17, 2010 at 2:17 PM, John J Barton
<johnjbarton at johnjbarton.com> wrote:
> 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.

That is correct. Though it's not related to if the script is top-level
or not. It's simply related to *when* the script statements execute.
The definition would likely be integrated in the steps related to
processing of <script> elements.

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

Sure (though I'm not sure which environment is compiled in other than
the global object, which you can't replace anyway, at least not for
now).

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

This feature is not enough for that. For example this event is not
fired for onXXX event handlers, calls to eval(), calls to the Function
constructor, calls to WorkerGlobalScope.importScripts or loading of
Workers and SharedWorkers.

For debugging APIs I suggest platform specific notification mechanisms
as they are much more performant and easier to implement.

/ Jonas