edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
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.

  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).