From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: None (mailfrom) identity=mailfrom; client-ip=8.23.224.60; helo=out.smtp-auth.no-ip.com; envelope-from=kevin@carhart.net; receiver= Received: from out.smtp-auth.no-ip.com (smtp-auth.no-ip.com [8.23.224.60]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 2E7DE787E9 for ; Fri, 26 Jan 2018 00:21:03 -0800 (PST) X-No-IP: carhart.net@noip-smtp X-Report-Spam-To: abuse@no-ip.com Received: from carhart.net (unknown [99.52.200.227]) (Authenticated sender: carhart.net@noip-smtp) by smtp-auth.no-ip.com (Postfix) with ESMTPA id 1E18E513 for ; Fri, 26 Jan 2018 00:21:16 -0800 (PST) Received: from carhart.net (localhost [127.0.0.1]) by carhart.net (8.13.8/8.13.8) with ESMTP id w0Q8LFph007648 for ; Fri, 26 Jan 2018 00:21:15 -0800 Received: from localhost (kevin@localhost) by carhart.net (8.13.8/8.13.8/Submit) with ESMTP id w0Q8LEDi007645 for ; Fri, 26 Jan 2018 00:21:14 -0800 Date: Fri, 26 Jan 2018 00:21:14 -0800 (PST) From: Kevin Carhart To: Edbrowse-dev@lists.the-brannons.com In-Reply-To: Message-ID: References: <20180019150815.eklhad@comcast.net> <20180026014313.eklhad@comcast.net> User-Agent: Alpine 2.03 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [Edbrowse-dev] nasa / prepending "on" to events X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.25 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 08:21:03 -0000 I should fix my semantics. I realized that I use "handlers" to refer to both kinds of things and it could be unclear. If it makes sense from context, you can ignore the following, but I am going to clean this up slightly if you want to read this revision instead. On Fri, 26 Jan 2018, Kevin Carhart wrote: I am not positive, but I think we're doing both systems right, and the two systems coexist. An element could have onclick and click$$array. It could respond to onclick() and click(), and they could both be sitting there. I think the former is called in a more narrow case, if it exists on that element, and also I believe that there is only one at a time, and if you set a new one, it clobbers the old. Since the latter is an array, there could be any number. > >> When you click on a button or link, are we suppose to try to run both >> click() and onclick()? >> If not, then when on earth do the click() handlers run? I think that the click() handlers [LISTENER-BASED] would run based on the element's presence or absence from a set which had had a handler [LISTENER-BASED] applied, while onclick is a single function and would run if it had been established either in HTML or by defining the function on that thing. I think the handlers [LISTENER-BASED] are less individual. If it's a div, and there was code that said getElementsByTagName("div").addEventListener("click",code), then the ultimate effect is that the element in question has had that handler [LISTENER-BASED] doled out to it as part of a set of 30 or some total. So it's the efficiency of not having to think about that work as much, the way you don't have to think about every intersecting position in two nested loops. I think isn't it also true that all of the attributes beginning with "on" are one-of-a-kind entities? For instance, in decorate.c, lists of handlers [INDIVIDUAL FUNCTION-BASED] like "onclick", "onchange", "onsubmit" are called out for potentially unique code for each one. So I think the addEventListener system is geared for intra-javascript, where the event names themselves might be "x1", "x2" and "x3" and the naming could itself be based on control structures or any type of logic. It could be as ephemeral as any variable. So every possible event name does not have hardcoded presence. It's a genericization. Ah, so I thought of a reason why these two things both exist. It makes sense to hardcode onload, because there is only one, and you would not get any performance or workload benefit out of being able to parameterize it. It's correct to say onload. I think it's historical - those 30 things have specific definition in HTML, while the listener system opens it up so that events can be named anything. Here's one more short reference which I thought was pretty good. It's part of a stackoverflow page, by Michal Perlakowski, early 2016. The original is https://stackoverflow.com/questions/6348494/addeventlistener-vs-onclick --- In this answer I will describe the three methods of defining DOM event handlers. 1. element.addEventListener() element.addEventListener() has multiple advantages: o Allows you to register unlimited events handlers and remove them with element.removeEventListener(). o Has useCapture parameter, which indicates whether you'd like to handle an event in its capturing or bubbling phase. o Cares about semantics. Basically, it makes registering event handlers more explicit. For a beginner, a function call makes it obvious that something happens, whereas assigning event to some property of DOM element is at least not intuitive. o Allows you to separate document structure (HTML) and logic (JavaScript). In tiny web applications it may not seem to matter, but it does matter with any bigger project. It's way much easier to maintain a project which separates structure and logic than a project which doesn't. o Eliminates confusion with correct event names. Due to using inline event listeners or assigning event listeners to .onevent properties of DOM elements, lots of inexperienced JavaScript programmers thinks that the event name is for example onclick or onload. on is not a part of event name. Correct event names are click and load, and that's how event names are passed to .addEventListener(). o Works in almost all browsers. If you still have to support IE <= 8, you can use a polyfill from MDN. 2. element.onevent = function() {} (e.g. onclick, onload) This was a way to register event handlers in DOM 0. It's now discouraged, because it: o Allows you to register only one event handler. Also removing the assigned handler is not intuitive, because to remove event handler assigned using this method, you have to revert onevent property back to its initial state (i.e. null). o Doesn't respond to errors appropriately. For example, if you by mistake assign a string to window.onload, for example: window.onload = "test";, it won't throw any errors. Your code wouldn't work and it would be really hard to find out why. .addEventListener() however, would throw error (at least in Firefox): TypeError: Argument 2 of EventTarget.addEventListener is not an object. o Doesn't provide a way to choose if you want to handle an event in its capturing or bubbling phase. 3. Inline event handlers (onevent HTML attribute) Similarly to element.onevent, it's now discouraged. Besides the issues that element.onevent has, it: o Is a potential security issue, because it makes XSS much more harmful. Nowadays websites should send proper Content-Security-Policy HTTP header to block inline scripts and allow external scripts only from trusted domains. o Doesn't separate document structure and logic. o If you generate your page with a server-side script, and for example you generate a hundred links, each with the same inline event handler, your code would be much longer than if the event handler was defined only once. That means the client would have to download more content, and in result your website would be slower.