stylegallery 0.1.0

package/patterns/viewport-shell/fixed-sidenav-shell.md

@@ -0,0 +1,97 @@
+---
+type: Layout Pattern
+name: fixed-sidenav-shell
+title: fixed-sidenav-shell
+category: Viewport / Shell
+description: Keep side navigation stable while main content scrolls.
+primary_spatial_problem: Keep side navigation stable while main content scrolls.
+secondary_spatial_problems: none
+layout_axis: both
+content_shape: mixed
+responsiveness: fluid
+constraints: Uses only local class hooks and explicit layout constraints.
+scroll_ownership: Pattern owns the named scroll container.
+source_lineage: https://carbondesignsystem.com/elements/2x-grid/overview/
+lifecycle: generated
+generated_from: scripts/generate-patterns.mjs, scripts/pattern-data.mjs
+---
+
+<!-- Generated from `scripts/generate-patterns.mjs` and `scripts/pattern-data.mjs`. Do not hand-edit generated catalog or pattern docs; edit the source files and regenerate. -->
+
+# fixed-sidenav-shell
+
+## When To Use
+
+Use this pattern when you need to keep side navigation stable while main content scrolls.
+
+## HTML
+
+```html
+<section class="fixed_sidenav_shell" aria-label="Settings">
+    <nav class="fixed_sidenav_shell_list"><a href="#">Profile</a><a href="#">Billing</a></nav>
+    <main class="fixed_sidenav_shell_main">Editable settings form scrolls independently</main>
+</section>
+```
+
+## CSS
+
+```css
+.fixed_sidenav_shell {
+    display: grid;
+    grid-template-columns: 16rem minmax(0, 1fr);
+    grid-template-rows: minmax(0, 1fr);
+    max-block-size: 100dvh;
+}
+
+.fixed_sidenav_shell_list {
+    min-block-size: 0;
+}
+
+.fixed_sidenav_shell_main {
+    min-block-size: 0;
+    overflow: auto;
+}
+```
+
+## Core Properties
+
+- `display`, `grid-template-columns`, `grid-template-rows`, `max-block-size`, `min-block-size`, `overflow` define the spatial behavior for this pattern.
+
+## Properties That Break The Layout If Removed
+
+- Removing `display`, `grid-template-columns`, `grid-template-rows`, `max-block-size`, `min-block-size`, `overflow` changes the pattern from its documented layout responsibility back toward ordinary flow or an unsafe fixed arrangement.
+
+## Constraints And Change Points
+
+- fluid responsiveness is part of the contract; change sizing values only when the new minimum, maximum, or wrap point is documented with the pattern.
+- Keep the HTML class hooks and CSS selectors in one-to-one agreement.
+
+## Scroll Ownership
+
+Pattern owns the named scroll container.
+
+## Accessibility And Source Order Notes
+
+- Semantic role expectation: Preserve the HTML sample's landmark, list, navigation, form, figure, or article roles; layout classes must not replace semantic elements.
+- DOM order expectation: Keep semantic elements, DOM order, reading order, and focus order independent from the visual placement created by the layout classes.
+- Focus risk: Any interactive descendants follow DOM order; do not use this pattern to create a visual order that keyboard focus cannot follow.
+- Scroll expectation: Pattern owns the named scroll container.
+- Cognitive risk: Medium: scroll ownership can hide context, controls, or return points if it is not named in the consuming layout.
+
+## Browser And Fallback Notes
+
+The CSS uses modern grid, flex, intrinsic sizing, logical properties, or positioning. If a target browser cannot support a property, fall back to ordinary block flow before adding decorative or script-driven layout behavior.
+
+## Composition Notes
+
+Use `fixed_sidenav_shell` as the stable pattern root and compose additional layout behavior outside that root unless the child class is part of the documented relationship.
+
+## Anti-patterns
+
+- Do not add color, border, shadow, typography, or animation rules to reusable pattern CSS.
+- Do not use this pattern to repair unclear HTML structure; make the DOM roles legible first.
+
+## IA Navigation
+
+Parent: [Viewport / Shell patterns](index.md) in [Pattern Categories](../index.md).
+Next: [Layout Recipes](../../recipes/index.md) for screen-level composition, or return to the [Layout Pattern Catalog](../../CATALOG.md) when choosing another primitive.

package/patterns/viewport-shell/holy-grail.md

