From: Kevin Carhart <kevin@carhart.net>
To: Edbrowse-dev@lists.the-brannons.com
Subject: Re: [Edbrowse-dev] nasa / prepending "on" to events
Date: Fri, 26 Jan 2018 00:21:14 -0800 (PST) [thread overview]
Message-ID: <alpine.LRH.2.03.1801260011320.27769@carhart.net> (raw)
In-Reply-To: <alpine.LRH.2.03.1801252312530.27769@carhart.net>
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.
next prev parent reply other threads:[~2018-01-26 8:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-19 20:08 [Edbrowse-dev] Error Object Karl Dahlke
2018-01-19 20:51 ` Dominique Martinet
2018-01-25 10:48 ` [Edbrowse-dev] defaultView / cloning onevent$$array Kevin Carhart
2018-01-25 14:07 ` Karl Dahlke
2018-01-25 23:07 ` Kevin Carhart
2018-01-26 2:58 ` Karl Dahlke
2018-01-26 3:50 ` [Edbrowse-dev] nasa / prepending "on" to events Kevin Carhart
2018-01-26 4:59 ` Karl Dahlke
2018-01-26 5:51 ` Kevin Carhart
2018-01-26 6:43 ` Karl Dahlke
2018-01-26 8:10 ` Kevin Carhart
2018-01-26 8:21 ` Kevin Carhart [this message]
2018-01-26 9:08 ` Karl Dahlke
2018-01-26 10:38 ` Kevin Carhart
2018-01-26 14:32 ` Karl Dahlke
2018-01-26 19:13 ` Geoff McLane
2018-01-26 19:28 ` Karl Dahlke
2018-01-27 3:52 ` Kevin Carhart
2018-01-27 18:52 ` Geoff McLane
2018-01-27 21:10 ` Karl Dahlke
2018-01-28 3:12 ` Karl Dahlke
2018-01-28 19:19 ` Geoff McLane
2018-01-28 21:35 ` Karl Dahlke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LRH.2.03.1801260011320.27769@carhart.net \
--to=kevin@carhart.net \
--cc=Edbrowse-dev@lists.the-brannons.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).