A CSS Transition Was Cancelled. Which Completion Event Fired?

A transition can appear to “finish” from the application’s point of view while the browser reports a different lifecycle outcome. The false-positive pattern is simple: code changes a style, a later state looks correct, and an application-level callback or timeout declares success. None of those signals proves that the original CSS transition completed. A running transition can instead be canceled because its transitioning property was removed, the element stopped being rendered, the target changed while the transition was in flight, or another lifecycle boundary invalidated the original transition. CSS Transitions Level 1 distinguishes completion from cancellation, and MDN makes the operational consequence explicit: if transitioncancel fires for a transition, the corresponding transitionend does not.

This playbook treats transitionend versus transitioncancel on interrupted CSS transitions as a release-validation problem rather than a CSS tutorial. The test subject is one synthetic element, one transitioned property, deterministic programmatic inputs, an independent expected-case manifest, raw event capture, and state reconciliation. The primary success signal is not “the element ended up opaque.” It is whether the emitted lifecycle events match the declared contract and the final computed state matches the requested state.

The documented baseline is current as of November 10, 2026: CSS Transitions Level 1 is a W3C Working Draft dated October 8, 2026; the relevant MDN event pages were last modified October 26, 2026; and MDN’s transition property page was last modified September 10, 2026.

The release decision for the fixture published below is HOLD. The cases are specified and executable, but no browser-result matrix is represented here as observed. Every behavioral case remains EXPECTED / NOT EXECUTED until the fixture is run in the pinned runtimes and its evidence ledger is populated.

Define the operational acceptance contract

The acceptance contract must answer one narrow question: when a CSS transition that has already started is interrupted, did the original transition complete with transitionend, or was it terminated with transitioncancel?

That question is stricter than “did the final style become the requested value?” CSS Transitions Level 1 defines transitionend as the event that occurs when a transition completes. It separately defines transitioncancel for cancellation, including an elapsedTime representing time spent in the active portion before cancellation.

For this fixture, acceptance requires all of the following evidence:

The command interface is intentionally mundane:

npm ci
npx playwright install
npm test
cat artifacts/evidence.json

A green test command is not itself acceptance. The evidence artifact must show which event fired, for which property, under which synthetic input, and what state existed afterward.

The Kubernetes preStop and termination grace period playbook applies the same evidence discipline: distinguish the state you need to prove from an adjacent signal that merely looks successful. It examines how preStop consumes the termination budget using Pod lifecycle evidence.

Pin the documented baseline

The normative starting point is CSS Transitions Module Level 1, currently published as a Working Draft dated October 8, 2026. It says implementations maintain running transitions, move normally completed transitions into a completed set, and cancel running transitions under defined style-change conditions. It also states that when an element leaves the document, running transitions on that element must be canceled.

The event definitions matter more than informal descriptions. transitionrun occurs when a transition is created. transitionstart occurs when the delay phase ends. transitionend occurs on completion. transitioncancel occurs when a transition is canceled. For transitionend, elapsedTime equals the transition duration; for cancellation, elapsedTime reflects active time up to cancellation, excluding ordinary positive delay time.

MDN aligns with that model. Its transitionend page states that removing a transition before completion prevents the end event, and specifically notes that if transitioncancel fires, transitionend will not fire. Its transitioncancel page says cancellation can occur after transitionrun and before transitionend.

MDN’s transition reference also confirms that the shorthand controls transition-property, duration, timing function, delay, and behavior. Our fixture uses only opacity, a positive duration, zero delay, and a linear timing function so the lifecycle is not obscured by multiple properties or delay semantics.

A useful independent reference is Web Platform Tests. The current WPT cancellation tests explicitly assert that setting display:none while a transition is in progress should emit transitioncancel, and that removing the transitioning property from transition-property should emit transitioncancel rather than transitionend.

Pin exact runtime versions

The reproducibility matrix should be immutable for a release candidate. A suitable current pin is Node.js 26.13.0 LTS and Playwright 1.65.0. Playwright 1.65.0, released November 5, 2026, declares bundled Chromium 158.0.8127.18, Firefox 159.0, and WebKit 27.2. Node.js 26.13.0 became LTS on October 28, 2026.

