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.
_______________________________________________
Edbrowse-dev mailing list
Edbrowse-dev@lists.the-brannons.com
http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev