[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.javascript

onload and onclick

emf

3/28/2016 12:08:00 PM

The eye exercises at:

http://emf.neocities.org/...

are working fine (after I was finally able to upload all the files I
wanted) My question revers to he function that fires them:

window.onload = function () {
"use strict";
document.getElementById("start").onclick = function () {
requestFullScreen();
init();
};
};

I arrived at this solution after deciding to remove any JS code from the
HTML code. It works fine, however it looks a little too complicated for
my personal taste. Is there a simpler way to write it?

emf

--
Spherical Triangle Calculator
http://emf.neocities.org/tr/sphe...
16 Answers

Stefan Weiss

3/28/2016 8:48:00 PM

0

emf wrote:
> window.onload = function () {
> "use strict";
> document.getElementById("start").onclick = function () {
> requestFullScreen();
> init();
> };
> };
>
> I arrived at this solution after deciding to remove any JS code from the
> HTML code. It works fine, however it looks a little too complicated for
> my personal taste. Is there a simpler way to write it?

This is pretty typical code for what you're doing. There are a few
variations that could make it a little more concise, but nothing
dramatic. For example:

- If you include this script after the element with the ID "start", you
don't have to wait for the "load" event before you assign a click
handler to the element.
- Strict mode makes no difference in this particular function, so the
"use strict" statement could be left out.
- Explicitly referring to the `window` object is optional; you could
write `onload = function ()...` with the same effect.

Personally, I wouldn't use any of these. I would even go a step in the
opposite direction and use the more verbose `addEventListener()` method
instead of the DOM-0 style "onload" and "onclick" properties:

window.addEventListener("load", function () {
// etc
});

This allows for more than one listener per target and event type, which
is particularly useful for the "load" event.

Most people use libraries to simplify common tasks like event handling
and element selection. With one such library, your code might look like
this:

$(function () {
$("#start").click(function () {
requestFullScreen();
init();
});
});

That's shorter (and also uses the "DOMready" event). Loading a huge
library for just a few lines of code would be counterproductive, but
typically the library gets used for the rest of the code, as well.


- stefan

ram

3/28/2016 9:21:00 PM

0

Stefan Weiss <krewecherl@gmail.com> writes:
>Personally, I wouldn't use any of these. I would even go a step in the
>opposite direction and use the more verbose `addEventListener()` method
>instead of the DOM-0 style "onload" and "onclick" properties:
> window.addEventListener("load", function () {
> // etc
> });

When is it better or worse to use »DOMContentLoaded« instead
of »load«?

When is it better or worse to use »body.« instead of
»window.« above?

I am looking for a »default call« to start my scripts that
should make sure that most of what usually is needed for a
script has been loaded, and so far I had settled for

document.addEventListener( "DOMContentLoaded", ...

>Most people use libraries to simplify common tasks like event handling
>and element selection. With one such library, your code might look like
>this:

I would not use jQuery for »simplification« of a specific
task in a specific browser, but rather because - as far as
I have heard about it - it contains code that already
contains several adaptions to specific browsers (and their
deficiencies and bugs), so, I'd use it because it can act
as a kind of compatibility layer to different browsers.

Otherwise, for its pure features, the distance between
jQuery and plain JavaScript has become a little bit smaller
because some features of jQuery now have been built into
DOM4 by functions such as - for example - »querySelector«.

I wonder whether it has been really this way historically:
was it an invention of jQuery to use CSS selectors to select
elements and is »querySelector« in DOM4 today really because
of the prior art (one might say, »pressure«) of jQuery?

>That's shorter (and also uses the "DOMready" event). Loading a huge
>library for just a few lines of code would be counterproductive, but
>typically the library gets used for the rest of the code, as well.

So, there is a »DOMready«, too! Now I have »load«,
»DOMContentLoaded« /and/ »DOMready« to choose from!

Thomas 'PointedEars' Lahn

3/28/2016 9:23:00 PM

0

Stefan Weiss wrote:

> emf wrote:
>> window.onload = function () {
>> "use strict";
>> document.getElementById("start").onclick = function () {
>> requestFullScreen();
>> init();
>> };
>> };
>>
>> I arrived at this solution after deciding to remove any JS code from the
>> HTML code. It works fine, however it looks a little too complicated for
>> my personal taste. Is there a simpler way to write it?
>
> This is pretty typical code for what you're doing. There are a few
> variations that could make it a little more concise, but nothing
> dramatic. For example:
>
> - If you include this script after the element with the ID "start", you
> don't have to wait for the "load" event before you assign a click
> handler to the element.

Not guaranteed:

<https://www.w3.org/TR/2014/REC-html5-20141028/introduction.html#common-pitfalls-to-avoid-when-using-the-scriptin...

> - Strict mode makes no difference in this particular function, so the
> "use strict" statement could be left out.

Questionable advice. If the function is later augmented with source code to
which strict mode would be relevant, those checks would not be performed.
And the OP is evidently not ECMAScript-savvy enough to know when strict mode
would apply so chances are that they would not add the declaration later.

The standing recommendation, particularly to beginners, is to declare strict
mode *locally* (which the OP has done, although it could be declared for a
â??moduleâ? of the module pattern as well), unless legacy code requires
otherwise *and* cannot be easily rewritten to accomodate strict mode.
*A lot* of common beginnerâ??s mistakes are detected this way.

> - Explicitly referring to the `window` object is optional;

Cite evidence.

> you could write `onload = function ()...` with the same effect.

A Really Bad Idea. What if there happens to be a property of an object or a
variable in the scope chain that is not the targeted object? What if it is
strict mode code? This change makes the code less compatible and harder to
reuse *at no advantage*.

> Personally, I wouldn't use any of these. I would even go a step in the
> opposite direction and use the more verbose `addEventListener()` method
> instead of the DOM-0 style "onload" and "onclick" properties:
>
> window.addEventListener("load", function () {
> // etc
> });
>
> This allows for more than one listener per target and event type, which
> is particularly useful for the "load" event.

Yes, the event listener should be added. But verbatim this does not work in
IE < 9, and IE 9 in Compatibility Mode. So if that is a problem a wrapper
is required. (Microsoft has terminated support for versions before IE *11*
in January. [1] We have removed IE 8 support last year [IIRC], and are
going to stop actively supporting IE 9 sometime this year.)

[1] <https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-s...

> Most people use libraries to simplify common tasks like event handling
> and element selection.

ACK.

> With one such library, your code might look like this:
>
> $(function () {
> $("#start").click(function () {
> requestFullScreen();
> init();
> });
> });

Looks like jQuery-based code where .on("click", â?¦) is recommended instead,
for extensibility and consistency.

> That's shorter (and also uses the "DOMready" event). Loading a huge
> library for just a few lines of code would be counterproductive, but
> typically the library gets used for the rest of the code, as well.

Still, one should carefully assess what features of the library are actually
used, and use a tailored version, and the library wrappers only when
necessary. Should the library wrappers not be necessary at all, then the
reasonable decision is not to use the library.

<http://youmightnotneedjquer...

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

Aleksandro

3/28/2016 9:34:00 PM

0

On 28/03/16 09:07, emf wrote:
> The eye exercises at:
>
> http://emf.neocities.org/...
>
> are working fine (after I was finally able to upload all the files I
> wanted) My question revers to he function that fires them:
>
> window.onload = function () {
> "use strict";
> document.getElementById("start").onclick = function () {
> requestFullScreen();
> init();
> };
> };
>
> I arrived at this solution after deciding to remove any JS code from the
> HTML code. It works fine, however it looks a little too complicated for
> my personal taste. Is there a simpler way to write it?

"use strict"

window.addEventListener("DOMContentLoaded", attachListener)

function attachListener ()
{
document.gelElementById("start").addEventListener(requestEvent)
}

function requestEvent ()
{
requestFullScreen()
init()
}

Frank Kozuschnik

3/28/2016 10:20:00 PM

0

Thomas 'PointedEars' Lahn:

> (Microsoft has terminated support for versions before IE *11* in
> January. [1] We have removed IE 8 support last year [IIRC], and
> are going to stop actively supporting IE 9 sometime this year.)
>
> [1] <https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-s...

For some Windows versions, older IE versions are still supported because
no newer version is available. For each Windows version, Microsoft
supports the most current version of Internet Explorer that is available
for this Windows version.

For example, IE 9 is the most current version of Internet Explorer on
Windows Vista SP2 and Windows Server 2008 SP2, and this means that IE 9
is still supported on these Windows versions (as long as these Windows
versions themselves are supported).

<https://support.microsoft.com/en-us/lifecycle#gp/Microsoft-Internet-Ex...

Thomas 'PointedEars' Lahn

3/28/2016 10:34:00 PM

0

Stefan Ram wrote:

> Stefan Weiss <krewecherl@gmail.com> writes:
>>Personally, I wouldn't use any of these. I would even go a step in the
>>opposite direction and use the more verbose `addEventListener()` method
>>instead of the DOM-0 style "onload" and "onclick" properties:
>> window.addEventListener("load", function () {
>> // etc
>> });
>
> When is it better or worse to use »DOMContentLoaded« instead
> of »load«?

See below. Next time, STFW and RTFM.

> When is it better or worse to use »body.« instead of
> »window.« above?

It is better when there is a â??bodyâ? variable or property in the scope chain
whose value is a reference to the same object as the value of
â??document.bodyâ?. Neither the ECMAScript global object nor the host-defined
window object has a built-in �body� property.

> I am looking for a »default call« to start my scripts that
> should make sure that most of what usually is needed for a
> script has been loaded, and so far I had settled for
>
> document.addEventListener( "DOMContentLoaded", ...

There is no silver bullet.

> I wonder whether it has been really this way historically:
> was it an invention of jQuery to use CSS selectors to select
> elements

No, as a *quick* Web research shows, the initial jQuery release was on
2006-08-26.

> and is »querySelector« in DOM4 today really because
> of the prior art (one might say, »pressure«) of jQuery?

No, Document::querySelector() and Document::querySelectorAll() have been
introduced with the W3C Selectors API Level 1, which went a W3C
Recommendation in 2013, but had been implemented before (since Firefox 3.5
[2009-06] and Safari 3.2 [2008-11-13]).

The first working draft of that specification is of 2006-05-25, three months
earlier than the first jQuery release. It introduces D::match() and
D::matchAll() methods for the same purpose; two working drafts later, on
2007-10-19, they had been renamed to D::qS() and D::qSA(). So the only
â??pressureâ? that could have come from jQuery was the â??queryâ? in the method
names.

<https://developer.mozilla.org/en-US/docs/Web/API/Document/querySe...
pp.

>>That's shorter (and also uses the "DOMready" event). Loading a huge
>>library for just a few lines of code would be counterproductive, but
>>typically the library gets used for the rest of the code, as well.
>
> So, there is a »DOMready«, too!

Only as an abstraction layer of some libraries.

<https://developer.mozilla.org/en-US/docs/Web/Events/DOMContent...

> Now I have »load«, »DOMContentLoaded« /and/ »DOMready« to choose from!

Unless you need to support IE < 9 or IE 9 in Compatibility Mode, listen to
â??DOMContentLoadedâ? if you are only interested in the nodes of the document
tree (mistakenly called â??DOMâ?), and â??loadâ? if you want to be pretty sure
that all referred resources have been loaded and rendered.

Better yet, if possible, instead of listening to the â??loadâ? event on the
body/document/window, listen to the â??loadâ? event on the specific element of
whose loading status you are interested in: historically, the â??loadâ? event
of the body/document/window has sometimes fired even before all referred
images had been downloaded.

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

Thomas 'PointedEars' Lahn

3/28/2016 10:43:00 PM

0

Frank Kozuschnik wrote:

> Thomas 'PointedEars' Lahn:
>> [1]
>> [<https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-s...
>
> For some Windows versions, older IE versions are still supported because
> no newer version is available. For each Windows version, Microsoft
> supports the most current version of Internet Explorer that is available
> for this Windows version.
> [â?¦]
> <https://support.microsoft.com/en-us/lifecycle#gp/Microsoft-Int... Explorer>

Thank you, that clarification is very important. (So we might have to
continue supporting IE 9 until Extended Support ends for Windows Vista SP2:
2017-04-11. Yuck^H^H^Hahoo! ;-))

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

Stefan Weiss

3/28/2016 10:58:00 PM

0

Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
>> - If you include this script after the element with the ID "start", you
>> don't have to wait for the "load" event before you assign a click
>> handler to the element.
>
> Not guaranteed:
>
> <https://www.w3.org/TR/2014/REC-html5-20141028/introduction.html#common-pitfalls-to-avoid-when-using-the-scriptin...

That specific section you linked to actually supports what I wrote:

| On the other hand, parsing of HTML files happens asynchronously and
| incrementally, meaning that the parser can pause at any point to let
| scripts run.

The parser, having parsed and created the "start" element, pauses to let
the script add a "click" listener to it. There is _no_ potential for a
race condition as with "load", which is what that part of the spec warns
about.

Adding click listeners before the DOMContentLoaded stage has always
worked just fine.

>> - Strict mode makes no difference in this particular function, so the
>> "use strict" statement could be left out.
>
> Questionable advice.

This was _not_ advice. Learn to read.

> If the function is later augmented with source code to which strict
> mode would be relevant

Sure, and if my grandmother had wheels she'd be a wagon.

I said "this particular function". If you modify the code, the statement
no longer applies to it.

>> - Explicitly referring to the `window` object is optional;
>
> Cite evidence.

No, do your own homework.

>> you could write `onload = function ()...` with the same effect.
>
> A Really Bad Idea. What if there happens to be a property of an object or a
> variable in the scope chain that is not the targeted object?

We actually have the full code in this case and can easily see that
there is no such custom object or property. Creating one would be a
Really Bad Idea, indeed. If you're actually going to assume that
`onload` is somehow in danger of being something other than intended,
then `window` is affected in exactly the same way.

> What if it is strict mode code?

1) Nothing. Not a problem.

2) We know the code, we're not in global strict mode.

> This change makes the code less compatible and harder to
> reuse *at no advantage*.

Hence:

>> Personally, I wouldn't use any of these.

....
>> window.addEventListener("load", function () {
>> // etc
>> });
>>
>> This allows for more than one listener per target and event type, which
>> is particularly useful for the "load" event.
>
> Yes, the event listener should be added. But verbatim this does not work in
> IE < 9, and IE 9 in Compatibility Mode. So if that is a problem a wrapper
> is required. (Microsoft has terminated support for versions before IE *11*
> in January. [1] We have removed IE 8 support last year [IIRC], and are
> going to stop actively supporting IE 9 sometime this year.)

So, you no longer support IE8, but I should? Anyway, this is easily
fixed by using an additional `false` argument. Libraries generally take
care of that, too.


- stefan

Thomas 'PointedEars' Lahn

3/29/2016 12:05:00 AM

0

Stefan Weiss wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>> - If you include this script after the element with the ID "start", you
>>> don't have to wait for the "load" event before you assign a click
>>> handler to the element.
>>
>> Not guaranteed:
>>
>> <https://www.w3.org/TR/2014/REC-html5-20141028/introduction.html#common-pitfalls-to-avoid-when-using-the-scriptin...
>
> That specific section you linked to actually supports what I wrote:

On the contrary.

> | On the other hand, parsing of HTML files happens asynchronously and
> | incrementally, meaning that the parser can pause at any point to let
> | scripts run.
>
> The parser, having parsed and created the "start" element, pauses to let
> the script add a "click" listener to it. There is _no_ potential for a
> race condition as with "load", which is what that part of the spec warns
> about.

You are misinterpreting this. What it really says is that inline script
code can be executed at any time, whether the element in question had been
parsed by the HTML parser and added as an object to the document tree before
or not. If it has not been added yet, or is incompletely processed, the
inline script code assuming otherwise will fail in some way.

> Adding click listeners before the DOMContentLoaded stage has always
> worked just fine.

Lucky you. As I said, it is not guaranteed. Never has been. That is why
there are those events (and even the jQuery zealots recommend to use them).

>>> - Strict mode makes no difference in this particular function, so the
>>> "use strict" statement could be left out.
>>
>> Questionable advice.
>
> This was _not_ advice. Learn to read.

BTDT. â??Could be left outâ? without even a comment as to why this would be a
bad idea is equivalent to a recommendation. Especially to a beginner.

>>> - Explicitly referring to the `window` object is optional;
>>
>> Cite evidence.
>
> No, do your own homework.

IOW, you do not substantiate your claim, so we can safely assume it is
nonsense based on wishful thinking and insufficient testing.

>>> you could write `onload = function ()...` with the same effect.
>> A Really Bad Idea. What if there happens to be a property of an object
>> or a variable in the scope chain that is not the targeted object?
>
> We actually have the full code in this case and can easily see that
> there is no such custom object or property.

See below.

> Creating one would be a Really Bad Idea, indeed.

Only if one followed your unwise "non-advice".

> If you're actually going to assume that `onload` is somehow in danger of
> being something other than intended, then `window` is affected in exactly
> the same way.

No, because â??window.onloadâ? is always a property access, a standalone
â??onloadâ? is not always one.

>> What if it is strict mode code?
>
> 1) Nothing. Not a problem.

