[whatwg] <script> features

[Jonas Sicking]

On Tue, Aug 17, 2010 at 6:14 PM, John J Barton
<johnjbarton at johnjbarton.com> wrote:
> Jonas Sicking wrote:
>
> 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.
>
> Well either this is correct *or* you fire the event before compiling (see
> below). I think my description is not correct, and that's good.

I'm not sure which event you are referring to here?

> Though it's not related to if the script is top-level
> or not. It's simply related to *when* the script statements execute.
>
> (It's the function that is top-level.)
>
> I guess you mean by "execute the <script>", "compile the source in the tag
> and run the top-level function"?

To get to specification level detail, I mean:

In the "If the load was successful" algorithm at [1], insert a step
before the current step 3 which says:

"Set the documents /current-script/ to the script element node."

And insert a step after the current step 3 which says:

"Set the documents /current-script/ to the value it had before it was
modified above."

And define a currentScript IDL attribute on Document which returns the
documents /current-script/ property.

[1] http://www.whatwg.org/specs/web-apps/current-work/#executing-a-script-block

> (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).
>
>
> Well if I intercept the event and change the source to
>   with(browserShim) {
>      ... script tag contents here....
>   }
> Then I compile into another environment. Otherwise how can I achieve your
> goal?

These events in and of themselves doesn't allow you to modify the
script source. This does seem like a neat idea, if you have ideas for
how this would be done please do suggest them here.

What I was thinking was simply allowing the event handler to do things like:

var oldWrite;
myWillExecuteHandler(event) {
  oldWrite = document.write;
  document.write = myWriteOverride;
}
myDidExecuteHandler(event) {
  document.write = oldWrite;
}

> 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.
>
>
> But if you don't cover these paths then I don't think the feature is
> complete, because what ever developers do in top-level functions of script
> tag source they do in all those other cases too.

It's not intended for implementing debuggers. I suspect a debugging
API would require something significantly more complex in order to
deal with all the features I listed. For one, how would you deal with
the fact that workers can cause scripts to compile and evaluate on
multiple threads?

If you have suggestions I'm all ears.

/ Jonas