Re: [Edbrowse-dev] nasa / prepending "on" to events

[Kevin Carhart <kevin@carhart.net>]

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 would run based on the element's 
presence or absence from a set which had had a handler 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 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 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 like "onclick", "onchange", "onsubmit" are called out for 
potentially unique code for each one.  So I think the addEventHandler 
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 called 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.