Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.javascript > #35978

Re: Attributes containing JavaScript

From Thomas 'PointedEars' Lahn <PointedEars@web.de>
Newsgroups comp.lang.javascript
Subject Re: Attributes containing JavaScript
Date 2019-02-05 17:41 +0100
Organization PointedEars Software (PES)
Message-ID <ee0cb136-b0aa-ec5e-5fb5-ded1b3166b04@PointedEars.de> (permalink)
References <onclick-20190205125626@ram.dialup.fu-berlin.de>

Show all headers | View raw


Stefan Ram wrote:
>   From the point of programming style, how do you assess the
>   following two approaches to add a click-handler?
> 
>   1.) Add the handler in JavaScript
> 
> <span id="span">

The ID that has been chosen here is unwise at best: also, the markup is
incomplete (there is no end tag) and therefore invalid.

> ..
> incrementSpan = () => span.innerHTML = +span.innerHTML + 1;

Reading and writing the “innerHTML” property requires serialization and
deserialization of the document tree.

If the content does not contain markup, the “textContent” property should
be used instead, which is more efficient, less error-prone, and more secure
(code injection is not possible this way).  Even if the content contains
markup, it is more efficient and secure to only modify the “textContent”
property of the child elements whose content is supposed to change.

> span.addEventListener( "click", incrementSpan );
> 
>   2.) Add the handler in HTML
> 
> <span id="span" onclick="span.innerHTML = +span.innerHTML + 1">0</span>
> 
>   (end of "2.)")
> 
>   What are the advantages and disadvantages of each approach?

There are those who say that the separation of script and HTML is an
inherent advantage of the first approach.  Although I do see certain
advantages in that, I am not one of those people.

A disadvantage of the first approach is the dependency on a particular
event model (and the need to handle alternative models, although those
are technically obsolete now) and decreased transparency as to what the
document does.  There is also the possibility that the document does not
do what is intended before a sufficient number of its components have
been loaded.

A disadvantage of the second approach is the risk of writing “spaghetti
code”, and having to deal with the possibility that characters
in script code need to be escaped that have significance in markup.

An advantage of the second approach is that the event listener can be
removed without relying on a framework with an event registry by assigning
the “null” value to the corresponding event-handler property.  However,
further event listeners may have been added to the same element for the same
event which would not be removed this way.  If *only* the second approach is
followed, that is also one of its disadvantages.

Because there is a third option: Something to the effect of

  <script>
    var my = {
      incrementSpan (target) {
        target.textContent = (+target.textContent) + 1;
      }
    };
  </script>
  …
  <span id="span" onclick="my.incrementSpan(this)">0</span>

There are probably lengthy discussions about this all over the Web.
Read, think, post.  In *that* order.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

Back to comp.lang.javascript | Previous | Next — Next in thread | Find similar | Unroll thread


Thread

Re: Attributes containing JavaScript Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-02-05 17:41 +0100
  Re: Attributes containing JavaScript Julio Di Egidio <julio@diegidio.name> - 2019-02-05 10:51 -0800
  Re: Attributes containing JavaScript Julio Di Egidio <julio@diegidio.name> - 2019-02-06 20:19 -0800

csiph-web