Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #30148

Re: onload and onclick

Show all headers | View raw

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-scripting-apis>
> 
> 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.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

onload and onclick emf <emfril@gmail.com> - 2016-03-28 08:07 -0400
  Re: onload and onclick Stefan Weiss <krewecherl@gmail.com> - 2016-03-28 22:47 +0200
    Re: onload and onclick Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-28 23:23 +0200
      Re: onload and onclick Frank Kozuschnik <franko@nurfuerspam.de> - 2016-03-29 00:20 +0200
        Re: onload and onclick Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-29 00:43 +0200
      Re: onload and onclick Stefan Weiss <krewecherl@gmail.com> - 2016-03-29 00:57 +0200
        Re: onload and onclick Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-29 02:04 +0200
          Re: onload and onclick Stefan Weiss <krewecherl@gmail.com> - 2016-03-29 04:47 +0200
            Re: onload and onclick Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-31 20:06 +0200
              Re: onload and onclick Aleksandro <aleksandro@gmx.com> - 2016-03-31 15:37 -0300
              Re: onload and onclick Stefan Weiss <krewecherl@gmail.com> - 2016-04-02 01:43 +0200
    Re: onload and onclick Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-29 00:33 +0200
    Re: onload and onclick Stefan Weiss <krewecherl@gmail.com> - 2016-03-29 05:03 +0200
    Re: onload and onclick emf <emfril@gmail.com> - 2016-03-29 01:45 -0400
  Re: onload and onclick Aleksandro <aleksandro@gmx.com> - 2016-03-28 18:33 -0300

csiph-web