Path: csiph.com!news.mixmin.net!weretis.net!feeder1.news.weretis.net!news.solani.org!.POSTED!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: comp.lang.javascript Subject: Re: onload and onclick Date: Tue, 29 Mar 2016 02:04:38 +0200 Organization: PointedEars Software (PES) Lines: 130 Message-ID: <21488317.CWynO2UuzJ@PointedEars.de> References: <3360887.gmJMtLSuvG@PointedEars.de> Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Trace: solani.org 1459209879 10211 eJwNxskBACAIA7CVVKDQcfBg/xEkr5hg4rjCoFZWT0fcN29wB6VWooLosQmXGzWHpsvxLYkPEmgQdA== (29 Mar 2016 00:04:39 GMT) X-Complaints-To: abuse@news.solani.org NNTP-Posting-Date: Tue, 29 Mar 2016 00:04:39 +0000 (UTC) User-Agent: KNode/4.14.2 X-User-ID: eJwVx8ERACEIBLCWFHZBykE4+i/BufxCtW3lMBo4nE7xbgH+qdaIO298ce2gRLsyazN9lkuqV5CyBnVPdgweWGgVxw== Cancel-Lock: sha1:mbXIG4c6eUz3Tz+xtlhDnDoK9JM= X-NNTP-Posting-Host: eJwFwQkBwDAIA0BLfAlMTqHFv4TdwamcDIKBxZrxRDE/uN1+PjmLfiltFtASiYGe2ZpQXvwMGRCY Xref: csiph.com comp.lang.javascript:30148 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: >> >> > > 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: | SVN: Twitter: @PointedEars2 | ES Matrix: Please do not cc me. / Bitte keine Kopien per E-Mail.