Use an exact package declaration rather than a floating range:

{
  "name": "css-transition-lifecycle-fixture",
  "private": true,
  "version": "1.0.0",
  "engines": {
    "node": "26.13.0"
  },
  "scripts": {
    "test": "playwright test --reporter=line"
  },
  "devDependencies": {
    "@playwright/test": "1.65.0"
  }
}

The boundary case is version drift. If node --version, the Playwright package version, or the browser executable versions differ from the manifest, the result is RERUN, not ACCEPT. A behavior difference under a changed engine is versioned behavior until reconciled; it must not be quietly merged into the evidence from the pinned run.

Build an isolated reproducible fixture

The fixture should have one element, one transitioned longhand, no framework, no hover dependency, no animation library, and no application state machine. Synthetic class and style mutations are preferable to pointer movement because they reduce input timing variability.

<!doctype html>
<meta charset="utf-8">
<title>CSS transition lifecycle fixture</title>

<style>
  #target {
    opacity: 0;
    transition: opacity 400ms linear;
  }

  #target.on {
    opacity: 1;
  }
</style>

<div id="target">fixture</div>

Load ./fixture.js as a JavaScript module for this page.

The transition shorthand here means that only opacity is eligible, with a 400 ms duration and linear timing. MDN documents the shorthand mapping and the relevant constituent properties.

The fixture should also force a style boundary before triggering a transition. CSS Transitions Level 1 notes that implementations process style changes in “style change events” and warns that changes made very close together can be treated as simultaneous differently across implementations. Reading computed style, followed by a frame boundary, makes the intended before-state explicit rather than relying on an incidental paint.

export async function establishBeforeState(el) {
  el.className = "";
  el.style.cssText = "";
  void getComputedStyle(el).opacity;

  await new Promise(resolve =>
    requestAnimationFrame(() =>
      requestAnimationFrame(resolve)
    )
  );
}

That use of forced style is not intended as production advice. It is laboratory instrumentation.

The SQLite WAL backup validation playbook verifies that backups preserve committed rows using a synthetic database and restore checks, rather than trusting an artifact that merely opens successfully. The shared validation pattern is to separate an apparent success signal from the state that actually matters.

Write the independent expected-case manifest

Expected results must exist before the browser run. Otherwise, observed behavior can quietly become the definition of success.

[
  {
    "id": "C1",
    "input": "allow opacity transition to complete",
    "expectedTerminalEvent": "transitionend",
    "expectedFinalOpacity": "1",
    "status": "EXPECTED / NOT EXECUTED"
  },
  {
    "id": "C2",
    "input": "set transition-property:none while active",
    "expectedTerminalEvent": "transitioncancel",
    "expectedFinalOpacity": "1",
    "status": "EXPECTED / NOT EXECUTED"
  },
  {
    "id": "C3",
    "input": "set display:none while active",
    "expectedTerminalEvent": "transitioncancel",
    "expectedFinalDisplay": "none",
    "status": "EXPECTED / NOT EXECUTED"
  },
  {
    "id": "C4",
    "input": "reverse opacity target while active",
    "expectedOldTransitionTerminalEvent": "transitioncancel",
    "expectedReplacementTransition": true,
    "expectedFinalOpacity": "0",
    "status": "EXPECTED / NOT EXECUTED"
  },
  {
    "id": "C5",
    "input": "remove element while active",
    "expectedTerminalClassification": "canceled",
    "expectedConnected": false,
    "status": "EXPECTED / NOT EXECUTED"
  },
  {
    "id": "N1",
    "input": "opacity change with transition-duration:0s",
    "expectedEvents": [],
    "expectedFinalOpacity": "1",
    "status": "EXPECTED / NOT EXECUTED"
  }
]

C2 is directly backed by the WPT test that removes the transitioning property and treats transitionend as unreachable. C3 is backed by the WPT display:none cancellation test.

C4 requires more care. CSS Transitions Level 1 has explicit rules for changing the target while a transition is running. When the new target differs from the current running transition’s end value, the existing transition can be canceled and a new one started; when the new target is the logical reversing-adjusted start value, the replacement uses a reversing-shortening factor so the reverse leg may be shorter.