@@ -0,0 +1,112 @@
+---
+type: Layout Pattern
+name: holy-grail
+title: holy-grail
+category: Viewport / Shell
+description: Place header, footer, sidebars, and main content in a resilient shell.
+primary_spatial_problem: Place header, footer, sidebars, and main content in a resilient shell.
+secondary_spatial_problems: none
+layout_axis: both
+content_shape: mixed
+responsiveness: breakpointed
+constraints: Uses only local class hooks and explicit layout constraints.
+scroll_ownership: No internal scroll container.
+source_lineage: https://web.dev/articles/one-line-layouts
+lifecycle: generated
+generated_from: scripts/generate-patterns.mjs, scripts/pattern-data.mjs
+---
+
+<!-- Generated from `scripts/generate-patterns.mjs` and `scripts/pattern-data.mjs`. Do not hand-edit generated catalog or pattern docs; edit the source files and regenerate. -->
+
+# holy-grail
+
+## When To Use
+
+Use this pattern when you need to place header, footer, sidebars, and main content in a resilient shell.
+
+## HTML
+
+```html
+<section class="holy_grail" aria-label="News page">
+    <header class="holy_grail_header">Daily briefing</header>
+    <aside class="holy_grail_left">Topic navigation</aside>
+    <main class="holy_grail_main">Lead story and article stream</main>
+    <aside class="holy_grail_right">Market snapshot</aside>
+    <footer class="holy_grail_footer">Edition links</footer>
+</section>
+```
+
+## CSS
+
+```css
+.holy_grail {
+    display: grid;
+    gap: 1rem;
+    grid-template: "header header header" auto "left main right" 1fr "footer footer footer" auto / minmax(12rem, auto) 1fr minmax(12rem, auto);
+    min-block-size: 100dvh;
+}
+
+.holy_grail_header {
+    grid-area: header;
+}
+
+.holy_grail_left {
+    grid-area: left;
+}
+
+.holy_grail_main {
+    grid-area: main;
+    min-inline-size: 0;
+}
+
+.holy_grail_right {
+    grid-area: right;
+}
+
+.holy_grail_footer {
+    grid-area: footer;
+}
+```
+
+## Core Properties
+
+- `display`, `gap`, `grid-template`, `min-block-size`, `grid-area`, `min-inline-size` define the spatial behavior for this pattern.
+
+## Properties That Break The Layout If Removed
+
+- Removing `display`, `gap`, `grid-template`, `min-block-size`, `grid-area`, `min-inline-size` changes the pattern from its documented layout responsibility back toward ordinary flow or an unsafe fixed arrangement.
+
+## Constraints And Change Points
+
+- breakpointed responsiveness is part of the contract; change sizing values only when the new minimum, maximum, or wrap point is documented with the pattern.
+- Keep the HTML class hooks and CSS selectors in one-to-one agreement.
+
+## Scroll Ownership
+
+No internal scroll container.
+
+## Accessibility And Source Order Notes
+
+- Semantic role expectation: Preserve the HTML sample's landmark, list, navigation, form, figure, or article roles; layout classes must not replace semantic elements.
+- DOM order expectation: Keep semantic elements, DOM order, reading order, and focus order independent from the visual placement created by the layout classes.
+- Focus risk: Any interactive descendants follow DOM order; do not use this pattern to create a visual order that keyboard focus cannot follow.
+- Scroll expectation: No internal scroll container.
+- Cognitive risk: Low: the pattern should preserve ordinary reading flow when semantic order is already correct.
+
+## Browser And Fallback Notes
+
+The CSS uses modern grid, flex, intrinsic sizing, logical properties, or positioning. If a target browser cannot support a property, fall back to ordinary block flow before adding decorative or script-driven layout behavior.
+
+## Composition Notes
+
+Use `holy_grail` as the stable pattern root and compose additional layout behavior outside that root unless the child class is part of the documented relationship.
+
+## Anti-patterns
+
+- Do not add color, border, shadow, typography, or animation rules to reusable pattern CSS.
+- Do not use this pattern to repair unclear HTML structure; make the DOM roles legible first.
+
+## IA Navigation
+
+Parent: [Viewport / Shell patterns](index.md) in [Pattern Categories](../index.md).
+Next: [Layout Recipes](../../recipes/index.md) for screen-level composition, or return to the [Layout Pattern Catalog](../../CATALOG.md) when choosing another primitive.

package/patterns/viewport-shell/index.md

