Subjects and lessons to explore.

Law

Web Development · Foundations

Events

9 min read 5 practice questions
7 key termsSourcesReport an error
Want it in plain words first? Jump to Eli explains — the same idea, no jargon.
On this page 9 sections
  1. In 30 seconds
  2. Why this matters
  3. The college version
  4. Eli explains
  5. Worked example
  6. Key takeaway
  7. Quick check
  8. Study tools
  9. Sources & references

In 30 seconds

A browser is an object that signals an occurrence, such as a user activating a button or a page finishing a load. Code can register an with addEventListener() so a runs when a matching event is dispatched. The event object tells the listener about that occurrence. Some events also have a default browser action that a listener can prevent deliberately.

Why this matters

Events connect JavaScript to what happens in a page. They let an interface respond to an activation, a keystroke, a loaded resource, or another platform occurrence without repeatedly checking every element. Understanding listener registration, the event object, and default actions helps students trace behavior responsibly. It also creates a base for later topics on forms, the DOM, accessibility, asynchronous work, and event delegation without treating those larger subjects as interchangeable.

The college version

Events and event targets

The DOM Standard describes events as objects dispatched to objects to signal an occurrence, including user interaction and network activity. An object that implements the EventTarget interface can have event listeners. In ordinary page code, elements such as a button are familiar event targets, but the idea is broader: window, document, and some other web-platform objects can also receive events. The event has a type, such as click or load. A listener is registered for a particular type, so a listener for click is not a general instruction to run on every possible occurrence.

The usual registration API is target.addEventListener(type, callback, options). The type is a string naming the , and the callback is code the platform calls when a matching event reaches that listener. Registering the listener does not run the callback immediately. The callback runs later when the relevant event is dispatched. This separation is the core event-driven pattern: first describe what should happen, then let the platform invoke it when the occurrence happens. This lesson focuses on that basic pattern, rather than on selecting DOM elements, form validation, or security handling.

The event object and listener context

When the listener callback is invoked, it normally receives an event object. The object carries information about the particular event. Its type identifies the event type. Its target is the object to which the event was dispatched. Its currentTarget is the object whose listener is currently being invoked. These can be the same in a simple direct listener. They can differ when an event travels through a document tree and a listener is attached on an ancestor: the descendant that originated the event can be target, while the ancestor handling the listener can be currentTarget.

The DOM event model includes capture, target, and bubble phases. Many beginner listeners use the default option, which does not request capture. For common bubbling events, an event can then be observed by a listener on an ancestor after it is handled at its target. That fact supports a later pattern called event delegation, but delegation is not required to understand a single listener. More importantly, target should not be treated as a synonym for the element where every listener was registered. Read the event object and the registration site together. A listener can also be removed with removeEventListener() when supplied the matching type, callback, and relevant capture setting; this helps avoid behavior that should no longer be active.

Default actions and cancellation

Some events are cancelable and have a supplied by the user agent. For example, following a link after an activation is a familiar default action. Calling event.preventDefault() tells the user agent not to perform that default action for a cancelable event. It does not stop other listeners from running, and it does not automatically stop the event from moving through the event path. Those are separate concerns: stopPropagation() concerns propagation, while preventDefault() concerns a default action. A call to preventDefault() on a non-cancelable event has no effect on a default action.

Cancel a default action only when code provides an intentional alternative. For instance, a client-side interaction might manage an action itself, but an ordinary link should not be blocked simply because a listener exists. This is especially relevant for keyboard and assistive-technology use: behavior should preserve a meaningful, operable control rather than replacing it with an unannounced side effect. addEventListener() is generally preferable to assigning an on... property when code needs multiple independently registered listeners, because the API maintains an event-listener list. A listener callback should do focused work, use the event data it needs, and avoid assuming that every event shares the same cancelability, target, or propagation behavior.

Eli, the EliExplains learning guide

Eli explains

The same idea, in plain words

Explain it like I’m 10