Incorrect. Assignment to a non-existing property of a distinct object is
relatively harmless in strict mode. Reference, and particularly assignment,
to an identifier that fails to be resolved at the top end of the scope chain
throws a ReferenceError exception in strict mode instead. Also, since one
cannot know the scope chain in an HTML document with certainty, with an
identifier there is always the possibility that there is an object in the
scope chain before that has a corresponding property. For example, it could
be the object referred to by the â??formâ? or â??documentâ? property.

> 2) We know the code, we're not in global strict mode.

We know the *current* code of a *beginner*.

>> This change makes the code less compatible and harder to
>> reuse *at no advantage*.
>
> Hence:
>
>>> Personally, I wouldn't use any of these.

Given the context, this can be interpreted in multiple ways, not all
favorable to you.

>> Yes, the event listener should be added. But [addEventListener()] does
>> not work in IE < 9, and IE 9 in Compatibility Mode. So if that is a
>> problem a wrapper is required. (Microsoft has terminated support for
>> versions before IE *11* in January. [1] We have removed IE 8 support
>> last year [IIRC], and are going to stop actively supporting IE 9 sometime
>> this year.)
>
> So, you no longer support IE8, but I should?

No. How did you get that idea?

> Anyway, this is easily fixed by using an additional `false` argument.