@@ -0,0 +1,11 @@
+# Viewport / Shell
+
+<!-- Generated from `scripts/generate-patterns.mjs` and `scripts/pattern-data.mjs`. Do not hand-edit generated catalog or pattern docs; edit the source files and regenerate. -->
+
+- [cover](cover.md) - Keep a central region balanced between optional header and footer.
+- [holy-grail](holy-grail.md) - Place header, footer, sidebars, and main content in a resilient shell.
+- [sticky-footer](sticky-footer.md) - Keep footer at the bottom when content is short.
+- [sticky-header](sticky-header.md) - Keep a header visible above a scrolling content region.
+- [scroll-body-shell](scroll-body-shell.md) - Keep shell regions fixed while only the body scrolls.
+- [fixed-sidenav-shell](fixed-sidenav-shell.md) - Keep side navigation stable while main content scrolls.
+- [panel-layout](panel-layout.md) - Create predictable main and utility panels.

package/patterns/viewport-shell/panel-layout.md

@@ -0,0 +1,95 @@
+---
+type: Layout Pattern
+name: panel-layout
+title: panel-layout
+category: Viewport / Shell
+description: Create predictable main and utility panels.
+primary_spatial_problem: Create predictable main and utility panels.
+secondary_spatial_problems: none
+layout_axis: inline
+content_shape: mixed
+responsiveness: reflow
+constraints: Uses only local class hooks and explicit layout constraints.
+scroll_ownership: No internal scroll container.
+source_lineage: https://carbondesignsystem.com/elements/2x-grid/overview/
+lifecycle: generated
+generated_from: scripts/generate-patterns.mjs, scripts/pattern-data.mjs
+---
+
+<!-- Generated from `scripts/generate-patterns.mjs` and `scripts/pattern-data.mjs`. Do not hand-edit generated catalog or pattern docs; edit the source files and regenerate. -->
+
+# panel-layout
+
+## When To Use
+
+Use this pattern when you need to create predictable main and utility panels.
+
+## HTML
+
+```html
+<section class="panel_layout" aria-label="Console workspace">
+    <main class="panel_layout_main">Query editor</main>
+    <aside class="panel_layout_side">Execution history</aside>
+</section>
+```
+
+## CSS
+
+```css
+.panel_layout {
+    display: grid;
+    gap: 1rem;
+    grid-template-columns: repeat(auto-fit, minmax(min(22rem, 100%), 1fr));
+}
+
+.panel_layout_main {
+    min-inline-size: 0;
+}
+
+.panel_layout_side {
+    min-inline-size: 0;
+}
+```
+
+## Core Properties
+
+- `display`, `gap`, `grid-template-columns`, `min-inline-size` define the spatial behavior for this pattern.
+
+## Properties That Break The Layout If Removed
+
+- Removing `display`, `gap`, `grid-template-columns`, `min-inline-size` changes the pattern from its documented layout responsibility back toward ordinary flow or an unsafe fixed arrangement.
+
+## Constraints And Change Points
+
+- reflow responsiveness is part of the contract; change sizing values only when the new minimum, maximum, or wrap point is documented with the pattern.
+- Keep the HTML class hooks and CSS selectors in one-to-one agreement.
+
+## Scroll Ownership
+
+No internal scroll container.
+
+## Accessibility And Source Order Notes
+
+- Semantic role expectation: Preserve the HTML sample's landmark, list, navigation, form, figure, or article roles; layout classes must not replace semantic elements.
+- DOM order expectation: Keep semantic elements, DOM order, reading order, and focus order independent from the visual placement created by the layout classes.
+- Focus risk: Any interactive descendants follow DOM order; do not use this pattern to create a visual order that keyboard focus cannot follow.
+- Scroll expectation: No internal scroll container.
+- Cognitive risk: Medium: reflow can change spatial adjacency, so labels, controls, and related content must remain adjacent in DOM order.
+
+## Browser And Fallback Notes
+
+The CSS uses modern grid, flex, intrinsic sizing, logical properties, or positioning. If a target browser cannot support a property, fall back to ordinary block flow before adding decorative or script-driven layout behavior.
+
+## Composition Notes
+
+Use `panel_layout` as the stable pattern root and compose additional layout behavior outside that root unless the child class is part of the documented relationship.
+
+## Anti-patterns
+
+- Do not add color, border, shadow, typography, or animation rules to reusable pattern CSS.
+- Do not use this pattern to repair unclear HTML structure; make the DOM roles legible first.
+
+## IA Navigation
+
+Parent: [Viewport / Shell patterns](index.md) in [Pattern Categories](../index.md).
+Next: [Layout Recipes](../../recipes/index.md) for screen-level composition, or return to the [Layout Pattern Catalog](../../CATALOG.md) when choosing another primitive.