Preserve a negative control

N1 protects the test harness itself. MDN states that if transition duration and delay are both zero, no transition occurs and transition lifecycle events do not fire.

The negative control is therefore:

#target {
  opacity: 0;
  transition: opacity 0s linear;
}

The synthetic input sets opacity:1. The expected state is opacity === "1" and the expected lifecycle-event list is empty.

Reject the run if N1 emits transitionrun, transitionstart, transitionend, or transitioncancel. That failure means the test harness, event filtering, reused DOM state, or browser setup cannot be trusted. Do not reinterpret the other cases until the negative control is repaired and the entire matrix is rerun.

Reproduce the misleading success

The failure mode to reproduce is not a browser bug. It is an application observer that equates final-looking state with successful transition completion.

Consider this unsafe code:

function fadeIn(el) {
  el.classList.add("on");

  setTimeout(() => {
    if (getComputedStyle(el).opacity === "1") {
      reportSuccess("fade completed");
    }
  }, 500);
}

Now interrupt the transition after 100 ms:

setTimeout(() => {
  el.style.transitionProperty = "none";
}, 100);

The computed final opacity can still become 1 because removing the transition changes how the target style is applied. Yet the original running transition has not thereby completed. CSS Transitions Level 1 specifically says that when the matching transition-property disappears, the running transition is canceled; the WPT cancellation test encodes the same rule.

That is the false-positive signal: opacity === "1" is useful state evidence, but it is not completion-event evidence.

The inverse mistake is also possible:

el.addEventListener("transitionend", () => {
  done = true;
});

If cancellation is a valid operational path, listening only for transitionend can leave done unresolved. MDN explicitly distinguishes the two terminal events and says an emitted transitioncancel excludes the corresponding transitionend.

The repair is not to prefer one signal universally. It is to model two terminal outcomes and reconcile them with application state.

Run the controlled comparison

The harness records all four lifecycle events and keeps terminal classification separate from final style:

export function instrument(el) {
  const events = [];

  for (const type of [
    "transitionrun",
    "transitionstart",
    "transitionend",
    "transitioncancel"
  ]) {
    el.addEventListener(type, event => {
      if (event.propertyName !== "opacity") return;

      events.push({
        type: event.type,
        propertyName: event.propertyName,
        elapsedTime: event.elapsedTime,
        pseudoElement: event.pseudoElement,
        timestamp: performance.now()
      });
    });
  }

  return events;
}

Then define one function per synthetic input:

export const cases = {
  C1: async el => {
    el.classList.add("on");
  },

  C2: async el => {
    el.classList.add("on");
    await delay(100);
    el.style.transitionProperty = "none";
  },

  C3: async el => {
    el.classList.add("on");
    await delay(100);
    el.style.display = "none";
  },

  C4: async el => {
    el.classList.add("on");
    await delay(100);
    el.classList.remove("on");
  },

  C5: async el => {
    el.classList.add("on");
    await delay(100);
    el.remove();
  }
};

Do not assert exact wall-clock timestamps. Browser frame scheduling and timer wake-up are not the contract under test. Assert terminal-event identity, property identity, event exclusivity, and state.

The Java periodic-task exception playbook uses ScheduledExecutorService and ScheduledFuture to distinguish the terminal state of one scheduled task from the liveness of its executor. A periodic task can terminate exceptionally while its executor remains alive.

Assert the failure boundary

A compact assertion helper should reject ambiguous lifecycle evidence:

function terminalEvents(events) {
  return events.filter(
    e => e.type === "transitionend" ||
         e.type === "transitioncancel"
  );
}

function assertOneTerminal(events, expected) {
  const terminal = terminalEvents(events);

  if (terminal.length !== 1) {
    throw new Error(
      expected exactly one terminal event; got ${JSON.stringify(terminal)}
    );
  }

  if (terminal[0].type !== expected) {
    throw new Error(
      expected ${expected}; got ${terminal[0].type}
    );
  }
}