Nonsense. The method itself is not available in the named circumstances.

> Libraries generally take care of that, too.

If they would only do what you suggest, they would be insufficient there.
Fortunately or not, they do more: they tend to use .attachEvent() then
(which is not equivalent; I [recommend to] reuse the event-handler property
instead).

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

Stefan Weiss

3/29/2016 2:47:00 AM

0

Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
>> | On the other hand, parsing of HTML files happens asynchronously and
>> | incrementally, meaning that the parser can pause at any point to let
>> | scripts run.
>>
>> The parser, having parsed and created the "start" element, pauses to let
>> the script add a "click" listener to it. There is _no_ potential for a
>> race condition as with "load", which is what that part of the spec warns
>> about.
>
> You are misinterpreting this. What it really says is that inline script
> code can be executed at any time, whether the element in question had been
> parsed by the HTML parser and added as an object to the document tree before
> or not. If it has not been added yet, or is incompletely processed, the
> inline script code assuming otherwise will fail in some way.
>
>> Adding click listeners before the DOMContentLoaded stage has always
>> worked just fine.
>
> Lucky you. As I said, it is not guaranteed. Never has been.

It does not matter if there is or isn't an actual written guarantee in
the specification, because when a script is executed before the
"DOMContentLoaded" stage, the previously parsed (complete) elements
*are* available in the DOM. This is the way browsers have been working
for a very, very long time - making it a de facto standard. Thousands of
scripts rely on this behavior.