package/patterns/viewport-shell/scroll-body-shell.md

@@ -0,0 +1,93 @@
+---
+type: Layout Pattern
+name: scroll-body-shell
+title: scroll-body-shell
+category: Viewport / Shell
+description: Keep shell regions fixed while only the body scrolls.
+primary_spatial_problem: Keep shell regions fixed while only the body scrolls.
+secondary_spatial_problems: none
+layout_axis: block
+content_shape: mixed
+responsiveness: fluid
+constraints: Uses only local class hooks and explicit layout constraints.
+scroll_ownership: Pattern owns the named scroll container.
+source_lineage: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/overflow
+lifecycle: generated
+generated_from: scripts/generate-patterns.mjs, scripts/pattern-data.mjs
+---
+
+<!-- Generated from `scripts/generate-patterns.mjs` and `scripts/pattern-data.mjs`. Do not hand-edit generated catalog or pattern docs; edit the source files and regenerate. -->
+
+# scroll-body-shell
+
+## When To Use
+
+Use this pattern when you need to keep shell regions fixed while only the body scrolls.
+
+## HTML
+
+```html
+<section class="scroll_body_shell" aria-label="Inbox">
+    <header>Inbox filters</header>
+    <main class="scroll_body_shell_body">Message list owns vertical scrolling</main>
+    <footer>Selected message actions</footer>
+</section>
+```
+
+## CSS
+
+```css
+.scroll_body_shell {
+    display: grid;
+    grid-template-rows: auto minmax(0, 1fr) auto;
+    max-block-size: 100dvh;
+}
+
+.scroll_body_shell_body {
+    min-block-size: 0;
+    overflow: auto;
+}
+```
+
+## Core Properties
+
+- `display`, `grid-template-rows`, `max-block-size`, `min-block-size`, `overflow` define the spatial behavior for this pattern.
+
+## Properties That Break The Layout If Removed
+
+- Removing `display`, `grid-template-rows`, `max-block-size`, `min-block-size`, `overflow` changes the pattern from its documented layout responsibility back toward ordinary flow or an unsafe fixed arrangement.
+
+## Constraints And Change Points
+
+- fluid responsiveness is part of the contract; change sizing values only when the new minimum, maximum, or wrap point is documented with the pattern.
+- Keep the HTML class hooks and CSS selectors in one-to-one agreement.
+
+## Scroll Ownership
+
+Pattern owns the named scroll container.
+
+## Accessibility And Source Order Notes
+
+- Semantic role expectation: Preserve the HTML sample's landmark, list, navigation, form, figure, or article roles; layout classes must not replace semantic elements.
+- DOM order expectation: Keep semantic elements, DOM order, reading order, and focus order independent from the visual placement created by the layout classes.
+- Focus risk: Any interactive descendants follow DOM order; do not use this pattern to create a visual order that keyboard focus cannot follow.
+- Scroll expectation: Pattern owns the named scroll container.
+- Cognitive risk: Medium: scroll ownership can hide context, controls, or return points if it is not named in the consuming layout.
+
+## Browser And Fallback Notes
+
+The CSS uses modern grid, flex, intrinsic sizing, logical properties, or positioning. If a target browser cannot support a property, fall back to ordinary block flow before adding decorative or script-driven layout behavior.
+
+## Composition Notes
+
+Use `scroll_body_shell` as the stable pattern root and compose additional layout behavior outside that root unless the child class is part of the documented relationship.
+
+## Anti-patterns
+
+- Do not add color, border, shadow, typography, or animation rules to reusable pattern CSS.
+- Do not use this pattern to repair unclear HTML structure; make the DOM roles legible first.
+
+## IA Navigation
+
+Parent: [Viewport / Shell patterns](index.md) in [Pattern Categories](../index.md).
+Next: [Layout Recipes](../../recipes/index.md) for screen-level composition, or return to the [Layout Pattern Catalog](../../CATALOG.md) when choosing another primitive.

package/patterns/viewport-shell/sticky-footer.md

