tegwick
642163a1ed
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
43 lines
2.3 KiB
Markdown
43 lines
2.3 KiB
Markdown
---
|
||
title: Progressive Enhancement
|
||
status: draft
|
||
maturity: hypothesis
|
||
families: [quality, execution, affordance]
|
||
scales: [L3, L6]
|
||
admission: research-candidate-only
|
||
---
|
||
|
||
# Progressive Enhancement
|
||
|
||
Context: essential reading/navigation or submission should work before optional
|
||
scripts arrive. Problem: delayed or failed client execution can block a usable
|
||
server-delivered interface. Resilience competes with interaction richness and the
|
||
cost of maintaining equivalent behavior across paths.
|
||
|
||
Proposed solution: give the essential task a usable HTML/link/form contract first;
|
||
add client behavior that preserves its meaning and authoritative validation.
|
||
Define which controls are essential and what enhanced behavior adds. Test absent,
|
||
late and partially failing scripts separately. Server-rendered text alone does not
|
||
establish a functional no-script task.
|
||
|
||
For enhanced navigation, preserve route, history, loading/error feedback and focus
|
||
semantics. For writes, avoid duplicate submission when falling back after an
|
||
uncertain response: reconcile the original operation before resubmitting it.
|
||
Keyboard operation, labels, status announcements and recovery focus need explicit
|
||
verification in both paths. Native elements help but are not an accessibility proof.
|
||
|
||
Consequences: initial tasks depend on fewer client capabilities, while parity and
|
||
failure recovery add design work. No-script support is not offline support. A
|
||
client-only rich editor may deliberately require scripts; name that requirement
|
||
instead of promising a fallback that cannot perform the task.
|
||
|
||
Evidence: [navigation review](../reviews/NavigationRenderingEvidence.md) N03–N05
|
||
locates htmx and SvelteKit mechanisms with specific link/form/action prerequisites.
|
||
These are two documentation families, not two verified deployments of this complete
|
||
contract. Full-pattern recurrence and decision benefit remain unknown. This develops
|
||
an existing seed; hypothesis only, no canonical identity or admitted relations.
|
||
|
||
Proposed connections: [URL-addressable State](URLAddressableState.md) supports shared
|
||
view selection; [Mutation Outcome Tracking](MutationOutcomeTracking.md) matters when
|
||
an enhanced write becomes uncertain. Neither is a universal dependency.
|
||
[VC-03](../walkthroughs/VC03-ContentPublication.md) explores a read-only core.
|