[whatwg] <script> features

[Giorgio Maone]

  They would be great additions, thanks.

> 2. scriptwillexecute/scriptdidexecute events
Notice that Opera has a richer set of eventsof this kind (exsposed to 
"privileged" User Scripts, though, AFAIK), allowing for much more control over 
the executing scripts, no matter if from script elements, event handlers or URLs:
http://www.opera.com/docs/userjs/specs/#evlistener

Cheers
-- G

Jonas Sicking wrote, On 17/08/2010 6.15:
> Hi All,
>
> 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>.
>
> 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)
>
> / Jonas