For a single uninterrupted transition, this encodes the lifecycle invariant we care about: one terminal classification, not both.

For reversal C4, do not reuse this helper across the entire case because the case may contain two transition objects: cancellation of the first and lifecycle events for its replacement. Instead partition event sequences by transition generation where the runtime exposes sufficient identity, or by controlled phase boundaries in a minimal fixture. CSS Transitions Level 2 makes this distinction explicit by describing interrupted playback as a run/start/cancel sequence and by defining event ordering for transition generations.

Test failure and boundary cases

C1 proves the ordinary path. Without it, a harness that never receives transitionend could falsely “pass” every cancellation case.

C2 removes the matching transitioning property. CSS Transitions Level 1 requires cancellation when a property has a running transition but no matching transition-property remains. WPT has a direct test for this exact condition.

C3 sets display:none while the opacity transition is active. MDN uses display:none as an example of removal before completion, and the current WPT fixture explicitly asserts that hiding a transitioning element this way emits transitioncancel.

C4 reverses the target before completion. This boundary is operationally important because “interrupted” does not always mean “animation stops and nothing replaces it.” The Level 1 algorithm can cancel the old running transition and start a new reversed transition with a shortening factor.

C5 removes the element from the document. Level 1 states that if an element is no longer in the document, implementations must cancel its running transitions.

N1 verifies that the fixture does not manufacture events when no transition exists.

Add a timeout failure row too:

await Promise.race([
  runCase(),
  delay(3000).then(() => {
    throw new Error("evidence timeout");
  })
]);

A timeout is not proof that neither event exists. It is missing evidence and therefore HOLD or RERUN.

Capture raw evidence

A useful evidence ledger records source facts, runtime identity, input, events, and final state in one machine-readable artifact.

async function collectEvidence(id, action) {
  const el = freshTarget();
  await establishBeforeState(el);

  const events = instrument(el);

  const before = {
    connected: el.isConnected,
    opacity: getComputedStyle(el).opacity,
    display: getComputedStyle(el).display,
    transitionProperty:
      getComputedStyle(el).transitionProperty,
    transitionDuration:
      getComputedStyle(el).transitionDuration
  };

  const startedAt = performance.now();
  await action(el);
  await delay(900);

  const after = el.isConnected
    ? {
        connected: true,
        opacity: getComputedStyle(el).opacity,
        display: getComputedStyle(el).display,
        transitionProperty:
          getComputedStyle(el).transitionProperty
      }
    : { connected: false };

  return {
    id,
    startedAt,
    before,
    events,
    after,
    userAgent: navigator.userAgent
  };
}

The ledger should retain elapsedTime because it helps distinguish a genuine interrupted lifecycle from a synthetic application message. The specification defines elapsedTime on TransitionEvent, including different semantics for normal completion and cancellation.

An evidence ledger should look like this before execution:

No row above is an observed browser outcome.

Detect missing evidence

Treat missing evidence as a first-class failure mode.

The rejection criterion is simple: if the manifest expects a terminal lifecycle classification and the log contains neither a qualifying terminal event nor enough lower-level evidence to explain why the case did not start, the row is HOLD, not PASS.

For example, this is insufficient:

{
  "id": "C2",
  "after": {
    "opacity": "1"
  }
}

It proves a state, not a lifecycle.

This is also insufficient:

{
  "id": "C2",
  "events": [
    { "type": "transitioncancel", "propertyName": "width" }
  ]
}

It proves cancellation of a different property.

Capture transitionrun and transitionstart because they establish whether the transition being evaluated existed before the interrupt. CSS Transitions Level 1 assigns those events distinct lifecycle meanings, and Level 2’s event-dispatch model describes the normal interrupted sequence as run, start, cancel.

If a cancellation case has no preceding run for opacity, diagnose fixture setup before diagnosing browser behavior.

Reconcile the actual state

Event evidence and state evidence answer different questions.

For C2, the expected lifecycle result is cancellation of the original transition. The expected state result is opacity 1, because the class still requests the target opacity after transition eligibility has been removed. Those outcomes are not contradictory: “transition canceled” describes the transition object’s lifecycle; opacity 1 describes the resulting style.

