[whatwg] <script> features

[John J. Barton]

  On 8/17/2010 11:52 PM, Jonas Sicking wrote:
> 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.
I think is it appropriate for the proposed event to have a property 
pointing to the source.
>>> 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,
Similarly <script> tag event approach only works in async cases which 
rely on <script> tags; it won't work if the async is caused by eg window 
load event handlers or setTimeouts.  The proposal offers only partial 
support for intercepting Javascript before compilation, I think it 
should offer complete support.

> 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.
I don't understand this. The <script> tag event fires and runs code 
before and after the script tag content is compiled and the top level 
function runs. The above example runs code before and after the script 
tag content is compiled and the top-level function runs. How can one not 
get the same answer? I suppose the body of the target <script> tag could 
prevent the trailing script from running, but it could also prevent the 
event handler.

jjb