[whatwg] <script> features

[John J. Barton]

  On 8/17/2010 6:43 PM, Jonas Sicking wrote:
> ...
> [1] http://www.whatwg.org/specs/web-apps/current-work/#executing-a-script-block
>
Ok so I see where "executing a script block" becomes "executing <script>".
>> (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.
}

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