JavaScript Events and Forms

🎯Learning Objectives

• Level 16 updated a document tree.
• This lesson decides when and why those updates happen.
• You will attach listeners, inspect an event, trace its propagation, distinguish cancellation from propagation control and handle a form’s submission deliberately.

• Our running task is a local workshop-request preview.
• The learner supplies fictional contact details, chooses a session and requests places.
• The page checks input, shows field-specific errors and exposes the resulting form data locally.
• The purpose is to understand events and validation, not to book a real workshop.

⚡Events — A Signal That Something Happened

• An event represents an occurrence, such as a click, an input change or a form submission.
• The browser dispatches an event object through the relevant targets.
• A listener responds to it with a function.

• Choose an event for the task rather than attaching every action to a pointer gesture.
• A native button’s click can be activated through supported keyboard interaction.
• A form’s submit event supports the submission workflow beyond a particular button click.

• A programmatically dispatched event is useful for a controlled test, but it does not automatically prove the browser’s full native interaction or validation behavior.
• Test the actual control as well as the handler.

🔌addEventListener — Pass the Function

• AddEventListener registers a callback for an event type.
• Pass the function itself, not the result of immediately calling it.
• A named callback is useful when you need to remove the same listener later.

• Repeatedly adding distinct anonymous functions can create multiple handlers even if their bodies look identical.
• For a setup routine that can run more than once, guard initialization or manage listener cleanup.

• HTML onclick attributes mix behavior into markup and can make maintenance harder.
• This lesson registers listeners in the external lesson script and keeps its native controls understandable from their HTML.

function showDetails(event) {
  console.log(event.type);
}
button.addEventListener("click", showDetails);
// Later, when this listener is no longer needed:
button.removeEventListener("click", showDetails);

• RemoveEventListener needs the matching event type, callback identity and capture setting.
• Rewriting a visually identical arrow function does not supply the original callback object.

🎯Event Object — target and currentTarget

• Event.target identifies the target associated with the dispatch as exposed to the listener.
• CurrentTarget is the object whose listener is currently running.
• In our simple light-DOM example, clicking a span inside a link can make the span the target while the link remains currentTarget for its own listener.

• Event.type identifies the event kind.
• EventPhase distinguishes capture, at-target and bubble processing.
• DefaultPrevented indicates whether a cancelable event’s default action has been canceled.

• Read or copy currentTarget during the listener if you need it later.
• Its value is tied to listener invocation and is normally null after dispatch finishes.
• Complex cases such as shadow DOM can retarget events; this lab uses an ordinary nested light-DOM structure.

link.addEventListener("click", event => {
  const observed = {
    type: event.type,
    target: event.target.id,
    listener: event.currentTarget.id,
    phase: event.eventPhase
  };
  console.log(observed);
});

The event-path lab records these values synchronously rather than storing the event object and later assuming currentTarget still names the listener.

🧭Capture, Target and Bubble

• For a bubbling click, ancestor capture listeners run toward the target, target listeners run, then ancestor bubble listeners run outward.
• A listener registered with capture: true observes the capture side of that path.

• Our playground has an outer region, an inner region and a link containing a span.
• Its observed listeners normally run outer capture, inner capture, link listener, inner bubble and outer bubble.
• If the span is clicked, the link is an ancestor of the actual target; if the link itself is the target, its own listener runs at target.

• Not every event bubbles.
• Focus and blur differ from bubbling focusin and focusout, for example.
• Choose an event and inspect its propagation rules before relying on a parent listener.

outer.addEventListener("click", observe, { capture: true });
inner.addEventListener("click", observe, { capture: true });
link.addEventListener("click", observe);
inner.addEventListener("click", observe);
outer.addEventListener("click", observe);

🛑preventDefault and stopPropagation

• PreventDefault asks the browser to cancel an event’s default action when the event is cancelable.
• For a link click, that can cancel navigation.
• It does not automatically stop propagation to other listeners.

• StopPropagation prevents further propagation beyond the current processing point.
• It does not by itself cancel navigation or prevent every other listener on the same node from running.
• StopImmediatePropagation also stops later listeners on the same node for that event.

• Passive listeners cannot cancel default actions through preventDefault.
• Use a passive listener for suitable observation, such as a scroll-related listener that does not need to cancel interaction, rather than setting passive blindly.

link.addEventListener("click", event => {
  event.preventDefault(); // cancel navigation if cancelable
  // Ancestor bubble listeners can still run.
});

• In the playground, “Cancel navigation” still records all five observed listeners.
• “Stop propagation” records the two capture listeners and the link listener while its local fragment navigation remains available.

🔗Delegation — Listen on a Stable Parent

• Delegation uses a suitable ancestor listener to handle events from its descendants.
• It is useful when cards are inserted after initialization because the parent listener can remain in place.
• It requires an event that reaches the parent and careful target checking.

• Closest can find a relevant button when the click landed on a nested icon or span.
• Then confirm that the chosen control belongs to the intended container.
• This avoids letting a broadly matched button trigger an unrelated action.

