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 CB87F787E9 for ; Fri, 26 Jan 2018 02:38: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 12BAB1F6 for ; Fri, 26 Jan 2018 02:38:17 -0800 (PST) Received: from carhart.net (localhost [127.0.0.1]) by carhart.net (8.13.8/8.13.8) with ESMTP id w0QAcGOY002706 for ; Fri, 26 Jan 2018 02:38:16 -0800 Received: from localhost (kevin@localhost) by carhart.net (8.13.8/8.13.8/Submit) with ESMTP id w0QAcFA2002700 for ; Fri, 26 Jan 2018 02:38:16 -0800 Date: Fri, 26 Jan 2018 02:38:15 -0800 (PST) From: Kevin Carhart To: Edbrowse-dev@lists.the-brannons.com In-Reply-To: <20180026040830.eklhad@comcast.net> Message-ID: References: <20180019150815.eklhad@comcast.net> <20180026040830.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 10:38:04 -0000 Hi Karl > > So all of this doesn't answer my question. I think you only have to run onclick, because the "click" system is running all the time. As long as we provide a DOM, and the ID and name and class attributes are all standard, the code is establishing, removing, and calling all the time. And also due to the presence of side effects like instant innerHTML. That Drescher site is an example. One of the links triggers ajax, and this is not tied either to a hyperlink or inline "on" handler. There's another source. The hyperlink has standard IDs, so our DOM methods rope it in to a set that is queried for with the GetElements functions. Then, because that certain was in the result set, it gets a click handler doled out to it which then works for the user. So we're doing both already - I think. >> I think isn't it also true that all of the attributes beginning with "on" are >> one-of-a-kind entities? > > Do you mean there is just one of them? I don't think so. > I think some websites start with onclick= in html, for a handler, then add another one via javascript and they are both suppose to run, at least I sort of remember that but can't point to a specific site right now. > So my code supports this. > If there is already a function onclick, that becomes onclick array[0], and the next one pushes and so on. > That's what I do, and it may not be right, but I don't think it's wrong. Sorry, I sort of mixed two connotations here. In that particular thing about the one-of-a-kind entities, I was only trying to refer to the fact that you have hand-tailored work such as the function set_onhandlers() in decorate, which does a lot for a small number of useful inline handlers. So this might coexist comfortably with a different system that is suited for dynamic naming that does not need to have been delineated at compile time. But the other thing you raised from this was: > Do you mean there is just one of them? I don't think so. I think we have it from the horse's mouth from a mozilla page. https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Event_handlers The Web platform provides several ways to get notified of DOM events. Two common styles are: the generalized addEventListener() and a set of specific on-event handlers. This page focuses on the details of how the latter work. ... The on-event handlers are a group of properties offered by DOM elements to help manage how that element reacts to events. Elements can be interactive (e.g. links, buttons, images, forms) or non-interactive (e.g. the base document). Events are the actions like being clicked, detecting pressed keys, getting focus, etc. The on-event handler is usually named according to the event it is designed to react to, such as onclick, onkeypress, onfocus, etc.... Note that each object can have only one on-event handler for a given event (though that handler could call multiple sub-handlers). This is why addEventListener() is often the better way to get notified of events, especially when wishing to apply various event handlers independently from each other, even for the same event and/or to the same element.