[whatwg] <script> features

[Nicholas Zakas]

Really like the idea, though I think the naming of Opera's events ("beforescript", "afterscript") fit in better with other events on the page (i.e. "beforeunload").

-Nicholas
 
______________________________________________
Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Giorgio Maone
Sent: Monday, August 16, 2010 11:12 PM
To: Jonas Sicking
Cc: WHAT Working Group
Subject: Re: [whatwg] <script> features

  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