[whatwg] <script> features

[Jonas Sicking]

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

I'll have to think about it, might not be a bad idea. Curious to get
input from others 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;
>>>> }
>>>
>>> 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.

It's not a proposal for intercepting all script compilation. It's a
bit unclear to me what the use case for a webpage to intercept all
compilation is? It also seems significantly more complex in the face
of things like workers and language features like eval and setTimeout.

The use case here is being able to intercept the execution when
linking to a particular library. I could also see wanting to intercept
the compilation and initial execution of on* attributes as that would
allow you to intercept all execution that happens in a particular
subtree. This is useful if you get a chunk of HTML, rather than simply
a script url, from an external source.

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

Your solution requires modifying the HTML markup. My solution only
requires attaching an event handler to the document node. The former
isn't always possible, and the latter is almost always significantly
easier.

/ Jonas