Re: [whatwg] <script> features
Ian Hickson
On Mon, 16 Aug 2010, Jonas Sicking wrote:
>
> 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 think jQuery already does things that requires knowing which <script>
> element linked to jQuery, and it approximates this property by getting
> the last element in document.getElementsByTagName("script"), which won't
> work reliably. Especially with features like <script async>.
This feature is trivially implementable using the next one, so I haven't
added it.
> 2. scriptwillexecute/scriptdidexecute events
>
> These events fire right before and right after a <script> is executed.
> This allows a page to override the context a specific script is seeing.
> For example installing compatibility shims for older browsers. Another
> possible use for this is to make ads execute asynchronously. Currently
> this is problematic because a lot of ads use document.write and so the
> content will be lost (or worse) if an async attribute is added to the
> <script> element used to load the ad. Using these events a page can
> override document.write while a specific script is executing and insert
> the written content into the DOM.
>
> (I've written an implementation for firefox for these features here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=587931)
I added "beforescriptexecute" recently, in the context of another thread.
There's already the "load" event that fires after a script executes, but
sadly for internal scripts it is asynchronous which means that timers
might fire between the internal script executing and the load event
firing, which could cause all kinds of wacky things if this was being used
for changing the scripting environment. So I've added an
always-synchronous event to the <script> execution model.
One difference I notice between the spec and the Firefox code is that
per the spec, canceling beforescriptexecute stops the 'load' event as
well. Is this not desired?
Also, I made the events bubble so you wouldn't have to use capture
handlers to catch them on <body> if we later add onbeforescriptexecute=""
handlers (right now you have to use addEventListener() to catch them).
On Tue, 17 Aug 2010, David Flanagan wrote:
>
> Would these event handlers fire even when the type attribute of the
> script was unrecognized? Since scripts can now be used to embed
> arbitrary data, it would be pretty useful to have this kind of hook on
> each script tag for processing that data.
The events only fire if the script is actually going to execute.
On Tue, 24 Aug 2010, Henri Sivonen wrote:
>
> The relative order with onload should be documented.
Done. (Before onload -- has to be since in some cases the onload is
async and it'd be wacked to be sometimes before and sometimes after.)
> > (I've written an implementation for firefox for these features here:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=587931)
>
> By looking at the patch, it seems that insertion the events fire before
> document.write() becomes permitted (if applicable) and after it becomes
> forbidden again. Whether the handlers for these events should be able to
> call document.write() without blowing away has a dependency on the
> resolution of http://www.w3.org/Bugs/Public/show_bug.cgi?id=9984 and the
> relative order of the new events and onload.
The spec (I think, this is complicated!) matches what you describe in:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=9984#c6
...modulo the later discussion about document.write().
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Kornel Lesiński
>> The whole point of this feature is to enable the js-code inside a loaded
>> script to use the .currentScript property in order to find the <script>
>> element in the DOM which loaded it.
>
> Ah, ok. What's the use case for that?
Embedding of 3rd party widgets asynchronously:
<script async src="3rd-party-widget.js"></script>
Then the script could find its node in the document and replace it with
whatever it wants.
Another use case would be a (superficial) emulation of document.write()
for scripts that have been embedded asynchronously.
--
regards, Kornel Lesiński
Jonas Sicking
> On Fri, 23 Mar 2012, Jonas Sicking wrote:
>>
>> The whole point of this feature is to enable the js-code inside a loaded
>> script to use the .currentScript property in order to find the <script>
>> element in the DOM which loaded it.
>
> Ah, ok. What's the use case for that?
One use case is to be able to pass parameters to a script library by
sticking the information in the markup. data-* attributes would work
great for this. I seem to recall jQuery doing something like this, but
can't find information about that right now.
In the case of ReSpec it uses it to get its own url and then use that
as a base url to load dependent scripts as needed.
/ Jonas
Aryeh Gregor
> In the case of ReSpec it uses it to get its own url and then use that
> as a base url to load dependent scripts as needed.
testharness.js also does that, I think -- it loads a CSS file from the
same directory as itself. IIRC, it does so by looking for the first
<script> whose src ends in "testharness.js". It would be more
reliable if it could record the actual URL it's being loaded from.
(For this use-case it would be enough for the script to get its own
URL. In fact, this might be slightly more reliable, because there's
nothing to stop an earlier part of the script from inadvertently
changing the <script> element's src. That wouldn't satisfy the first
use-case Jonas mentioned, though.)