What did not always work reliably was modifying the tree by inserting,
deleting, or moving nodes around before the containing element finished
parsing. Remember the infamous "Operation aborted" error in IE? That's
what happened when the tree structure was modified before the browser
was ready - and even back then it was fine to add event listeners during
parsing.

As a matter of fact, I wouldn't be at all surprised if this behavior
actually is specified in HTML5. It's hard to keep up with 1150 pages of
"living standard", and I've never had a reason to read the immense
section about parsing, but there are some passages that highly suggest
that the DOM is intended to be available during parsing. Here are some
rather extreme examples:

A<script>
var text = document.createTextNode('B');
document.body.appendChild(text);
</script>C

A<script>
var text = document.getElementsByTagName('script')[0].firstChild;
text.data = 'B';
document.body.appendChild(text);
</script>C

https://html.spec.whatwg.org/multipage/syntax.html#creating-and-inser...

Given time, I could probably find the section that directly specifies
all this, but I'm already wasting too much time here.

>>>> - Strict mode makes no difference in this particular function, so the
>>>> "use strict" statement could be left out.
>>>
>>> Questionable advice.
>>
>> This was _not_ advice. Learn to read.
>
> BTDT. â??Could be left outâ? without even a comment as to why this would be a
> bad idea is equivalent to a recommendation. Especially to a beginner.

