44 lines
2.3 KiB
Markdown
44 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.
|