For C3, the expected lifecycle is cancellation and the independent state is display:none. Again, the hidden element’s final state does not prove transition completion. The WPT case exists precisely to establish cancellation when the element is hidden during its transition.

For C4, reconcile three things: the first transition’s terminal event, the replacement transition’s lifecycle, and final opacity 0. CSS Transitions Level 1’s reversing rules make this multi-object interpretation necessary.

A reconciliation function should therefore avoid a one-bit “success” result:

function reconcile(actual, expected) {
  return {
    lifecycleMatches:
      classifyLifecycle(actual.events) ===
      expected.expectedLifecycle,

    stateMatches:
      compareState(actual.after, expected),

    evidenceComplete:
      hasRequiredEvidence(actual, expected)
  };
}

Acceptance requires all three booleans.

The pandas GroupBy missing-key reconciliation playbook compares an output aggregate with the source-row population rather than trusting a plausible total. The relevant connection is reconciliation against an independently declared population or state.

Separate documented from observed behavior

Every result in the final report should carry a provenance class.

DOCUMENTED means the claim comes from the specification or another primary reference. Examples include: transitionend represents completion; transitioncancel represents cancellation; losing a matching transition-property can cancel a running transition; and removing an element from the document cancels its running transitions.

REFERENCE TEST means an interoperable web-platform test expresses the expected behavior. C2 and C3 fall into that category because WPT contains direct tests for transition-property removal and display:none.

EXPECTED means this playbook’s independent manifest predicts a result from the documented baseline.

OBSERVED may be used only after a named runtime actually produces an evidence artifact.

INFERENCE means a conclusion combines evidence. For example, “the application’s completion flag is a false positive” is an inference if the original transition emitted transitioncancel while final opacity nevertheless reached 1.

That vocabulary prevents an expected result from becoming folklore by being written in the past tense.

The current article therefore records no browser case as OBSERVED. The exact Playwright and Node versions are verified release facts, but the fixture behavior remains EXPECTED / NOT EXECUTED. Playwright 1.65.0’s published browser bundle is Chromium 158.0.8127.18, Firefox 159.0, and WebKit 27.2.

Measure the repair boundary

A repair is acceptable only if it changes the application’s lifecycle interpretation without changing unrelated transition behavior.

Before repair:

el.addEventListener("transitionend", finish);

After repair:

el.addEventListener("transitionend", event => {
  settle("completed", event);
});

el.addEventListener("transitioncancel", event => {
  settle("canceled", event);
});

The boundary is narrow: C1 should still classify as completed; C2 and C3 should classify as canceled; N1 should still produce no transition lifecycle event.

Reject the repair if it converts cancellation into generic success:

const finish = () => resolve("done");
el.addEventListener("transitionend", finish);
el.addEventListener("transitioncancel", finish);

That code prevents a hang, but it erases the semantic difference this playbook is designed to preserve.

Apply the smallest safe repair

A safe application abstraction gives callers a terminal classification and verifies final state separately.

export function awaitOpacityTransition(el) {
  return new Promise(resolve => {
    const onEnd = event => {
      if (event.propertyName !== "opacity") return;
      cleanup();
      resolve({
        lifecycle: "completed",
        event
      });
    };

    const onCancel = event => {
      if (event.propertyName !== "opacity") return;
      cleanup();
      resolve({
        lifecycle: "canceled",
        event
      });
    };

    const cleanup = () => {
      el.removeEventListener("transitionend", onEnd);
      el.removeEventListener("transitioncancel", onCancel);
    };

    el.addEventListener("transitionend", onEnd);
    el.addEventListener("transitioncancel", onCancel);
  });
}

The caller then performs state reconciliation:

const outcome = await awaitOpacityTransition(el);

const state = {
  connected: el.isConnected,
  opacity: el.isConnected
    ? getComputedStyle(el).opacity
    : null
};

if (
  outcome.lifecycle === "completed" &&
  state.opacity === "1"
) {
  acceptVisualCompletion();
} else if (
  outcome.lifecycle === "canceled" &&
  state.opacity === "1"
) {
  handleInterruptedButAppliedState();
} else {
  holdForDiagnosis({ outcome, state });
}