I completely disagree. I was listing some variations that could make the
code more compact, which is what the OP asked for. I followed by saying
that I would do the opposite of what I just described. If you really
read that as advice, I have to repeat: learn to read.

>>>> - Explicitly referring to the `window` object is optional;
>>>
>>> Cite evidence.
>>
>> No, do your own homework.
>
> IOW, you do not substantiate your claim, so we can safely assume it is
> nonsense based on wishful thinking and insufficient testing.

A - statement
B - give evidence
A - no
B - statement is therefore false

If this passes as logic for you, it explains a lot. Nevermind that we're
talking about exactly this topic in the next paragraphs...

Let me just reiterate that I am in no way advocating setting the
property implicitly. I was merely pointing out that it is possible and
legal.

>> If you're actually going to assume that `onload` is somehow in danger of
>> being something other than intended, then `window` is affected in exactly
>> the same way.
>
> No, because â??window.onloadâ? is always a property access, a standalone
> â??onloadâ? is not always one.

I don't see what difference the type of access makes. Both `window` and
`onload` can be set to anything. Note that in current browsers this is
no longer possible in the top scope, since neither are writable, but you
can still do this:

(function () {
var window = {};
window.onload = ...
})();

(function () {
var onload = {};
onload = ...
})();

And they both break just the same. So the "Really Bad Idea" is actually:
don't shadow the names of built-in objects or properties and then rely
on them. This is neither new nor surprising.