• Keep the action name controlled and meaningful.
• Delegation is a listener organization technique, not permission to execute arbitrary text from a data attribute.

list.addEventListener("click", event => {
  const button = event.target.closest("button[data-action]");
  if (!button || !list.contains(button)) return;
  if (button.dataset.action === "details") {
    showWorkshopDetails(button.dataset.id);
  }
});

• A listener stopped before reaching list will not be observed by this delegation example.
• Inspect the actual path when a dynamically added control appears inactive.

⌨️Click, Keyboard and Native Semantics

• Use a button for an action and a link for navigation.
• Native controls provide established keyboard behavior, focus handling and accessibility semantics.
• A clickable div requires additional work and can still behave inconsistently.

• Do not add a second Enter/Space activation handler to a native button without considering its native click behavior; that can duplicate the action.
• A custom control needs a deliberate keyboard contract, but the default choice should be a native control.

• Keydown is useful for tasks such as a documented shortcut.
• Preserve ordinary Tab navigation and text-entry keys unless the specific interaction requires handling them.
• Make the action available visibly as well as through a shortcut.

<button type="button" id="details">Show details</button>
<a href="#workshop-summary">Read workshop summary</a>

• The playground link can be activated by Enter.
• The registration preview uses a native submit button and a form submit listener.
• Native browser behavior remains part of the post-deployment test.

✍️input, change and Editing Feedback

• Input generally reports user-driven changes as they occur.
• Change reports a committed change according to the control’s behavior.
• Text inputs, selects and checkboxes do not all commit in exactly the same way.

• Assigning input.value from code does not automatically fire the input event.
• A program that needs a follow-up update should call its own update function or dispatch a deliberately chosen event with a clear purpose.

• Keep editing feedback calm.
• Clear a stale field error when its value is edited, then validate again on submission.
• Avoid stealing focus or announcing the entire form on every keystroke.

nameInput.addEventListener("input", () => {
  nameInput.setCustomValidity("");
  nameError.textContent = "";
  nameInput.removeAttribute("aria-invalid");
});

• Clearing an error means the stale message has been removed; it does not guarantee that the new entry meets every rule.
• The lab rechecks the complete form on its next submit attempt.

📝Forms — Names, Labels and Button Types

• A label names a control for the learner; a name attribute identifies a field in submitted form data.
• An ID helps connect the label and scripting.
• Those three roles should not be confused.

• Use type="submit" for the primary form action and type="button" for a local helper that should not submit.
• A button without an explicit type inside a form can submit unexpectedly.

• Required, type, min, max and step provide native constraints.
• A select can have an empty required placeholder.
• A checked checkbox can contribute its named value; an unchecked checkbox is omitted from ordinary FormData.

<form id="request">
  <label for="places">Places requested</label>
  <input id="places" name="places" type="number"
         min="1" max="4" step="1" required>
  <button type="submit">Preview request</button>
  <button type="button">Clear messages</button>
</form>

• The lab’s limits are teaching rules.
• Native client constraints improve feedback; a real receiving service must validate its own accepted data and business rules.

📨Handle submit on the Form

• A form submit listener handles the form workflow, including supported implicit submission and requestSubmit.
• Listening only to a particular button’s click can miss other ways the form is submitted.

• In the normal native workflow, failing interactive constraints can prevent submission before a submit event fires.
• The lab uses novalidate intentionally so its submit handler can show inline errors for every attempt, while still consulting native validity APIs.

• PreventDefault is called immediately in the lab’s submit listener because its result is a local preview.
• It does not send a request or navigate to a result page.
• The submit button is initially disabled until the script has installed its handler.

form.addEventListener("submit", event => {
  event.preventDefault();
  // Validate fields and display a local preview.
});

• One accepted click should produce one handling result.
• Do not duplicate the same validation in both a click listener and a submit listener when both would process the same attempt.

✅Native Validity and Custom Task Rules

• CheckValidity returns whether applicable controls satisfy their constraints and can fire invalid events.
• ReportValidity also asks the browser to present native feedback.
• Validity exposes flags such as valueMissing, typeMismatch, rangeOverflow and stepMismatch.

• SetCustomValidity supplies a custom error string.
• A non-empty message keeps the control invalid; clear it with an empty string when rechecking or after editing.
• Forgetting to clear it can leave a corrected field blocked.

• The request lab trims a 2–60-character display name, uses native single-email type checking with a 100-character limit, accepts a known session and integer places from 1–4, and checks that the selected session has enough places.
• HTML has three available places and JavaScript has two.
• A checked confirmation is required.

placesInput.setCustomValidity("");
if (requested > available) {
  placesInput.setCustomValidity("Request no more than the available places.");
}
const valid = form.checkValidity();

• The lab accepts decimal-digit place entries such as 2; fractional or exponential spellings are rejected.
• It checks native validity and displays inline messages rather than calling reportValidity for competing popup feedback.
• Email type checking is a syntax check, not proof of ownership or deliverability.