Do not make transitionend a business-critical single point of progress if the interface must work when transitions are disabled. The Level 1 accessibility considerations explicitly note that user agents may alter or disable motion and caution against depending on transition events for functional correctness.

That is a design limitation, not an excuse to conflate end and cancel. Where lifecycle identity matters, preserve it.

Test rollback and rerun safety

Rollback means restoring the old event interpretation without corrupting fixture state. Because this repair changes event handling rather than persistent data, rollback is mechanically simple but still needs evidence.

Keep the fixture immutable and version it separately from application code. The rerun sequence should recreate every target element, re-establish the before-state, clear listeners, execute exactly one synthetic case, and write a new evidence row. Reusing an element across cases risks retaining inline styles such as transition-property:none or display:none.

A CI wrapper can enforce the pin:

import { test, expect } from "@playwright/test";
import fs from "node:fs";

test("record runtime identity", async ({ browserName, page }) => {
  const ua = await page.evaluate(() => navigator.userAgent);

  const record = {
    node: process.version,
    playwright: "1.65.0",
    browserName,
    userAgent: ua
  };

  fs.mkdirSync("artifacts", { recursive: true });
  fs.writeFileSync(
    artifacts/runtime-${browserName}.json,
    JSON.stringify(record, null, 2)
  );

  expect(process.version).toBe("v26.13.0");
});

The Ansible check-mode task coverage playbook treats unexecuted validation as an evidence gap rather than interpreting a green summary as proof.

Rollback evidence consists of the previous handler version, the new handler version, the runtime manifest, and both run IDs. Do not merge evidence across runs after changing fixture code.

Assign operational ownership

The browser-platform owner owns the expected lifecycle interpretation against the CSS specification. The application owner owns whether cancellation is acceptable for the component’s business behavior. The release operator owns runtime pinning, artifact retention, and the final gate.

A boundary case belongs to the platform owner when the browser emits a sequence that contradicts the documented lifecycle under a valid fixture. It belongs to the fixture owner when transitionrun never occurred because the before-state was not established. It belongs to the application owner when browser behavior is valid but application code treats cancellation as completion.

The rejection criterion is unresolved ownership. An unexplained mismatch cannot be accepted simply because the rendered page “looks right.”

For cross-browser disagreement, preserve each browser’s raw evidence separately and classify the release HOLD until the mismatch is reconciled against the specification, WPT coverage, and known implementation behavior. The spec itself is still a draft, and Level 1 notes that timing of style-change events can expose implementation differences when changes are made very close together.

Make the release decision

The gate has four outcomes.

For this fixture, the decision is HOLD because C1–C5 and N1 are EXPECTED / NOT EXECUTED. That is not a behavioral failure. It is an evidence-state decision: the documented baseline and executable fixture exist, but acceptance requires actual browser artifacts.

The expected release path is:

1. Execute the unchanged fixture under Node 26.13.0 and Playwright 1.65.0 using Chromium 158.0.8127.18, Firefox 159.0, and WebKit 27.2.

2. Preserve one JSON evidence file per browser.

3. Reconcile each row against the independent manifest.

4. Verify N1 before trusting positive cases.

5. ACCEPT only if lifecycle and independent final state agree with the declared contract.

Connect the practice to Refonte Learning

The Refonte Learning Frontend Development program describes a curriculum centered on HTML, CSS, JavaScript, responsive interfaces, React, Redux, API/AJAX work, Git, accessibility, and performance optimization. It lists a 4-month period, 10–12 hours/week dedication, a requirement of basic programming understanding with HTML/CSS familiarity described as a plus, and “Potential Internship” among its program characteristics.

These topics are relevant to this playbook because the exercise connects CSS behavior with engineering validation: reading a platform contract, isolating a reproducible fixture, pinning runtime versions, distinguishing expected from observed behavior, preserving negative controls, and deciding whether evidence is sufficient for release.

Engineers who want structured frontend study covering HTML, CSS, JavaScript, React, version control, accessibility, and performance can review the Refonte Learning Frontend Development program.