This is the 13th day of my participation in the August More text Challenge. For details, see: August More Text Challenge

Recently, I have been doing a series of summary questions on the front end, interested friends can add attention, welcome correction, communication.

Strive for each knowledge point to be able to sum up some more, at least to do in the interview, for each knowledge point can be kan, not dumb fire.

preface

In the click event listener function, the output value of this.id and event.target.id are different. In the click event listener function, the output value of this.id and event.target.id are different.

Today we’re going to look at how this works.

The title

There is an HTML document structure like this:

<div id="parent">
    <div id="child" class="child">Am I</div>
</div>
Copy the code

Execute the following JavaScript code for the first time:

document.getElementById("parent").addEventListener("click".function () {
    alert(The 'parent event is triggered,' + this.id);
});

document.getElementById("child").addEventListener("click".function () {
    alert('Child event is triggered,' + this.id);
});
Copy the code

The second time another set of JavaScript code is executed:

document.getElementById("parent").addEventListener("click".function (e) {
    alert(The 'parent event is triggered,' + e.target.id);
});

document.getElementById("child").addEventListener("click".function (e) {
    alert('Child event is triggered,' + e.target.id);
});
Copy the code

The questions are as follows:

What is the execution result of the JavaScript code after clicking on the div with ID child?

The answer is:

  • The first time the result is “Child event triggered, child” and then “parent event triggered, parent”.
  • The second time, the result is “Child event triggered, child” and then “parent event triggered, Child”.

When the parent event is triggered, the result of e.target. Id is child. Shouldn’t it be parent?

To reassure

DOM element event execution order

First, we know that the event execution order of DOM elements on HTML pages generally has three stages:

  • Event capture
  • Events trigger
  • The event bubbling

The whole process is shown below:

Event capture and event bubble

When an event occurs on an element that has a parent element (for example, a child element in our case), modern browsers run two different phases – the capture phase and the bubble phase. During the capture phase:

  • The browser checks the element’s outermost ancestor<html>, whether one was registered during the capture phaseonclickEvent handler, if so, run it.
  • And then, it moves to<html>Click on the element’s next ancestor and do the same, then click on the element and the next ancestor, and so on until you reach the element that was actually clicked.

In the bubbling phase, the opposite is true:

  • The browser checks to see if the element actually clicked is registered in the bubble phaseonclickEvent handler, if so, run it
  • Then it moves to the next immediate ancestor element and does the same, and then the next, and so on, until it arrives<html>Elements.

The two stages are shown in the figure below:

In modern browsers, by default, all event handlers are registered during the bubbling phase, which is why there is only one method that prevents bubbling, event.stopPropagation(), and no method that prevents capture, because it is completely unnecessary.

This and the event target

First, we need to have a clear understanding that event bubbling, or event capture, is for elements that have registered events.

Summary of this and event.target:

  • In the course of the event,event.targetAlways point to the element that actually triggers the event flow, that is, the element in the event touch phase.
  • This is a reference to the element for which the event is being executed. This and event.currenttarget refer to the element for which the listening event is being executed.

Event also has an attribute event.srcElement, which is an alias for event.target, but is a non-standard attribute and should not be used in production environments as much as possible.

To prevent a bubble

Suppose you have the following code:

parent.onclick = function1;
child.onclick = function2;
Copy the code

When we click the child, since the event is registered in the bubble phase by default, not only function2 will be executed, but function1 will be executed later, which may not be what we expect. We would prefer that their click events do not affect each other.

To do this, just add event.StopPropagation () to Function2.

extension

Now let’s add another copy of the JavaScript code in the title:

document.getElementById("parent").addEventListener("click".function (e) {
    alert(The 'parent event is triggered,' + e.target.id);
}, false);

document.getElementById("child").addEventListener("click".function (e) {
    alert('Child event is triggered,' + e.target.id);
}, true);
Copy the code

Question 1: If I click the Child element, what is the output?

Question 2: If I click on the parent element, what is the output?

As you can see, now the parent’s click event is executed in the bubble phase and the Child’s click event is executed in the capture phase.

For question 1, since the parent is registered to execute in the bubble phase, its events are executed in the bubble phase after the child trigger phase, so the answer should be: “Child event trigger, Child” first, then “Parent event trigger, Child”.

For problem 2, although the child registers the capture phase execution event, but the parent event process capture can not reach it, so the answer should be: only popup “parent event triggered, parent”.

conclusion

Above we have analyzed so much, in fact, summed up the following:

  • The event.target points to the element that triggered the event process and does not change.
  • This refers to the registration element for the currently executing event.
  • Capture stops at event.target, and bubbling begins at event.target.
  • Major browsers default to event registration during the bubbling phase, so there is only a way to prevent bubbling but no way to prevent capture.
  • The third argument in the element’s addEventListener method, true or false, has no effect on the flow of events that the element itself fires, only after its parent or child has fired the same event.

Small problems also have big roots, dare to discover, dare to explore!

~

Thanks for reading!

~

Learn interesting knowledge, make interesting friends, and create interesting souls!

Hello everyone, I am the author of “programming Samadhi” Hermit King, my public number is “programming Samadhi”, welcome to pay attention, I hope you can give me more advice!

You come, with expectations, I have the ink to greet! You return, regardless of gain and loss, only with aftertaste!

Both knowledge and skill, internal force and external work, both theory and practice should grasp, both hands should be hard!