📦FormData — Inspect Successful Controls

• New FormData(form) collects successful named controls according to the form rules.
• Disabled controls are omitted.
• An unchecked checkbox is omitted.
• A name is needed for an ordinary field to contribute an entry.

• Text and numeric control values usually arrive as strings; a number input does not make FormData produce a Number.
• Repeated field names can have multiple entries, so getAll is useful when multiple values are intended.

• A submit button’s name/value depends on how the submitter is included.
• This lab’s submit button has no name and constructs FormData from the form.
• It shows the raw entries alongside an explicitly normalized places Number.

const data = new FormData(form);
const entries = Array.from(data.entries());
const places = Number(data.get("places"));
console.log(entries, places);

• The optional updates checkbox has value "yes" and appears only when checked.
• The required confirmation appears in accepted data.
• The preview never assumes an omitted checkbox entry is the string "false".

🔄requestSubmit, submit and reset

• RequestSubmit follows a submission workflow similar to activating a submit button: it participates in validation and dispatches submit when the workflow permits.
• Form.submit bypasses the submit event and constraint validation.
• They are not interchangeable helpers.

• Avoid naming a form control submit when the code needs form.submit, because named controls can mask that method.
• Use descriptive field names and keep the submission API clear.

• Form.reset restores controls to their default states rather than automatically making every field empty.
• It does not clear every custom error, application result or generated message; clear those parts deliberately.

form.requestSubmit(); // validation/submit workflow
// form.submit() has different behavior and bypasses that handler.

form.reset();
field.setCustomValidity("");
error.textContent = "";

• The lab’s reset returns to a blank name/email/session, one requested place and unchecked checkboxes.
• It clears inline validity messages, preview data and the attempt count, then focuses the name field.

♿Errors, Focus and Honest Outcomes

• Give each field error a nearby text message and connect it with aria-describedby.
• Set aria-invalid when the attempted entry is rejected.
• A concise status reports the attempt outcome while the detailed errors remain associated with their controls.

• Focus the first invalid field after submission.
• Keep all entered values so the learner can correct them.
• On successful local preview, keep the form usable rather than replacing it with a success screen that hides the controls.

• Client validation does not reserve a seat or prove that a server accepted a request.
• The lab reports a local accepted preview.
• A real network form would need loading, server validation, response handling and a deliberate policy for repeated attempts; those concerns follow in the asynchronous lesson.

🧪Premium Interactive — Event Path and Form Lab

• First choose a propagation mode and activate the nested link by clicking its text or using Enter.
• Inspect the observed target, currentTarget, phase and defaultPrevented values.
• The link points to a nearby marker in this lesson.
• Cancel navigation prevents that fragment action while propagation continues; stop propagation keeps the fragment action but stops the later ancestor listeners.

• Then use fictional values in the local workshop-request form.
• The handler cancels default submission, combines native validity with the stated task rules and previews FormData locally.
• No personal details are sent or saved by this lab.
• Corrected fields are rechecked on the next attempt.

[]

No accepted preview yet.

🛠️Debugging — Identify the Event and the Workflow

• If preventDefault appears to do nothing, check cancelable and passive status.
• If an ancestor handler is absent, inspect whether propagation was stopped earlier.
• If Enter misses validation, inspect whether only a click listener exists.
• If a corrected field stays invalid, check its custom validity message.

• If an optional checkbox is absent from FormData, inspect whether it is checked.
• If a numeric comparison treats a string unexpectedly, convert deliberately and validate the whole entry.
• If every click increments an attempt twice, look for two listeners processing the same submit.

• Repeat a small workflow: blank attempt, fill valid fields, request too many places, correct places, preview once, edit one field and reset.
• Keep the event log and form outcome separate so a link click is not mistaken for a form submission.

💬Interview Questions — Flip to Explain

❓MCQ Practice — Explain the Event and Form

💻Extra Practice — Test Specific Interactions

📌Quick Revision

📖Glossary — Flip to Learn

🏆Final Challenge — A Clear Local Request Workflow

• Build a labeled local workshop-request form with one submit handler.
• Keep native constraints in the HTML, explain any deliberate novalidate choice and enforce the selected session’s available places.
• Use nearby described errors, a concise status and a useful correction focus path.

• Clear custom errors before the next check.
• Read FormData only for an accepted preview, show its raw strings and normalize the numeric places explicitly.
• Treat an unchecked optional checkbox as omitted.
• Preserve the form and user entries so a rejected request can be corrected.

• Test blank values, malformed email, an unknown session, zero/fractional/too-many places, unchecked confirmation, accepted HTML 3, rejected JavaScript 3 and accepted JavaScript 2.
• Confirm one result per submit attempt and defaults after reset.
• Test native mouse and keyboard paths in a browser.

• Success criterion: explain target/currentTarget, propagation versus cancellation, native versus custom checks and the scope of the local result.
• Level 18 will introduce asynchronous JavaScript and API requests.