@@ -0,0 +1,92 @@
+---
+type: Layout Pattern
+name: sticky-footer
+title: sticky-footer
+category: Viewport / Shell
+description: Keep footer at the bottom when content is short.
+primary_spatial_problem: Keep footer at the bottom when content is short.
+secondary_spatial_problems: none
+layout_axis: block
+content_shape: mixed
+responsiveness: fluid
+constraints: Uses only local class hooks and explicit layout constraints.
+scroll_ownership: No internal scroll container.
+source_lineage: https://developer.mozilla.org/en-US/docs/Web/CSS/How_to/Layout_cookbook
+lifecycle: generated
+generated_from: scripts/generate-patterns.mjs, scripts/pattern-data.mjs
+---
+
+<!-- Generated from `scripts/generate-patterns.mjs` and `scripts/pattern-data.mjs`. Do not hand-edit generated catalog or pattern docs; edit the source files and regenerate. -->
+
+# sticky-footer
+
+## When To Use
+
+Use this pattern when you need to keep footer at the bottom when content is short.
+
+## HTML
+
+```html
+<section class="sticky_footer" aria-label="Account setup">
+    <header>Account setup</header>
+    <main class="sticky_footer_main">Profile fields and preferences</main>
+    <footer><button>Save profile</button></footer>
+</section>
+```
+
+## CSS
+
+```css
+.sticky_footer {
+    display: grid;
+    grid-template-rows: auto 1fr auto;
+    min-block-size: 100dvh;
+}
+
+.sticky_footer_main {
+    min-block-size: 0;
+}
+```
+
+## Core Properties
+
+- `display`, `grid-template-rows`, `min-block-size` define the spatial behavior for this pattern.
+
+## Properties That Break The Layout If Removed
+
+- Removing `display`, `grid-template-rows`, `min-block-size` changes the pattern from its documented layout responsibility back toward ordinary flow or an unsafe fixed arrangement.
+
+## Constraints And Change Points
+
+- fluid responsiveness is part of the contract; change sizing values only when the new minimum, maximum, or wrap point is documented with the pattern.
+- Keep the HTML class hooks and CSS selectors in one-to-one agreement.
+
+## Scroll Ownership
+
+No internal scroll container.
+
+## Accessibility And Source Order Notes
+
+- Semantic role expectation: Preserve the HTML sample's landmark, list, navigation, form, figure, or article roles; layout classes must not replace semantic elements.
+- DOM order expectation: Keep semantic elements, DOM order, reading order, and focus order independent from the visual placement created by the layout classes.
+- Focus risk: Any interactive descendants follow DOM order; do not use this pattern to create a visual order that keyboard focus cannot follow.
+- Scroll expectation: No internal scroll container.
+- Cognitive risk: Low: the pattern should preserve ordinary reading flow when semantic order is already correct.
+
+## Browser And Fallback Notes
+
+The CSS uses modern grid, flex, intrinsic sizing, logical properties, or positioning. If a target browser cannot support a property, fall back to ordinary block flow before adding decorative or script-driven layout behavior.
+
+## Composition Notes
+
+Use `sticky_footer` as the stable pattern root and compose additional layout behavior outside that root unless the child class is part of the documented relationship.
+
+## Anti-patterns
+
+- Do not add color, border, shadow, typography, or animation rules to reusable pattern CSS.
+- Do not use this pattern to repair unclear HTML structure; make the DOM roles legible first.
+
+## IA Navigation
+
+Parent: [Viewport / Shell patterns](index.md) in [Pattern Categories](../index.md).
+Next: [Layout Recipes](../../recipes/index.md) for screen-level composition, or return to the [Layout Pattern Catalog](../../CATALOG.md) when choosing another primitive.

package/patterns/viewport-shell/sticky-header.md

