[whatwg] <script> features

[Jonas Sicking]

On Tue, Aug 17, 2010 at 9:45 PM, John J. Barton
<johnjbarton at johnjbarton.com> wrote:
>>> (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.
>
> For example,
> myWillExecuteHandler = function(event)
> {
>    var elt = event.target;
>    var adulterate = "with(shim){\n"+elt.innerHTML+"}\n";
>    eval(adulterate);
>    return false; // need some way to abort the script tag in progress.
> }

This doesn't work for external scripts. I.e. ones with a src attribute.

>> 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;
>> }
>
> But I guess you don't need events to modify and restore the environment, why
> not just put a script before and after:
> <script>
> oldWrite = document.write;
> document.write = function(msg) { console.log(msg); }
> </script>
> <script>
> document.write("I command you!");
> </script>
> <script>
> document.write = oldWrite;
> </script>

This doesn't work if the script whose evironment you want to modify is
an asynchronous script. It also is significantly more cumbersome,
especially if you want to do this to several <script> elements in your
page. It also doesn't work if some parts of your markup is generated
by other libraries or components that you don't directly control,
which is exactly the situation when you generally want to use shims.

>>> 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?
>
> Again, its not a debugging API, it's just the same API you propose.  If
> workers cause scripts to compile, and it triggers event handlers they run on
> the worker thread (and consequently cannot operate on the UI).  And if you
> want to talk about complex, let's talk about what developers have to do now
> or what debugger have to do to try to help them.

I'm all for improving debuggers. However I don't see a need to expose
the APIs that debuggers need to web pages. If there are features that
web pages need, and that debuggers happen to be able to use, then
that's great. But features should be added based on if web pages need
them, not if debuggers or implementations need them internally.

/ Jonas