2

Adding an event handler is pretty easy.

Now I'd like to inhibit default behavior, e.g. highlighting a text when keeping it touched for a while.

I found the preventDefault method. However I don't see how to provide the required event object to myFunction

<!DOCTYPE html>
<html>
<body>
<h1>Event Handling</h1>
<p ontouchstart="myFunction(true)" ontouchend="myFunction(false)">Touch this! </p>
<p id="demo">demo</p>

<script>
function myFunction(state) {
  document.getElementById("demo").innerHTML = (state? "Hello World": " ");
  event.preventDefault();  // how to get access to the event object ?
}
</script>

</body>
</html>

Or am I on the wrong search path?

Scott Marcus
  • 64,069
  • 6
  • 49
  • 71
datafiddler
  • 1,755
  • 3
  • 17
  • 30

2 Answers2

4

Adding an event handler is pretty easy.

It is. But, you're doing it the 25+ year old legacy way, which should not be used today.

The event object is not automatically passed to callbacks when you use the legacy inline event attributes, such as onXyz.

Instead, use the modern approach to event handling and use .addEventListener() separately in your JavaScript. Then, the event object reference will automatically be passed as the first argument to your callback.

Now, because you want to pass your own argument to your callback, you'll need to wrap your actual callback in an anonymous function that will be the the "official" event handler and that one will receive the event argument. Then, in that wrapper, you can call your desired function and pass along the event as well as your custom argument(s).

Since not all devices support touch events, you need to check to see if they are supported by the device before you use them. Below, I've done a basic feature detection check, but read this for more comprehensive approaches.

In addition, you may also want to prevent the event from bubbling up to ancestor elements that may have event handlers registered to them as well. If so, you should also add event.stopPropagation().

Also, you should avoid .innerHTML when you can (almost always) as it has performance and security implications. Since you aren't actually getting or setting any HTML, use .textContent.

<!DOCTYPE html>
<html>
<body>
<h1>Event Handling</h1>
<p class="touch">Touch this! </p>
<p id="demo">demo</p>

<script>
  // Get your DOM references just once instead of each time your functions run
  const touchP = document.querySelector(".touch");
  const demo = document.getElementById("demo");

  // Not all devices support touch events, you should check first.
  if(touchP.touchstart){
    // The registered callback function will automatically be passed an event reference
    touchP.addEventListener("touchstart", function(event){
      // You can now call your desired function and pass the event and your argument
      myFunction(event, true); 
    });

    touchP.addEventListener("touchend", function(event){
      myFunction(event, false)
    });
  } else {
    demo.textContent = "Touch not supported on this device.";
  }

  function myFunction(event, state) {
    event.preventDefault();
    event.stopPropagation(); // If you don't want the event to bubble

    // You probably didn't want a space character returned if state == false.
    // Instead, return an empty string: ""
    demo.textContent = state ? "Hello World" : "";
  }
</script>

</body>
</html>
Scott Marcus
  • 64,069
  • 6
  • 49
  • 71
  • You forgot some words in your statement. Should be "which I THINK should not be used today". – kaladin_storm Apr 05 '21 at 00:31
  • @kaladin_storm I did not. The use of inline event attributes causes real problems as evidenced by this question in the first place and documented in the link I shared. And, if you read that link, you would have found another that points to **the documentation for inline event attributes**, which states unequivocally ["do not use these"](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Building_blocks/Events#inline_event_handlers_%E2%80%94_dont_use_these). This is not an opinion. – Scott Marcus Apr 05 '21 at 00:37
  • @kaladin_storm I have been coding and teaching all of this since it was invented. The popular misconception about inline event attributes is that they seem to work just fine when you start off and do simple things with them. Then, when you start writing real production code, you find that they introduce all sorts of problems. Unfortunately, they just won't go away because browsers cannot stop supporting them for legacy reasons and most newbies just copy someone else's code that uses them without actually understanding how they work (or don't work). – Scott Marcus Apr 05 '21 at 00:39
  • Definitely an opinion. If if the big guys say not to use it. Absolutely nothing wrong with an inline event. – kaladin_storm Apr 05 '21 at 00:42
  • @kaladin_storm Definitely not and in my experience (and with due respect), you opinion is one that is shared by millions of developers who haven't reached a level of coding experience to fully understand this. Just because a browser supports something, does not make it correct. This is because of the way the BOM and the DOM evolved from way back before we had standards. Inline event attributes harken back to the days of DOM level 0 (before there was a standard DOM). If you won't take the word of the actual authorities on the subject (MDN is the steward of the JavaScript language), then sorry. – Scott Marcus Apr 05 '21 at 00:45
  • @kaladin_storm And frankly, I've laid out most the major reasons in the link I shared. Are you really saying that each of those points is an opinion? Do you understand that implicit global functions are created as wrapper around inline callback that alter `this` binding? Do you even know how to see those implicit wrappers? – Scott Marcus Apr 05 '21 at 00:47
  • Using a feature built into something that doesn't have a performance problem and doesn't actually break anything means it is an opinion when someone says you shouldn't use it. A coding practice is always an opinion. – kaladin_storm Apr 05 '21 at 00:48
  • Now. I do like to say that just because something supports a feature doesn't mean it should be used. But alas. That is my opinion. – kaladin_storm Apr 05 '21 at 00:50
  • @kaladin_storm As I just said, `this` binding does break, the `event` is not passed, and they can cause memory leaks in older browsers. Inline event attributes aren't a "feature", they are a leftover relic from a time before standards and the only reason they persist today is for backwards compatibility. But, good luck to you. One day, when you've gotten more experience, you will understand. – Scott Marcus Apr 05 '21 at 00:50
0

You have to pass the event to your function when you call it.

<p ontouchstart="myFunction(event, true)" ontouchend="myFunction(event, false)">Touch this! </p>

function myFunction(event, state) {
  document.getElementById("demo").innerHTML = (state? "Hello World": " ");
  event.preventDefault();  // how to get access to the event object ?
}

The event exist in the event declarations.

kaladin_storm
  • 352
  • 1
  • 7
  • Thanks, works well. (Even on my laptop with touchscreen, where Scott's solution shows "`Touch not supported on this device`") I've tried this (or something similar), and ran into errors that disappear now in a new test setup. – datafiddler Apr 05 '21 at 08:04