Start SVG morph animation with a bounded coordinate contract. Match the endpoint structure, pair the points deliberately, and inspect an intermediate path before adding a clock. This original four-point example gives you exact endpoints, a midpoint trace, rejection cases, and a local interface for inspecting them.
The local HTML example pairs original SVG geometry with an acceptance ledger. It does not establish commercial-plugin behavior or native project results.
Keep the first example small enough to inspect
Use only the explicit uppercase sequence M L L L Z, with four coordinate pairs in a fixed order. There is one starting point and three subsequent vertices, then closure. Do not import arbitrary path markup or claim to parse every valid SVG path.
The original endpoints are:
A
M20 20 L80 20 L80 80 L20 80 Z
B
M30 10 L90 30 L70 90 L10 70 Z
Record the coordinate pairs separately:
| Point ID | A | B |
|---|---|---|
| P1 | (20, 20) | (30, 10) |
| P2 | (80, 20) | (90, 30) |
| P3 | (80, 80) | (70, 90) |
| P4 | (20, 80) | (10, 70) |
P1 corresponds to P1, P2 to P2, and so on. That correspondence is authored, not automatically inferred from proximity or appearance. Reordering an endpoint's vertices changes the task even if its final outline looks similar.
The W3C SVG 2 path specification requires matching command count, types, and order for smooth path-data interpolation and describes separate interpolation of compatible parameters. It also describes discrete behavior for structurally different command lists. This is a specification reference, not proof of current browser support. SVG 2 path-data animation rules.
Interpolate each coordinate from the original endpoints
For each x or y coordinate, use:
current = a + (b − a) × t, with 0 ≤ t ≤ 1.
Here a and b are the original endpoint coordinates. Do not use the last rendered coordinate as the new starting value each frame; that would change the calculation from the declared interpolation.
At t = 0, each coordinate is a. At t = 1, each is b. At t = 0.5, each lies halfway between its paired endpoint values.
For P1:
x = 20 + (30 − 20) × 0.5 = 25.
y = 20 + (10 − 20) × 0.5 = 15.
Review all four:
| Point | Midpoint x | Midpoint y |
|---|---|---|
| P1 | 25 | 15 |
| P2 | 85 | 25 |
| P3 | 75 | 85 |
| P4 | 15 | 75 |
The exact midpoint path is:
M25 15 L85 25 L75 85 L15 75 Z
This is the useful acceptance anchor. A smooth-looking preview with different coordinates has not followed this fixture.
Keep raw coordinates distinct from display formatting. For the authored 0, 0.5 and 1 checks, use the exact endpoint/midpoint values. Other slider positions may produce decimals; record how the later tool displays them without feeding rounded readout values back into the calculation.
Reject incompatible inputs before accepting a preview
The proposed helper accepts two finite four-point arrays and the fixed M L L L Z structure. It does not normalize alternate commands, infer missing points, rotate vertex order, or convert curves into lines.
For a negative case, replace a line segment in B with a valid quadratic-curve segment. For example:
M30 10 Q60 0 90 30 L70 90 L10 70 Z
That path can be SVG material, but it is outside this helper's line-only contract and does not have the required command-type match. Hold smooth-preview eligibility. Do not say a browser must reject the entire SVG.
For another negative case, use only three points:
M30 10 L90 30 L70 90 Z
The point and command counts differ. Do not invent a fourth point or silently reuse one.
An unsupported structure, nonfinite coordinate, unknown point record, or invalid t clears accepted output and stops any playback. Keep the issue visible. A previous valid midpoint must not remain labeled as the current result of invalid inputs.
Review the geometry and readout together in NOS
After a local HTML reading copy has been prepared, NOS can save and render it beside the native point and command ledger. Put endpoints A/B, the t = 0.5 current path, and its d readout together so a reviewer can compare the geometry with the numbers.
Keep native SVG/point records and actual tests authoritative. A saved/rendered page does not prove that sliders, interpolation, playback, or reduced-motion behavior execute correctly in the host. Those observations remain pending.
The geometry view labels A, B, and Current. Use distinct line treatment as well as labels rather than depending only on color. Display point IDs so the pairing is inspectable. A proposed 0 0 100 100 viewBox fits the authored endpoint and midpoint coordinates; it is a fixture choice, not a guarantee for other inputs.
A compatible command list alone does not guarantee that arbitrary intermediate shapes avoid self-intersection or preserve an intended topology. The packet checks this original coordinate correspondence, not a universal shape-quality condition.
Make manual inspection the primary interaction
The local example starts paused at t = 0, showing A. A labeled slider would select a finite t within the accepted interval. Buttons for 0, 0.5, and 1 would select the same state as the slider. All geometry and readouts would derive from that one current t.
Manual scrubbing or an endpoint button would stop playback before changing t. Reset would stop the clock, restore original A/B, and select t = 0. It would clear current validation messages and restore the eligible original fixture.
Playback is optional. If added, use one clock, no autoplay, explicit Play/Pause controls, and a declared duration. For this proposed design, t increases at 0.5 per active second: a complete A-to-B pass lasts two seconds and stops at B. Play resumes a paused intermediate t at that same rate; at B, a new user-started pass begins at A.
Repeated Play must not create multiple loops. Pause freezes t. Hidden-page suspension should pause and require manual resumption rather than replay an undisclosed jump. Old callbacks must not overwrite a scrubbed, reset, or invalid state.
With reduced motion requested, keep manual selection available and disable automatic playback for this design. A preference change during playback should stop the clock and leave the current manual state visible. These are authored interface requirements; actual timing and accessibility behavior have not been tested.
Preserve expected cases beside actual observations
| Case | Input/action | Expected result | Actual observation |
|---|---|---|---|
| M1 | Original pair, t = 0 | Exact A | |
| M2 | Original pair, t = 0.5 | M25 15 L85 25 L75 85 L15 75 Z | |
| M3 | Original pair, t = 1 | Exact B | |
| M4 | B includes Q | Ineligible for this smooth helper | |
| M5 | B has three points | Ineligible; no invented fourth point | |
| M6 | Scrub during Play | Clock stopped; selected t controls output | |
| M7 | Invalid endpoint during Play | Clock stopped; accepted output cleared | |
| M8 | Reduced motion | Manual selection only |
Record actual observations only after testing the relevant browser and host. Record source/point revisions, browser/host, rendering, keyboard/focus behavior, narrow layout, and any timing observation. Changed inputs or code retire old acceptance for that changed setup.
Copy this prompt for the morph packet
Prepare an original English SVG morph authoring packet.
Do not create SVG/HTML/code files, run an animation, import icons,
use plugins, capture screens, or publish.
Bounded structure: explicit uppercase M L L L Z only, four finite point
pairs, fixed matching order. No arbitrary path parser or markup insertion.
A = M20 20 L80 20 L80 80 L20 80 Z.
B = M30 10 L90 30 L70 90 L10 70 Z.
Pair P1 with P1, P2 with P2, P3 with P3, P4 with P4.
No auto alignment, reordering, curve conversion or inferred points.
For each original endpoint coordinate:
current = a + (b - a) * t, finite 0 <= t <= 1.
t = 0 -> exact A.
t = 1 -> exact B.
t = 0.5 -> points (25,15), (85,25), (75,85), (15,75).
Midpoint d = M25 15 L85 25 L75 85 L15 75 Z.
Use original endpoints, not previous frame geometry.
Keep raw calculation and display rounding separate.
Negative cases:
B with Q: M30 10 Q60 0 90 30 L70 90 L10 70 Z.
B with three points: M30 10 L90 30 L70 90 Z.
Reject eligibility for this bounded smooth helper before accepting output.
Do not say these paths must be rejected as entire SVGs by every browser.
Invalid endpoints, t or coordinates stop playback and clear stale output.
No universal topology, browser-support or normalization guarantee.
Proposed interface, not built:
Labeled A/B/current geometry, point IDs and d readout.
Original viewBox 0 0 100 100 as a fixture choice.
Paused initial t = 0. Slider and 0/0.5/1 buttons share one state.
Manual selection stops playback. Reset stops playback, restores A/B,
t = 0, original eligibility and cleared messages.
Optional Play/Pause: no autoplay, one clock, t rises 0.5 per active second;
a complete A-to-B single pass takes two seconds.
Pause freezes t; Play resumes intermediate state, or starts A if at B.
Repeated Play cannot add loops; stale callbacks cannot overwrite edits.
Hidden-page suspension pauses and needs manual resume.
Reduced motion: manual-only; changing preference stops playback.
Deliver point/command ledger, midpoint arithmetic, expected-case matrix,
blank actual observations and native source revision record.
Plan keyboard/focus, geometry/readout parity, invalid states, clock,
reduced-motion, browser/host, article-width and narrow layout checks.
Actual example, visual comparison and runtime outcomes remain pending.
Integrate NOS into body review: it can save/render prepared HTML beside
the native geometry ledger. Limit product claim to that reading view.
No promised slider/playback execution, saved state or host compatibility.
End with a CTA for the prepared comparison copy.
Explore NOS with the prepared HTML geometry review. Let the four midpoint coordinates explain the transition before a clock makes it move.