@@ -0,0 +1,86 @@
+---
+type: Layout Pattern
+name: sticky-header
+title: sticky-header
+category: Viewport / Shell
+description: Keep a header visible above a scrolling content region.
+primary_spatial_problem: Keep a header visible above a scrolling content region.
+secondary_spatial_problems: none
+layout_axis: block
+content_shape: mixed
+responsiveness: fluid
+constraints: Uses only local class hooks and explicit layout constraints.
+scroll_ownership: No internal scroll container.
+source_lineage: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/position
+lifecycle: generated
+generated_from: scripts/generate-patterns.mjs, scripts/pattern-data.mjs
+---
+
+<!-- Generated from `scripts/generate-patterns.mjs` and `scripts/pattern-data.mjs`. Do not hand-edit generated catalog or pattern docs; edit the source files and regenerate. -->
+
+# sticky-header
+
+## When To Use
+
+Use this pattern when you need to keep a header visible above a scrolling content region.
+
+## HTML
+
+```html
+<header class="sticky_header">
+    <nav aria-label="Repository"><a href="#">Code</a><a href="#">Issues</a><a href="#">Pull requests</a></nav>
+</header>
+```
+
+## CSS
+
+```css
+.sticky_header {
+    inset-block-start: 0;
+    position: sticky;
+    z-index: 1;
+}
+```
+
+## Core Properties
+
+- `inset-block-start`, `position`, `z-index` define the spatial behavior for this pattern.
+
+## Properties That Break The Layout If Removed
+
+- Removing `inset-block-start`, `position`, `z-index` changes the pattern from its documented layout responsibility back toward ordinary flow or an unsafe fixed arrangement.
+
+## Constraints And Change Points
+
+- fluid responsiveness is part of the contract; change sizing values only when the new minimum, maximum, or wrap point is documented with the pattern.
+- Keep the HTML class hooks and CSS selectors in one-to-one agreement.
+
+## Scroll Ownership
+
+No internal scroll container.
+
+## Accessibility And Source Order Notes
+
+- Semantic role expectation: Preserve the HTML sample's landmark, list, navigation, form, figure, or article roles; layout classes must not replace semantic elements.
+- DOM order expectation: Keep semantic elements, DOM order, reading order, and focus order independent from the visual placement created by the layout classes.
+- Focus risk: Any interactive descendants follow DOM order; do not use this pattern to create a visual order that keyboard focus cannot follow.
+- Scroll expectation: No internal scroll container.
+- Cognitive risk: Low: the pattern should preserve ordinary reading flow when semantic order is already correct.
+
+## Browser And Fallback Notes
+
+The CSS uses modern grid, flex, intrinsic sizing, logical properties, or positioning. If a target browser cannot support a property, fall back to ordinary block flow before adding decorative or script-driven layout behavior.
+
+## Composition Notes
+
+Use `sticky_header` as the stable pattern root and compose additional layout behavior outside that root unless the child class is part of the documented relationship.
+
+## Anti-patterns
+
+- Do not add color, border, shadow, typography, or animation rules to reusable pattern CSS.
+- Do not use this pattern to repair unclear HTML structure; make the DOM roles legible first.
+
+## IA Navigation
+
+Parent: [Viewport / Shell patterns](index.md) in [Pattern Categories](../index.md).
+Next: [Layout Recipes](../../recipes/index.md) for screen-level composition, or return to the [Layout Pattern Catalog](../../CATALOG.md) when choosing another primitive.

package/platform-guides/apple-interaction.md