An event is like a small notice that says something happened. A button can send a notice when someone activates it. A listener is the instruction you leave with the button: when that kind of notice arrives, run this little job. The listener gets an event object, like the notice card itself, so it can inspect what happened. Some notices would normally trigger a built-in browser action. If the event is cancelable, code can say preventDefault() to stop that built-in action—but only when it has a clear replacement.

Picture it like this

Imagine a school office has notice boards for different announcements. You pin a specific instruction under the ‘fire drill’ board, not under every board. When a drill notice arrives, the office follows that instruction. The notice says what kind of announcement it is and where it began. Some announcements have an automatic next step unless the office explicitly cancels it.

Where the picture stops working

Browser events are software objects, not paper notices, and dispatch can follow capture and bubble rules through a document tree. A browser default action also has precise platform rules; it is not an office worker freely choosing what to do.

Worked example

This listener has one job: record a cancelable save event and prevent its default action. const target = new EventTarget(); const log = []; const recordSave = event => { log.push(event.type); event.preventDefault(); }; target.addEventListener("save", recordSave); const allowed = target.dispatchEvent(new Event("save", { cancelable: true })); When this exact code was run with Bun, log became ["save"] and allowed was false. The callback ran because its registered type matched the dispatched event. The result was false because the event was cancelable and the listener called preventDefault(). In a page, the target might instead be a button and the event might be a browser-dispatched click; this example isolates the event mechanics without needing a page or a form.

Key takeaway

Use addEventListener() to register focused callbacks for named event types. Inspect the event object, and prevent a cancelable default action only when the interaction has a deliberate alternative.

Quick check

3 questions here, of 5 in this lesson’s practice set. Answers stay hidden until you check.

Question 1 of 3foundational

What does addEventListener("click", handler) primarily do?

Choose an answer, then check it.
Question 2 of 3intermediate

A listener is attached to a parent element, but a child element is the event's dispatch target. Which property identifies the parent while that parent's listener runs?

Choose an answer, then check it.
Question 3 of 3intermediate

What is the direct purpose of event.preventDefault() on a cancelable event?

Choose an answer, then check it.
Practice all 5

Keep learning

Ready to build on this? Continue to the next lesson.

Practice this lesson
Study tools & related lessonsYou’ll learn to · Common mistakes · Easily confused · Key vocabulary · Related

You’ll learn to

  • Define an event, event target, event listener, and callback.
  • Explain how addEventListener() associates a callback with an event type.
  • Distinguish event.target from event.currentTarget in a listener.
  • Predict the effect of preventDefault() on a cancelable default action.
  • Apply a listener to a small event-driven scenario.

Common mistakes

  • Expecting addEventListener() to execute the callback while registering it.

    Registration records the callback; invocation occurs when a matching event is dispatched.

  • Calling preventDefault() to stop all other listeners.

    It addresses a cancelable default action; it does not by itself stop propagation or other listeners.

  • Assuming event.target always names the object whose listener is running.

    Compare target with currentTarget, especially when an ancestor has the listener.

  • Blocking a native action without offering an intentional replacement.

    Prevent a default action only when the resulting interaction remains purposeful and operable.

Easily confused

event.target vs. event.currentTarget

target is the object to which the event was dispatched; currentTarget is the object whose listener is currently being invoked.

preventDefault() vs. stopPropagation()

The first prevents a cancelable default action; the second addresses event propagation and does not itself cancel a default action.

Key vocabulary

event
An object dispatched by the platform to signal an occurrence.
event target
An object that can have event listeners and can be involved in event dispatch.
event listener
A registered callback that observes a specified event type on an event target.
callback
A function supplied to an API so that the API can invoke it later.
event type
The string that identifies a category of event, such as click or load.
default action
Behavior the user agent performs for a cancelable event unless it is prevented.
cancelable
Describes an event for which preventDefault() can signal that its default action should not occur.

Sources & references

  1. EventTarget: addEventListener() method — MDN Web Docs
  2. Event: preventDefault() method — MDN Web Docs
  3. DOM Standard: Events — WHATWG

EliExplains lessons are original prose written from the open, credible references above. See Copyright & Licensing.

Researched 2026-08-20

Educational content only. It is not medical, legal or professional advice. Found an error? Tell us.