stylegallery 0.1.11 → 0.1.13
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/AGENTS.md +2 -2
- package/DOMAINS.md +1 -1
- package/GOVERNANCE.md +2 -2
- package/README.md +67 -35
- package/consumer-reference/agent-native/README.md +5 -5
- package/consumer-reference/agent-native/v2/admission-policy.json +66 -1
- package/consumer-reference/agent-native/v2/material-registry.json +1 -1
- package/consumer-reference/agent-native/v2/schema/admission-policy.schema.json +2 -2
- package/design-engineering/evidence-patterns/autocomplete.md +83 -0
- package/design-engineering/evidence-patterns/bottom-navigation.md +78 -0
- package/design-engineering/evidence-patterns/breadcrumbs.md +78 -0
- package/design-engineering/evidence-patterns/dark-mode-contrast.md +83 -0
- package/design-engineering/evidence-patterns/data-tables.md +86 -0
- package/design-engineering/evidence-patterns/empty-states.md +80 -0
- package/design-engineering/evidence-patterns/error-recovery.md +84 -0
- package/design-engineering/evidence-patterns/faceted-filters.md +90 -0
- package/design-engineering/evidence-patterns/form-labels.md +82 -0
- package/design-engineering/evidence-patterns/index.md +69 -0
- package/design-engineering/evidence-patterns/inline-validation.md +94 -0
- package/design-engineering/evidence-patterns/input-masks.md +79 -0
- package/design-engineering/evidence-patterns/tabs-and-segmented-controls.md +81 -0
- package/design-engineering/index.md +17 -0
- package/design-engineering/loading-and-feedback.md +29 -1
- package/design-engineering/native-interaction-contracts.md +10 -0
- package/design-engineering/state-management/patterns/latest-request-wins.md +2 -0
- package/design-engineering/state-management/patterns/optimistic-overlay.md +1 -0
- package/design-engineering/state-management/patterns/single-flight.md +2 -0
- package/design-engineering/state-management/patterns/unsaved-navigation.md +2 -0
- package/design-engineering/state-management/patterns/url-state.md +1 -0
- package/design-engineering/state-management/recipes/delete-undo.md +7 -0
- package/design-engineering/text-input-and-internationalization.md +1 -0
- package/expression/directions/nocturne-editorial.md +1 -0
- package/expression/directions/warm-print.md +1 -0
- package/expression/techniques/gradient-atmosphere.md +1 -0
- package/expression/techniques/grain-and-texture.md +1 -0
- package/expression/techniques/webgl-hero.md +1 -0
- package/guides/decision-tree.md +2 -0
- package/guides/webpage-generation-workflow.md +2 -0
- package/log.md +22 -0
- package/motion/accessible-motion.md +2 -0
- package/motion/interruption-and-retargeting.md +2 -0
- package/motion/rendering-and-performance.md +1 -0
- package/motion/techniques/kinetic-type.md +1 -0
- package/motion/techniques/scroll-choreography.md +2 -0
- package/package.json +27 -8
- package/patterns/centering/center.md +1 -0
- package/patterns/centering/super-center.md +2 -0
- package/patterns/containment/box.md +1 -0
- package/patterns/containment/clamped-card.md +1 -0
- package/patterns/containment/content-limiter.md +2 -0
- package/patterns/containment/fluid-styles.md +1 -0
- package/patterns/grid-repetition/card-grid.md +2 -0
- package/patterns/grid-repetition/columns.md +1 -0
- package/patterns/grid-repetition/dense-grid.md +1 -0
- package/patterns/grid-repetition/grid-wrapper.md +1 -0
- package/patterns/grid-repetition/masonry-approx.md +1 -0
- package/patterns/grid-repetition/page-grid.md +1 -0
- package/patterns/grid-repetition/ram-grid.md +2 -0
- package/patterns/grid-repetition/twelve-span-grid.md +1 -0
- package/patterns/in-line-grouping/badge-list.md +1 -0
- package/patterns/in-line-grouping/breadcrumb.md +1 -0
- package/patterns/in-line-grouping/cluster.md +1 -0
- package/patterns/in-line-grouping/deconstructed-pancake.md +1 -0
- package/patterns/in-line-grouping/pagination.md +1 -0
- package/patterns/in-line-grouping/reel.md +2 -0
- package/patterns/in-line-grouping/split-nav.md +1 -0
- package/patterns/in-line-grouping/tab-strip.md +1 -0
- package/patterns/in-line-grouping/wrap-row.md +1 -0
- package/patterns/media-fit/frame.md +2 -0
- package/patterns/media-fit/icon-frame.md +1 -0
- package/patterns/overlay-exception/imposter.md +1 -0
- package/patterns/overlay-exception/overlay-stack.md +1 -0
- package/patterns/split-sidebar/list-detail.md +1 -0
- package/patterns/split-sidebar/main-with-rail.md +1 -0
- package/patterns/split-sidebar/media-object.md +1 -0
- package/patterns/split-sidebar/sidebar.md +2 -0
- package/patterns/split-sidebar/split-screen.md +1 -0
- package/patterns/split-sidebar/sticky-aside.md +2 -0
- package/patterns/split-sidebar/supporting-pane.md +1 -0
- package/patterns/split-sidebar/switcher.md +2 -0
- package/patterns/stacking/feed.md +1 -0
- package/patterns/stacking/line-up.md +2 -0
- package/patterns/stacking/stack.md +1 -0
- package/patterns/stacking/step-nav.md +1 -0
- package/patterns/viewport-shell/cover.md +1 -0
- package/patterns/viewport-shell/fixed-sidenav-shell.md +2 -0
- package/patterns/viewport-shell/holy-grail.md +2 -0
- package/patterns/viewport-shell/panel-layout.md +1 -0
- package/patterns/viewport-shell/scroll-body-shell.md +2 -0
- package/patterns/viewport-shell/sticky-footer.md +2 -0
- package/patterns/viewport-shell/sticky-header.md +2 -0
- package/platform-guides/input-and-focus.md +10 -0
- package/platform-guides/preferences-and-accessibility.md +1 -0
- package/recipes/article-page.md +1 -0
- package/recipes/command-surface.md +1 -0
- package/recipes/dashboard.md +1 -0
- package/recipes/form-flow.md +1 -0
- package/recipes/homepage.md +2 -0
- package/recipes/list-detail.md +1 -0
- package/recipes/saas-settings.md +1 -0
- package/scripts/agent-native/v2/material-cli-adapter.mjs +7 -5
- package/scripts/agent-native/v2/material-queries.mjs +21 -0
- package/scripts/agent-native/v2/material-search-v3.mjs +409 -0
- package/scripts/compiler/README.md +16 -16
- package/scripts/compiler/mcp.mjs +38 -2
- package/scripts/legacy-sg-material-mcp.mjs +9 -0
- package/scripts/legacy-sg-material.mjs +4 -0
- package/scripts/pattern-data.mjs +409 -0
- package/scripts/sg-entry.mjs +2 -2
- package/scripts/sg-material-mcp.mjs +1 -1
- package/scripts/stylegallery-cli.mjs +130 -0
- package/skills/stylegallery-search/SKILL.md +34 -0
|
@@ -0,0 +1,90 @@
|
|
|
1
|
+
---
|
|
2
|
+
type: Domain Guide
|
|
3
|
+
title: Faceted Filter Selection
|
|
4
|
+
description: Make applied filters visible and removable while matching selection logic to the user's search task.
|
|
5
|
+
aliases: ["faceted filters","applied filters","filter chips","OR filter values"]
|
|
6
|
+
questions: ["How should multiple filter values combine and remain visible?"]
|
|
7
|
+
domain: design-engineering
|
|
8
|
+
lifecycle: experimental
|
|
9
|
+
provenance_kind: local
|
|
10
|
+
reviewed_on: 2026-10-19
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
# Faceted Filter Selection
|
|
14
|
+
|
|
15
|
+
Primary role: filter selection and recovery guide.
|
|
16
|
+
|
|
17
|
+
## Repository Boundary
|
|
18
|
+
|
|
19
|
+
This page owns filter meaning and visibility. [URL State](../state-management/patterns/url-state.md) owns serialization/history; [Latest Request Wins](../state-management/patterns/latest-request-wins.md) owns response authority. Layout owns sidebar and wrapping mechanics.
|
|
20
|
+
|
|
21
|
+
## Reusable Method
|
|
22
|
+
|
|
23
|
+
### Problem And Use
|
|
24
|
+
|
|
25
|
+
Users forget hidden constraints and mistake a narrowed result set for the entire catalog. Use facets when users need to combine meaningful independent attributes. Avoid a dense facet system for a tiny list or attributes users cannot interpret.
|
|
26
|
+
|
|
27
|
+
### Recommended Rules
|
|
28
|
+
|
|
29
|
+
1. For ordinary product attributes, begin with OR within a facet and AND across facets: `(blue OR black) AND medium`. Explain any different query semantics.
|
|
30
|
+
2. Show actual applied values, not just "3 filters". Include inherited/promoted filters and offer individual removal.
|
|
31
|
+
3. Local proposal: provide one clear-all action when multiple optional constraints are active. Define which mandatory scope it cannot remove.
|
|
32
|
+
4. Choose immediate application or an explicit Apply action from measured query cost and task behavior. Keep draft choices distinct from applied choices.
|
|
33
|
+
5. Update the count and list from the same accepted request. Preserve the query and selected filters on no results; offer reversible broadening.
|
|
34
|
+
|
|
35
|
+
### Evidence
|
|
36
|
+
|
|
37
|
+
| Source | Year | What was measured or specified |
|
|
38
|
+
| --- | --- | --- |
|
|
39
|
+
| [Baymard combined values](https://baymard.com/research-articles/allow-applying-of-multiple-filter-values) | 2024 | E-commerce observations: mutually exclusive values forced repeated searches and memorization. 15% benchmark non-support is site prevalence, not a causal abandonment estimate. OR/AND is a commerce convention, not every domain's query language. |
|
|
40
|
+
| [Baymard applied overview](https://baymard.com/research-articles/how-to-design-applied-filters) | 2020; updated 2026 | Observed confirmation, removal, and context problems without an overview. Article explicitly says testing was inconclusive about which desktop overview placement was most effective. |
|
|
41
|
+
|
|
42
|
+
### Example
|
|
43
|
+
|
|
44
|
+
Local server-backed filter form. The response should reflect applied selections and give each removable filter a URL preserving the others.
|
|
45
|
+
|
|
46
|
+
```html
|
|
47
|
+
<form action="/catalog" method="get">
|
|
48
|
+
<fieldset>
|
|
49
|
+
<legend>Color: match any selected color</legend>
|
|
50
|
+
<label><input type="checkbox" name="color" value="blue" checked>Blue</label>
|
|
51
|
+
<label><input type="checkbox" name="color" value="black">Black</label>
|
|
52
|
+
</fieldset>
|
|
53
|
+
<label for="size">Size</label>
|
|
54
|
+
<select id="size" name="size">
|
|
55
|
+
<option value="">Any size</option>
|
|
56
|
+
<option value="medium" selected>Medium</option>
|
|
57
|
+
</select>
|
|
58
|
+
<button>Apply filters</button>
|
|
59
|
+
</form>
|
|
60
|
+
<nav aria-label="Applied filters">
|
|
61
|
+
<a href="/catalog?size=medium">Remove color: blue</a>
|
|
62
|
+
<a href="/catalog?color=blue">Remove size: medium</a>
|
|
63
|
+
<a href="/catalog">Clear all filters</a>
|
|
64
|
+
</nav>
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
## Opinionated Guidance
|
|
68
|
+
|
|
69
|
+
Keep removal close to the results it explains. Use meaningful option names, and distinguish unavailable choices from choices that would produce zero results.
|
|
70
|
+
|
|
71
|
+
## Platform-Specific Guidance
|
|
72
|
+
|
|
73
|
+
A mobile filter sheet can hide draft choices; return to the result list with a visible applied overview. Focus return belongs to the sheet's interaction contract.
|
|
74
|
+
|
|
75
|
+
## Unsupported Absolutes
|
|
76
|
+
|
|
77
|
+
OR within every group is wrong for queries such as "contains all these ingredients". An applied-filter count alone does not explain scope. No fixed number of facets is proven optimal.
|
|
78
|
+
|
|
79
|
+
## Verification Contract
|
|
80
|
+
|
|
81
|
+
Proposed checks: two values in one facet, two facet types, direct URL, Back, clear-one, clear-all, zero results, obsolete response, and mobile sheet dismissal. Accessibility requires labeled groups, keyboard removal, stable focus after removal, and concise announced result updates for dynamic changes. No consumer execution is claimed. Re-review on query logic or application-policy changes.
|
|
82
|
+
|
|
83
|
+
## Source, License, And Attribution
|
|
84
|
+
|
|
85
|
+
Locally authored synthesis and fragment; primary sources rechecked 2026-10-19, no upstream samples copied. `consumer_reference: not_applicable` because no consumer search record is selected.
|
|
86
|
+
|
|
87
|
+
## IA Navigation
|
|
88
|
+
|
|
89
|
+
Parent: [Evidence Patterns](index.md).
|
|
90
|
+
Next: [Empty States And No Results](empty-states.md).
|
|
@@ -0,0 +1,82 @@
|
|
|
1
|
+
---
|
|
2
|
+
type: Domain Guide
|
|
3
|
+
title: Persistent Form Labels
|
|
4
|
+
description: Keep field identity and required instructions visible while users enter, review, and correct data.
|
|
5
|
+
aliases: ["label placement","persistent labels","placeholder labels","floating labels"]
|
|
6
|
+
questions: ["Should form labels sit above fields or inside placeholders?"]
|
|
7
|
+
domain: design-engineering
|
|
8
|
+
lifecycle: experimental
|
|
9
|
+
provenance_kind: local
|
|
10
|
+
reviewed_on: 2026-10-19
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
# Persistent Form Labels
|
|
14
|
+
|
|
15
|
+
Primary role: field labeling decision guide.
|
|
16
|
+
|
|
17
|
+
## Repository Boundary
|
|
18
|
+
|
|
19
|
+
This page owns persistent meaning and label selection. Layout owns spatial composition; [Text Input](../text-input-and-internationalization.md) owns direction and text editing. No decorative label system is introduced into reusable patterns.
|
|
20
|
+
|
|
21
|
+
## Reusable Method
|
|
22
|
+
|
|
23
|
+
### Problem And Use
|
|
24
|
+
|
|
25
|
+
Placeholder-only labels disappear just when users need to review or correct a value. Use persistent labels for data-entry controls. Avoid adding redundant visible copy when a control already has a clear visible name, such as a button.
|
|
26
|
+
|
|
27
|
+
### Recommended Rules
|
|
28
|
+
|
|
29
|
+
1. Provide one unambiguous accessible name for each input and a persistent visible label for ordinary form fields. Associate a native `label` with its input.
|
|
30
|
+
2. Local starting point: place labels above fields for narrow or translated forms. Side-aligned labels are a valid alternative when scanning and content fit are verified; there is no universal winning pixel gap.
|
|
31
|
+
3. Put necessary format/required instructions outside placeholders. Explain any required marker and distinguish optional fields consistently.
|
|
32
|
+
4. A floating label must remain readable after typing, autofill, validation, and zoom. Reserve room for full error messages; do not shrink labels into unreadable captions.
|
|
33
|
+
5. Group related choices with `fieldset` and `legend`; each option still needs its own label.
|
|
34
|
+
|
|
35
|
+
### Evidence
|
|
36
|
+
|
|
37
|
+
| Source | Year | What was measured or specified |
|
|
38
|
+
| --- | --- | --- |
|
|
39
|
+
| [Baymard mobile inline labels](https://baymard.com/research-articles/mobile-forms-avoid-inline-labels) | 2013 | Qualitative mobile checkout observations: users deleted entered values to recover vanished labels, with some abandonment. No controlled completion-time estimate. "Inline labels" here means disappearing placeholder-style labels, not inline validation. |
|
|
40
|
+
| [Labels or instructions, SC 3.3.2](https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html) | 2024 Recommendation; living explanation read 2026 | Labels/instructions required when content requires input. Does not prescribe above-versus-left placement or a measured spacing value. |
|
|
41
|
+
|
|
42
|
+
### Example
|
|
43
|
+
|
|
44
|
+
```html
|
|
45
|
+
<form action="/profile" method="post">
|
|
46
|
+
<label for="display-name">Display name</label>
|
|
47
|
+
<p id="name-help">Use the name you want other members to see.</p>
|
|
48
|
+
<input id="display-name" name="displayName" autocomplete="nickname"
|
|
49
|
+
aria-describedby="name-help">
|
|
50
|
+
<fieldset>
|
|
51
|
+
<legend>Digest frequency</legend>
|
|
52
|
+
<label><input type="radio" name="digest" value="weekly" checked>Weekly</label>
|
|
53
|
+
<label><input type="radio" name="digest" value="never">Never</label>
|
|
54
|
+
</fieldset>
|
|
55
|
+
<button>Save profile</button>
|
|
56
|
+
</form>
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
## Opinionated Guidance
|
|
60
|
+
|
|
61
|
+
Keep the label short and put explanations in associated help text. A quiet-looking form that requires memorization has not become simpler.
|
|
62
|
+
|
|
63
|
+
## Platform-Specific Guidance
|
|
64
|
+
|
|
65
|
+
Native floating-label controls and browser autofill need their own verification. Aligning text differently for RTL does not remove label associations or change reading order.
|
|
66
|
+
|
|
67
|
+
## Unsupported Absolutes
|
|
68
|
+
|
|
69
|
+
The cited study does not prove above-field labels always beat side labels. Its limited 1-2-field exceptions do not remove the accessible-name obligation. Floating labels are not automatically inaccessible or automatically proven usable.
|
|
70
|
+
|
|
71
|
+
## Verification Contract
|
|
72
|
+
|
|
73
|
+
Proposed checks: empty, populated, autofilled, invalid, disabled, long label, RTL, keyboard activation of a label, and zoom. Accessibility requires visible meaning, programmatic association, and contrast in each state; test both the name and help description. No browser/consumer execution is claimed. Re-review when label movement, autofill, or form composition changes.
|
|
74
|
+
|
|
75
|
+
## Source, License, And Attribution
|
|
76
|
+
|
|
77
|
+
Locally authored synthesis and example; sources rechecked 2026-10-19. No source samples copied. `consumer_reference: not_applicable` because no consumer form record is selected.
|
|
78
|
+
|
|
79
|
+
## IA Navigation
|
|
80
|
+
|
|
81
|
+
Parent: [Evidence Patterns](index.md).
|
|
82
|
+
Next: [Localized Input Masks](input-masks.md).
|
|
@@ -0,0 +1,69 @@
|
|
|
1
|
+
# Evidence-Based Interface Patterns
|
|
2
|
+
|
|
3
|
+
Primary role: product interaction selection guide.
|
|
4
|
+
|
|
5
|
+
Domain classification: design-engineering. Lifecycle: `experimental`. Provenance: locally authored synthesis. Reviewed on: 2026-10-19.
|
|
6
|
+
|
|
7
|
+
## Repository Boundary
|
|
8
|
+
|
|
9
|
+
Domain classification: design-engineering. These 12 experimental patterns own product decisions, not reusable spatial primitives or shared visual defaults. [Layout](../../layout/index.md) retains spatial ownership; [Quality](../../quality/index.md) retains evidence and accessibility precedence. This collection selects no consumer profile.
|
|
10
|
+
|
|
11
|
+
## Reusable Method
|
|
12
|
+
|
|
13
|
+
Start with the failure the user encounters, then select a pattern and verify its proposed cases in the consumer. Requirements, observed research findings, and local recommendations are different kinds of support.
|
|
14
|
+
|
|
15
|
+
### Pattern Routes
|
|
16
|
+
|
|
17
|
+
| User problem | Pattern | Decision |
|
|
18
|
+
| --- | --- | --- |
|
|
19
|
+
| Errors appear before entry is complete. | [Inline Validation Timing](inline-validation.md) | First validation versus correction timing |
|
|
20
|
+
| Submission fails without a recovery path. | [Error Messages And Recovery Summaries](error-recovery.md) | Specific messages, summary, focus |
|
|
21
|
+
| Field identity disappears after typing. | [Persistent Form Labels](form-labels.md) | Persistent labels and instructions |
|
|
22
|
+
| Formatting rejects valid regional data. | [Localized Input Masks](input-masks.md) | Flexible input versus verified mask |
|
|
23
|
+
| Hidden filters narrow the catalog unexpectedly. | [Faceted Filter Selection](faceted-filters.md) | Query logic and applied-value removal |
|
|
24
|
+
| Empty content has no explanation. | [Empty States And No Results](empty-states.md) | First use versus zero matches/failure |
|
|
25
|
+
| Table sorting or comparison loses context. | [Data Table Interaction](data-tables.md) | Sort scope, density, header semantics |
|
|
26
|
+
| Similar controls imply different actions. | [Tabs And Segmented Controls](tabs-and-segmented-controls.md) | Panels versus values versus routes |
|
|
27
|
+
| Highlighted text is committed accidentally. | [Autocomplete Acceptance](autocomplete.md) | Draft, candidate, accepted identity |
|
|
28
|
+
| Parent location is confused with history. | [Breadcrumb Hierarchy](breadcrumbs.md) | Ancestry versus Back |
|
|
29
|
+
| Bottom navigation mixes commands and routes. | [Bottom Navigation Destinations](bottom-navigation.md) | Stable peer destinations |
|
|
30
|
+
| Theme changes erase meaningful contrast. | [Dark Mode Contrast](dark-mode-contrast.md) | Actual state/pair measurement |
|
|
31
|
+
|
|
32
|
+
### Existing Owners To Extend Or Compose
|
|
33
|
+
|
|
34
|
+
- [Loading And Feedback](../loading-and-feedback.md): toast versus inline feedback, skeleton/spinner selection, and bounded 0.1/1/10-second heuristics.
|
|
35
|
+
- [Native Interaction Contracts](../native-interaction-contracts.md): modal focus containment and return.
|
|
36
|
+
- [Input And Focus](../../platform-guides/input-and-focus.md): 24/44 CSS px target criteria, gesture alternatives, and input paths.
|
|
37
|
+
- [Deletion And Supported Undo](../state-management/recipes/delete-undo.md): confirmation versus real reversibility.
|
|
38
|
+
- [Accessible Motion](../../motion/accessible-motion.md): motion alternatives for pending work.
|
|
39
|
+
|
|
40
|
+
### Evidence Reading Rules
|
|
41
|
+
|
|
42
|
+
WCAG references use the [2024 WCAG 2.2 Recommendation](https://www.w3.org/TR/WCAG22/); its Understanding pages explain requirements. APG is informative implementation guidance. Living documents are labeled by the 2026 reading year where no fixed publication year is claimed. Baymard and NN/g findings retain their task context: site prevalence is not a user success rate, an observed extreme is not a mean, and a recommendation is not a controlled experiment.
|
|
43
|
+
|
|
44
|
+
All cited bodies were rechecked 2026-10-19. A resolving URL is not proof that its recommendation fits every product. No consumer study, assistive-technology run, or browser conformance result is claimed.
|
|
45
|
+
|
|
46
|
+
## Opinionated Guidance
|
|
47
|
+
|
|
48
|
+
Prefer a bounded rule with a counterexample over a borrowed absolute. Numeric requirements retain their criterion, units, level, and exceptions; local counts and timings are explicitly proposals rather than research results.
|
|
49
|
+
|
|
50
|
+
## Platform-Specific Guidance
|
|
51
|
+
|
|
52
|
+
Record the actual browser, OS, input method, and assistive technology. Apple HIG and Android conventions are not web standards, and native points/dp are not automatically CSS pixels.
|
|
53
|
+
|
|
54
|
+
## Unsupported Absolutes
|
|
55
|
+
|
|
56
|
+
"Evidence-based" does not mean empirically proven for every task. No source in this collection authorizes a universal visual theme, mandatory framework, or accessibility guarantee from a code fragment.
|
|
57
|
+
|
|
58
|
+
## Verification Contract
|
|
59
|
+
|
|
60
|
+
For each chosen pattern, turn its cases into expected outcomes, run the real task, and retain actual evidence separately. The repository's domain/link/material checks validate documentation structure and retrieval, not those product outcomes. Re-review on a source revision, failed task, changed semantics, or changed owner.
|
|
61
|
+
|
|
62
|
+
## Source, License, And Attribution
|
|
63
|
+
|
|
64
|
+
Locally authored synthesis; primary sources are linked in each pattern with year and measurement boundary. No upstream prose, artwork, or samples copied. `consumer_reference: not_applicable` because the collection selects no consumer record.
|
|
65
|
+
|
|
66
|
+
## IA Navigation
|
|
67
|
+
|
|
68
|
+
Parent: [Design Engineering](../index.md).
|
|
69
|
+
Next: [Inline Validation Timing](inline-validation.md).
|
|
@@ -0,0 +1,94 @@
|
|
|
1
|
+
---
|
|
2
|
+
type: Domain Guide
|
|
3
|
+
title: Inline Validation Timing
|
|
4
|
+
description: Validate completed input without interrupting initial entry and clear corrected errors promptly.
|
|
5
|
+
aliases: ["inline validation","validation timing","validate on blur","premature validation"]
|
|
6
|
+
questions: ["When should form fields show validation errors?"]
|
|
7
|
+
domain: design-engineering
|
|
8
|
+
lifecycle: experimental
|
|
9
|
+
provenance_kind: local
|
|
10
|
+
reviewed_on: 2026-10-19
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
# Inline Validation Timing
|
|
14
|
+
|
|
15
|
+
Primary role: form validation decision guide.
|
|
16
|
+
|
|
17
|
+
## Repository Boundary
|
|
18
|
+
|
|
19
|
+
This page owns when product validation becomes visible. [Text Input And Internationalization](../text-input-and-internationalization.md) owns composition and editing; [Error Recovery](error-recovery.md) owns message content and submission summaries. Client feedback does not replace server validation.
|
|
20
|
+
|
|
21
|
+
## Reusable Method
|
|
22
|
+
|
|
23
|
+
### Problem And Use
|
|
24
|
+
|
|
25
|
+
An incomplete value is not necessarily a mistake: the user may still be typing. Use inline validation when a field can be checked independently. Avoid a success claim when validity depends on an uncompleted server check or another unfinished field.
|
|
26
|
+
|
|
27
|
+
### Recommended Rules
|
|
28
|
+
|
|
29
|
+
1. Local proposal: start with three presentation states: untouched, checked-invalid, checked-valid. Do not show required-field errors on initial focus.
|
|
30
|
+
2. Check a newly edited field on leaving it, or at a genuinely complete input boundary. There is no universal character count or millisecond debounce for all fields.
|
|
31
|
+
3. After an error is exposed, recheck on committed input so it disappears when corrected. Recheck dependent fields when their dependency changes.
|
|
32
|
+
4. Keep submission validation as a backstop. Preserve all recoverable input, identify every rejected field, and accept only the current request's result.
|
|
33
|
+
5. During IME composition, preserve provisional text; defer disruptive validation until composition completes. "Format accepted" must not claim that an address exists or a payment succeeded.
|
|
34
|
+
|
|
35
|
+
### Evidence
|
|
36
|
+
|
|
37
|
+
| Source | Year | What was measured or specified |
|
|
38
|
+
| --- | --- | --- |
|
|
39
|
+
| [Baymard inline validation](https://baymard.com/research-articles/inline-form-validation) | 2024 | Qualitative checkout observations: premature errors interrupted typing; stale errors misled users after correction. Public article provides examples, not a controlled effect size or participant denominator for these claims. |
|
|
40
|
+
| [WCAG error identification](https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html) | 2024 Recommendation; living explanation read 2026 | SC 3.3.1 requires text identification of automatically detected errors. It does not prescribe blur timing. No usability experiment. |
|
|
41
|
+
|
|
42
|
+
### Example
|
|
43
|
+
|
|
44
|
+
This local example progressively adds blur feedback to native validation; native submission remains available. Server checks are outside its scope.
|
|
45
|
+
|
|
46
|
+
```html
|
|
47
|
+
<form action="/subscribe" method="post">
|
|
48
|
+
<label for="address">Email address</label>
|
|
49
|
+
<input id="address" name="email" type="email" required
|
|
50
|
+
aria-describedby="address-error">
|
|
51
|
+
<p id="address-error"></p>
|
|
52
|
+
<button>Subscribe</button>
|
|
53
|
+
</form>
|
|
54
|
+
<script>
|
|
55
|
+
const field = document.querySelector("#address");
|
|
56
|
+
const error = document.querySelector("#address-error");
|
|
57
|
+
let checked = false;
|
|
58
|
+
function validate() {
|
|
59
|
+
const invalid = !field.validity.valid;
|
|
60
|
+
field.setAttribute("aria-invalid", String(invalid));
|
|
61
|
+
error.textContent = invalid ? "Enter a complete email address." : "";
|
|
62
|
+
}
|
|
63
|
+
field.addEventListener("blur", () => { checked = true; validate(); });
|
|
64
|
+
field.addEventListener("input", (event) => {
|
|
65
|
+
if (checked && !event.isComposing) validate();
|
|
66
|
+
});
|
|
67
|
+
field.addEventListener("compositionend", () => { if (checked) validate(); });
|
|
68
|
+
</script>
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
## Opinionated Guidance
|
|
72
|
+
|
|
73
|
+
Prefer fewer truthful messages over a green check on every keystroke. Keep visual updates separate from announcements so correction does not create continuous speech.
|
|
74
|
+
|
|
75
|
+
## Platform-Specific Guidance
|
|
76
|
+
|
|
77
|
+
Native validation messages and focus behavior differ by browser. A server-rendered rejection needs equivalent inline relationships and preserved values.
|
|
78
|
+
|
|
79
|
+
## Unsupported Absolutes
|
|
80
|
+
|
|
81
|
+
Blur is not always the correct commit boundary. Baymard's checkout findings do not establish an optimal timing policy for every form. Its article contains inconsistent 31%/32% benchmark figures; neither is used here as an effect estimate.
|
|
82
|
+
|
|
83
|
+
## Verification Contract
|
|
84
|
+
|
|
85
|
+
Proposed checks: initial focus has no error; blur an incomplete value; correct it without blurring; edit a confirmation dependency; paste; compose text; submit untouched required fields; receive an obsolete server response. Inspect text, `aria-invalid`, focus, and announcements. Accessibility requires text rather than color alone and a programmatic field/message relationship. These cases and the example have not been executed against a consumer. Re-review on validation, dependency, or input-method changes.
|
|
86
|
+
|
|
87
|
+
## Source, License, And Attribution
|
|
88
|
+
|
|
89
|
+
Locally authored synthesis and example; no source samples copied. Sources rechecked 2026-10-19. `consumer_reference: not_applicable` because no consumer form record is selected.
|
|
90
|
+
|
|
91
|
+
## IA Navigation
|
|
92
|
+
|
|
93
|
+
Parent: [Evidence Patterns](index.md).
|
|
94
|
+
Next: [Error Messages And Recovery Summaries](error-recovery.md).
|
|
@@ -0,0 +1,79 @@
|
|
|
1
|
+
---
|
|
2
|
+
type: Domain Guide
|
|
3
|
+
title: Localized Input Masks
|
|
4
|
+
description: Choose flexible input before adding a verified regional mask that preserves editing and valid data.
|
|
5
|
+
aliases: ["input masks","phone formatting","localized input","masked fields"]
|
|
6
|
+
questions: ["When should a phone field use an input mask?"]
|
|
7
|
+
domain: design-engineering
|
|
8
|
+
lifecycle: experimental
|
|
9
|
+
provenance_kind: local
|
|
10
|
+
reviewed_on: 2026-10-19
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
# Localized Input Masks
|
|
14
|
+
|
|
15
|
+
Primary role: formatting and mask selection guide.
|
|
16
|
+
|
|
17
|
+
## Repository Boundary
|
|
18
|
+
|
|
19
|
+
This page owns whether formatting should constrain a field. [Text Input And Internationalization](../text-input-and-internationalization.md) owns IME, caret, undo, and representation boundaries. Domain guidance supplies no shared mask library or universal telephone parser.
|
|
20
|
+
|
|
21
|
+
## Reusable Method
|
|
22
|
+
|
|
23
|
+
### Problem And Use
|
|
24
|
+
|
|
25
|
+
A mask can clarify grouping but reject perfectly valid numbers from another country. Use it only for a verified, bounded format with a demonstrated input need. Avoid one fixed mask for international phone numbers, names, or uncertain identifiers.
|
|
26
|
+
|
|
27
|
+
### Recommended Rules
|
|
28
|
+
|
|
29
|
+
1. Start with flexible text input. Local proposal: support at least paste, autofill, selection replacement, deletion, and undo before considering a mask acceptable.
|
|
30
|
+
2. Separate raw edit text, parsed canonical data, and display formatting. Never silently truncate to fit the display.
|
|
31
|
+
3. Apply regional formatting only after the region and its valid forms are known. Unsupported regions retain the flexible field.
|
|
32
|
+
4. Prefer `type="tel"` for telephone input, not a numeric quantity control. Keyboard hints are not validators; preserve a meaningful plus sign and extension when the contract supports them.
|
|
33
|
+
5. Treat incomplete input as an editing state. Reformat at a declared commit boundary when live rewriting would disrupt composition or caret position.
|
|
34
|
+
|
|
35
|
+
### Evidence
|
|
36
|
+
|
|
37
|
+
| Source | Year | What was measured or specified |
|
|
38
|
+
| --- | --- | --- |
|
|
39
|
+
| [Baymard input masking](https://baymard.com/research-articles/input-masking-form-field) | 2017 | Reports 89% of test subjects entered restricted numerical fields differently from supplied formatting examples. This is observed formatting variation, not a mask benefit percentage; the public article does not give a denominator for that statistic. |
|
|
40
|
+
| [Labels or instructions](https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html) | 2024 Recommendation; living explanation read 2026 | Required instructions must be available; a mask does not itself establish an accessible field name or explanation. No usability measurement. |
|
|
41
|
+
|
|
42
|
+
### Example
|
|
43
|
+
|
|
44
|
+
This is the intentional unmasked default, not a partial mask implementation. The server must parse and validate the supported regions without assuming a fixed digit count.
|
|
45
|
+
|
|
46
|
+
```html
|
|
47
|
+
<form action="/contact" method="post">
|
|
48
|
+
<label for="phone">Contact telephone</label>
|
|
49
|
+
<p id="phone-help">Include your country code. Spaces and punctuation are accepted.</p>
|
|
50
|
+
<input id="phone" name="phone" type="tel" autocomplete="tel"
|
|
51
|
+
aria-describedby="phone-help">
|
|
52
|
+
<button>Save contact</button>
|
|
53
|
+
</form>
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
## Opinionated Guidance
|
|
57
|
+
|
|
58
|
+
Use a mask to aid input, never to conceal a parser's narrow assumptions. Verify the help text against what the server actually accepts.
|
|
59
|
+
|
|
60
|
+
## Platform-Specific Guidance
|
|
61
|
+
|
|
62
|
+
Phone keyboards, autofill payloads, and composition paths vary across devices. Verify a real input method; synthetic key events do not reproduce it.
|
|
63
|
+
|
|
64
|
+
## Unsupported Absolutes
|
|
65
|
+
|
|
66
|
+
Not all telephone numbers have 10 digits. An example placeholder does not force users to follow that format. The 2017 findings do not prove a particular modern masking library reliable.
|
|
67
|
+
|
|
68
|
+
## Verification Contract
|
|
69
|
+
|
|
70
|
+
Proposed checks: international plus prefix, variable lengths, extension, pasted punctuation, caret edits in the middle, clear/undo, autofill, IME, and region change while editing. Accessibility requires persistent labels, announced errors, and no unexplained rejection or loss of data. Record round-trip values and selection positions. No consumer execution is claimed. Re-review when supported regions, parser, or formatter changes.
|
|
71
|
+
|
|
72
|
+
## Source, License, And Attribution
|
|
73
|
+
|
|
74
|
+
Locally authored synthesis and example; sources rechecked 2026-10-19, no source code copied. `consumer_reference: not_applicable` because no consumer input record is selected.
|
|
75
|
+
|
|
76
|
+
## IA Navigation
|
|
77
|
+
|
|
78
|
+
Parent: [Evidence Patterns](index.md).
|
|
79
|
+
Next: [Faceted Filter Selection](faceted-filters.md).
|
|
@@ -0,0 +1,81 @@
|
|
|
1
|
+
---
|
|
2
|
+
type: Domain Guide
|
|
3
|
+
title: Tabs And Segmented Controls
|
|
4
|
+
description: Separate panel navigation from value selection and choose an explicit keyboard and activation model.
|
|
5
|
+
aliases: ["tabs versus segmented control","tab activation","segmented selection","tab panels"]
|
|
6
|
+
questions: ["Should this control be tabs or a segmented selector?"]
|
|
7
|
+
domain: design-engineering
|
|
8
|
+
lifecycle: experimental
|
|
9
|
+
provenance_kind: local
|
|
10
|
+
reviewed_on: 2026-10-19
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
# Tabs And Segmented Controls
|
|
14
|
+
|
|
15
|
+
Primary role: mutually exclusive view and value selection guide.
|
|
16
|
+
|
|
17
|
+
## Repository Boundary
|
|
18
|
+
|
|
19
|
+
This page owns semantics and activation, not the wrapping provided by [Tab Strip](../../patterns/in-line-grouping/tab-strip.md). [Native Interaction Contracts](../native-interaction-contracts.md) owns composite behavior selection and focus responsibility.
|
|
20
|
+
|
|
21
|
+
## Reusable Method
|
|
22
|
+
|
|
23
|
+
### Problem And Use
|
|
24
|
+
|
|
25
|
+
Identical pill-shaped visuals can navigate panels, select a value, or issue commands. Use tabs for layered peer panels; use a radio group for one value from related options; use ordinary links for navigation to destinations. Avoid tab roles on controls with no associated panels.
|
|
26
|
+
|
|
27
|
+
### Recommended Rules
|
|
28
|
+
|
|
29
|
+
1. For APG tabs, expose a named tablist, tab/panel associations, exactly one selected tab, and one displayed panel in the basic single-selection model.
|
|
30
|
+
2. Provide one tab stop into the tablist; Arrow keys navigate tabs. In manual activation, Space/Enter selects. Horizontal tabs must not consume Up/Down scrolling keys.
|
|
31
|
+
3. Use automatic activation only when panel display has no noticeable latency. Remote loading is a reason to consider manual activation, not a reason to delay keyboard focus.
|
|
32
|
+
4. Treat segment count as platform guidance: Apple suggests about 5-7 in wide interfaces and about 5 or fewer on iPhone. Content fit and localization can require fewer; these are not WCAG limits.
|
|
33
|
+
5. Keep selected values independent from focus. Do not mix selection segments and destructive commands in one control.
|
|
34
|
+
|
|
35
|
+
### Evidence
|
|
36
|
+
|
|
37
|
+
| Source | Year | What was measured or specified |
|
|
38
|
+
| --- | --- | --- |
|
|
39
|
+
| [APG tabs](https://www.w3.org/WAI/ARIA/apg/patterns/tabs/) | Living guidance, read 2026 | Defines keyboard/selection/panel relationships and the no-noticeable-latency condition for automatic activation; no measured millisecond cutoff. |
|
|
40
|
+
| [Apple segmented controls](https://developer.apple.com/design/human-interface-guidelines/segmented-controls) | Living HIG, read 2026; changelog includes 2023 | Platform recommendations and examples, not a comparative experiment. macOS also supports multiple selection or action segments; native appearance does not determine web semantics. |
|
|
41
|
+
|
|
42
|
+
### Example
|
|
43
|
+
|
|
44
|
+
This local example intentionally uses native radio semantics for a value, not incomplete tab markup. Product styling may make it segmented without changing its meaning.
|
|
45
|
+
|
|
46
|
+
```html
|
|
47
|
+
<form action="/report" method="get">
|
|
48
|
+
<fieldset>
|
|
49
|
+
<legend>Report period</legend>
|
|
50
|
+
<label><input type="radio" name="period" value="week" checked>Week</label>
|
|
51
|
+
<label><input type="radio" name="period" value="month">Month</label>
|
|
52
|
+
<label><input type="radio" name="period" value="year">Year</label>
|
|
53
|
+
</fieldset>
|
|
54
|
+
<button>Show report</button>
|
|
55
|
+
</form>
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
## Opinionated Guidance
|
|
59
|
+
|
|
60
|
+
Record the meaning before choosing a component name. A server-navigated link set can look like tabs while correctly remaining links.
|
|
61
|
+
|
|
62
|
+
## Platform-Specific Guidance
|
|
63
|
+
|
|
64
|
+
Apple's toolbar/inspector and main-window recommendations differ; do not transfer an iOS segmented view switch mechanically to macOS or web. HIG body was read through its [official documentation JSON](https://developer.apple.com/tutorials/data/design/human-interface-guidelines/segmented-controls.json).
|
|
65
|
+
|
|
66
|
+
## Unsupported Absolutes
|
|
67
|
+
|
|
68
|
+
Five segments is not a universal maximum. Roving focus does not mean automatic selection. A `tab` role alone supplies no keyboard behavior.
|
|
69
|
+
|
|
70
|
+
## Verification Contract
|
|
71
|
+
|
|
72
|
+
Proposed checks: Tab entry/exit, Arrow wrap, manual activation, slow panel, preserved panel draft, removed tab, long translation, and zoom. Accessibility requires accurate selection, names, associations, visible focus, and reachable panel content. No consumer execution is claimed. Re-review on widget meaning, activation, or latency changes.
|
|
73
|
+
|
|
74
|
+
## Source, License, And Attribution
|
|
75
|
+
|
|
76
|
+
Locally authored synthesis and example; official sources rechecked 2026-10-19. No platform assets or code copied. `consumer_reference: not_applicable` because no consumer selector record is selected.
|
|
77
|
+
|
|
78
|
+
## IA Navigation
|
|
79
|
+
|
|
80
|
+
Parent: [Evidence Patterns](index.md).
|
|
81
|
+
Next: [Autocomplete Acceptance](autocomplete.md).
|
|
@@ -70,6 +70,23 @@ Choose [State Management](state-management/index.md) for UI state ownership, tra
|
|
|
70
70
|
|
|
71
71
|
This domain proposes product-layer questions. [Quality Gates](../quality/index.md) remain the shared authority for claims, evidence families, accessibility precedence, rationale, and debt.
|
|
72
72
|
|
|
73
|
+
## Evidence Patterns
|
|
74
|
+
|
|
75
|
+
Use [Evidence-Based Interface Patterns](evidence-patterns/index.md) to distinguish standards, measured observations, and local product recommendations.
|
|
76
|
+
|
|
77
|
+
- [Inline Validation Timing](evidence-patterns/inline-validation.md)
|
|
78
|
+
- [Error Messages And Recovery Summaries](evidence-patterns/error-recovery.md)
|
|
79
|
+
- [Persistent Form Labels](evidence-patterns/form-labels.md)
|
|
80
|
+
- [Localized Input Masks](evidence-patterns/input-masks.md)
|
|
81
|
+
- [Faceted Filter Selection](evidence-patterns/faceted-filters.md)
|
|
82
|
+
- [Empty States And No Results](evidence-patterns/empty-states.md)
|
|
83
|
+
- [Data Table Interaction](evidence-patterns/data-tables.md)
|
|
84
|
+
- [Tabs And Segmented Controls](evidence-patterns/tabs-and-segmented-controls.md)
|
|
85
|
+
- [Autocomplete Acceptance](evidence-patterns/autocomplete.md)
|
|
86
|
+
- [Breadcrumb Hierarchy](evidence-patterns/breadcrumbs.md)
|
|
87
|
+
- [Bottom Navigation Destinations](evidence-patterns/bottom-navigation.md)
|
|
88
|
+
- [Dark Mode Contrast](evidence-patterns/dark-mode-contrast.md)
|
|
89
|
+
|
|
73
90
|
## Source-Backed Deep Dives
|
|
74
91
|
|
|
75
92
|
- [Native Interaction Contracts](native-interaction-contracts.md). Choose dialog, disclosure, menu, popover, and combobox behavior.
|
|
@@ -2,10 +2,11 @@
|
|
|
2
2
|
type: Domain Guide
|
|
3
3
|
title: Loading, Progress, And Feedback
|
|
4
4
|
description: Separate input acknowledgement, pending work, stale content, confirmed completion, and measurable responsiveness.
|
|
5
|
+
aliases: ["loading state","spinner","skeleton","progress indicator","로딩 상태","스켈레톤","진행 표시"]
|
|
5
6
|
domain: design-engineering
|
|
6
7
|
lifecycle: experimental
|
|
7
8
|
provenance_kind: local
|
|
8
|
-
reviewed_on: 2026-
|
|
9
|
+
reviewed_on: 2026-10-19
|
|
9
10
|
---
|
|
10
11
|
|
|
11
12
|
# Loading, Progress, And Feedback
|
|
@@ -61,6 +62,33 @@ The editor submits a snapshot. Connectivity drops after the server may have rece
|
|
|
61
62
|
|
|
62
63
|
Keep the submitted snapshot distinct from edits made while saving. A successful acknowledgement for the earlier snapshot cannot mark the newer draft saved. Compose [submitted snapshot](state-management/patterns/submitted-snapshot.md) with [draft and baseline](state-management/patterns/draft-and-baseline.md).
|
|
63
64
|
|
|
65
|
+
### Indicator Choice And Time Boundaries
|
|
66
|
+
|
|
67
|
+
Extend this owner rather than creating a second loading-state catalog. A skeleton is useful only when the eventual structure is sufficiently predictable; keep placeholders stationary under reduced motion and reserve realistic space. A spinner conveys indeterminate waiting, not a completion percentage. Prefer real progress when completed and total work are meaningful. None of these choices proves shorter perceived waiting for the current task.
|
|
68
|
+
|
|
69
|
+
| Source | Year | What was measured or specified |
|
|
70
|
+
| --- | --- | --- |
|
|
71
|
+
| [NN/g response-time limits](https://www.nngroup.com/articles/response-times-3-important-limits/) | 1993; 2014 addendum | Synthesizes approximately 0.1 seconds for immediate-feeling response, 1 second for uninterrupted flow, and 10 seconds for sustained attention. These are published heuristics drawing on earlier HCI work, not a new controlled skeleton-versus-spinner experiment. |
|
|
72
|
+
| [Status Messages explanation](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html) | 2024 Recommendation; living explanation read 2026 | SC 4.1.3 addresses programmatically determinable status without taking focus; it specifies no toast timeout. |
|
|
73
|
+
|
|
74
|
+
Those two sources were rechecked 2026-10-19. The 0.1/1/10-second heuristics help identify a feedback need; they are not exact trigger timers. For work expected to exceed about 10 seconds, explain stage, honest progress where available, and a supported interruption/recovery path. Never fabricate a percent to satisfy that heuristic. Do not artificially hold fast results to display a spinner.
|
|
75
|
+
|
|
76
|
+
### Toast Versus Inline Feedback
|
|
77
|
+
|
|
78
|
+
Local selection proposal: keep field errors inline, long-running state with its affected region, and important outcomes in a durable location. A nonmodal toast can supplement a low-priority completed action when missing it does not block recovery. Do not put the only error explanation, required decision, or sole recovery action in a disappearing toast. There is no source-backed universal three-, five-, or ten-second toast duration.
|
|
79
|
+
|
|
80
|
+
For dynamic status, update an existing concise region without moving focus. Use assertive interruptions only when urgency warrants them; repeated routine success messages should not continually interrupt speech.
|
|
81
|
+
|
|
82
|
+
```html
|
|
83
|
+
<section aria-labelledby="upload-heading">
|
|
84
|
+
<h2 id="upload-heading">Upload</h2>
|
|
85
|
+
<p id="upload-status" role="status">Uploading file 2 of 4.</p>
|
|
86
|
+
<progress max="4" value="1" aria-label="Files uploaded">1 of 4</progress>
|
|
87
|
+
</section>
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
This local fragment describes one completed file and the second in progress. The state owner must update both values together from accepted work; it does not implement uploading. For completed-zero and first-use guidance, use [Empty States And No Results](evidence-patterns/empty-states.md).
|
|
91
|
+
|
|
64
92
|
## Opinionated Guidance
|
|
65
93
|
|
|
66
94
|
Prefer feedback that explains the actual stage and preserves a useful next action. Evaluate delays before showing indicators against measured task frequency and latency distribution; do not turn a borrowed delay into a universal rule. Avoid artificially holding completed content merely to finish a decorative loading cycle.
|
|
@@ -2,6 +2,8 @@
|
|
|
2
2
|
type: Domain Guide
|
|
3
3
|
title: Native Interaction Contracts
|
|
4
4
|
description: Choose disclosure, dialog, popover, menu, and combobox behavior by semantics, focus, dismissal, and input ownership.
|
|
5
|
+
aliases: ["dialog","popover","modal","menu","combobox","다이얼로그","팝오버","모달"]
|
|
6
|
+
questions: ["When should I use a dialog instead of a popover?"]
|
|
5
7
|
domain: design-engineering
|
|
6
8
|
lifecycle: experimental
|
|
7
9
|
provenance_kind: local
|
|
@@ -66,6 +68,14 @@ An editable combobox has at least two responsibilities: editing text and navigat
|
|
|
66
68
|
|
|
67
69
|
A disabled-looking control needs a deliberate discoverability policy. Native `disabled` and `aria-disabled` have different behavior; choose which focus and activation behavior the task requires, and explain why an action is unavailable without relying only on color.
|
|
68
70
|
|
|
71
|
+
### Modal Focus Checklist
|
|
72
|
+
|
|
73
|
+
The [APG modal-dialog source](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/) was rechecked 2026-10-19. It is living informative guidance, not a measured comparison. It requires an explicit model of focus inside the modal, Tab/Shift+Tab containment, Escape dismissal, and focus return. Local checklist: verify both boundaries of the tab sequence, not only initial focus.
|
|
74
|
+
|
|
75
|
+
For long structured content, consider initial focus on a static heading with `tabindex="-1"` so the beginning remains visible. Do not assign positive tabindex values to force an artificial reading order. Include a visible close action. After closing, return to the opener unless it no longer exists or a documented workflow makes another destination logical. `aria-modal="true"` describes modality; it does not trap focus or make the background inert.
|
|
76
|
+
|
|
77
|
+
These checks extend this guide's existing modal contract. They do not authorize a second focus-trap implementation or establish a browser/screen-reader result.
|
|
78
|
+
|
|
69
79
|
## Opinionated Guidance
|
|
70
80
|
|
|
71
81
|
Prefer native semantics when they fit the task, and build the smallest custom behavior that remains necessary. Name the semantic reason for every role override. Treat multiple open surfaces as an ownership question: which surface receives Escape, where focus stays, and which state survives dismissal.
|
|
@@ -2,6 +2,8 @@
|
|
|
2
2
|
type: Domain Guide
|
|
3
3
|
title: Latest Request Wins
|
|
4
4
|
description: Prevent an older read response from replacing the result of a newer user intent.
|
|
5
|
+
aliases: ["race condition","stale response","out of order responses","경쟁 조건","오래된 응답"]
|
|
6
|
+
questions: ["How do I stop an older search response from replacing newer results?"]
|
|
5
7
|
domain: design-engineering
|
|
6
8
|
lifecycle: experimental
|
|
7
9
|
provenance_kind: local
|
|
@@ -2,6 +2,7 @@
|
|
|
2
2
|
type: Domain Guide
|
|
3
3
|
title: Optimistic Overlay And Recovery
|
|
4
4
|
description: Show a speculative change while preserving an authoritative base for recovery.
|
|
5
|
+
aliases: ["optimistic update","optimistic UI","rollback","낙관적 업데이트"]
|
|
5
6
|
domain: design-engineering
|
|
6
7
|
lifecycle: experimental
|
|
7
8
|
provenance_kind: local
|
|
@@ -2,6 +2,8 @@
|
|
|
2
2
|
type: Domain Guide
|
|
3
3
|
title: Single Flight And Duplicate Submission
|
|
4
4
|
description: Apply an explicit policy to repeated activation of one pending operation.
|
|
5
|
+
aliases: ["double submit","duplicate submission","prevent double click","중복 제출","중복 클릭 방지","중복 제출 방지"]
|
|
6
|
+
questions: ["How do I prevent a form from being submitted twice?"]
|
|
5
7
|
domain: design-engineering
|
|
6
8
|
lifecycle: experimental
|
|
7
9
|
provenance_kind: local
|
|
@@ -2,6 +2,8 @@
|
|
|
2
2
|
type: Domain Guide
|
|
3
3
|
title: Unsaved Changes And Navigation
|
|
4
4
|
description: Make leaving an edited screen an explicit decision without losing the current draft.
|
|
5
|
+
aliases: ["unsaved changes warning","leave page confirmation","beforeunload","저장하지 않은 변경 사항","이탈 경고"]
|
|
6
|
+
questions: ["How do I warn before leaving with unsaved changes?"]
|
|
5
7
|
domain: design-engineering
|
|
6
8
|
lifecycle: experimental
|
|
7
9
|
provenance_kind: local
|