>>> What if it is strict mode code?
>>
>> 1) Nothing. Not a problem.
>
> Incorrect. Assignment to a non-existing property of a distinct object is
> relatively harmless in strict mode. Reference, and particularly assignment,
> to an identifier that fails to be resolved at the top end of the scope chain
> throws a ReferenceError exception in strict mode instead.

Does not apply, because `onload` can _always_ be resolved at the top of
the scope chain. It is a specified predefined property of the Window
object. Now demonstrate how assignment to bare `onload` can trigger a
ReferenceError in a document (strict mode or not).

> Also, since one
> cannot know the scope chain in an HTML document with certainty, with an
> identifier there is always the possibility that there is an object in the
> scope chain before that has a corresponding property. For example, it could
> be the object referred to by the â??formâ? or â??documentâ? property.

That's the same non-argument as above. Stuff can be shadowed, big whoop.

>> 2) We know the code, we're not in global strict mode.
>
> We know the *current* code of a *beginner*.

The OP has asked a specific question and given us all the context we
need. He even included a function-level "use strict" statement. The
assumption that we're somehow in global strict mode anyway is ludicrous.

>>> Yes, the event listener should be added. But [addEventListener()] does
>>> not work in IE < 9, and IE 9 in Compatibility Mode. [...]
....
>> Anyway, this is easily fixed by using an additional `false` argument.
>
> Nonsense. The method itself is not available in the named circumstances.

Right, I noticed that as soon as I hit reply. I thought about posting an
addendum, but I thought I'd let you have a win.


- stefan