@@ -0,0 +1,89 @@
+---
+type: Domain Guide
+title: Apple Interaction As A Comparative Reference
+description: Bounded comparison of Apple interaction themes with explicit web-adaptation and provenance limits.
+domain: platform-guides
+lifecycle: experimental
+source_repository: https://github.com/emilkowalski/skills
+source_path: skills/apple-design/SKILL.md
+source_revision: 220e8607c90b17337d210125777b7b695f26c221
+platform: Apple platforms
+platform_version: verify-current
+reviewed_on: 2026-07-11
+---
+
+# Apple Interaction As A Comparative Reference
+
+Primary role: platform comparison guide.
+
+## Repository Boundary
+
+This page uses selected Apple-platform interaction themes as comparative questions. It does not reproduce Apple guidance, establish affiliation, prescribe imitation, or treat a native implementation value as valid for the web.
+
+Current official Apple documentation is required for Apple-specific claims. Current web standards and browser documentation are required for web adaptation. Local rendered, device, accessibility, and performance evidence is required for product conclusions.
+
+## Reusable Method
+
+For each proposed comparison:
+
+1. Name the user task, platform, OS/API version, input method, and state transition.
+2. Describe the observable behavior without branded terminology.
+3. Identify the platform convention and its current official source.
+4. Separate the reusable interaction question from native implementation details.
+5. Define the web adaptation, including unavailable or materially different capabilities.
+6. Verify the adapted behavior on its real surface and record what remains unproven.
+
+## Comparative Questions
+
+| Theme | Question to investigate | Required evidence | Boundary |
+| --- | --- | --- | --- |
+| Response | Does feedback begin close enough to input to preserve cause and effect? | Interaction recording and input-state trace | No universal latency value is implied. |
+| Direct manipulation | Does the presented state follow, cancel, and resume from user input coherently? | Repeated drag/reversal test on target input modes | One-to-one tracking is not always required. |
+| Interruption | Can new input redirect a transition without jumping or locking control? | Mid-transition retarget and reversal evidence | Springs are one option, not a requirement. |
+| Velocity continuity | Does release-to-settle behavior avoid an observable seam? | Gesture and presented-state recording | Native velocity APIs and web libraries differ. |
+| Spatial consistency | Can the reader understand where content came from and where it returns? | Before/intermediate/after render plus source/focus order | Visual path cannot override semantic order. |
+| Recoverability | Can a user cancel, reverse, undo, or safely recover where the task requires it? | Task and error-path evidence | Confirmation is not universally preferable to undo. |
+| Wayfinding | Can the interface answer location, available destinations, contents, and exit? | Navigation task evidence | Familiar platform placement may not transfer across products. |
+| Soft boundaries | Would progressive resistance communicate a limit better than a hard stop? | Comparative prototype and input/device evidence | The resistance curve is not standardized across platforms. |
+| Multimodal feedback | Do visual, audio, and haptic cues share a clear cause and useful purpose? | Device timing and accessibility evidence | Web haptics/audio are not native equivalents and may be unavailable. |
+| Adaptive presentation | Does the interface remain usable across text size, contrast, transparency, motion preference, input, and viewport changes? | Relevant preference and constraint matrix | A platform feature name does not prove web accessibility. |
+
+## Opinionated Guidance
+
+Momentum-aware settling, source-anchored transitions, progressive boundary resistance, and carefully coordinated feedback can be useful hypotheses for directly manipulated interfaces. Translucent materials, system typography, haptics, and visual delight are product and platform choices outside reusable Layout pattern CSS.
+
+## Platform-Specific Guidance
+
+- iOS/macOS gesture physics, native spring APIs, Dynamic Type, system materials, haptics, and SwiftUI/UIKit behavior must be labeled as Apple-specific.
+- Any value described as shipped by Apple requires a direct, current official source and version.
+- A web mapping must identify browser support, input differences, accessibility behavior, and fallback semantics.
+- `backdrop-filter`, the Vibration API, web media queries, and JavaScript animation libraries are not equivalents merely because they can approximate one visible effect.
+
+## Unsupported Absolutes
+
+- Do not call an upstream formula or parameter an exact Apple implementation without a primary official source.
+- Do not require direct manipulation to track one-to-one in every context.
+- Do not require audio and haptic events on one exact frame as a universal web contract.
+- Do not claim translucent chrome is generally superior to opaque structure.
+- Do not adopt a single spring configuration as a safe default across tasks.
+- Do not import a named set of Apple principles as StyleGallery's shared principles.
+- Do not infer native behavior, platform affiliation, or accessibility from visual similarity.
+
+## Verification Contract
+
+Record the official platform source and version, the web-standard or browser source for adaptation, the exact target devices and input modes, relevant user preferences, and the observed pass/fail behavior. Use a real interactive prototype for interaction claims. State explicitly when native behavior cannot be reproduced or verified on the web.
+
+Review this page when Apple changes the cited convention, the web platform changes the adaptation surface, the source revision changes, or local testing contradicts the guidance. `platform_version: verify-current` prevents this experimental page from masquerading as a version-pinned platform contract.
+
+## Source, License, And Attribution
+
+- Upstream inspiration: [apple-design/SKILL.md](https://github.com/emilkowalski/skills/blob/220e8607c90b17337d210125777b7b695f26c221/skills/apple-design/SKILL.md)
+- Snapshot: `220e8607c90b17337d210125777b7b695f26c221`
+- Upstream license: MIT, Copyright (c) 2026 Emil Kowalski.
+- Reuse form: independent method rewrite; upstream prose, tables, code, exact-value sequences, Apple/WWDC-derived expression, and quotations were not retained.
+- Evidence boundary: the upstream artifact is a practitioner interpretation and provenance record, not an official Apple or web-platform source.
+
+## IA Navigation
+
+Parent: [Platform Guides](index.md).
+Next: [Layout](../layout/index.md).