# Scroll areas Human Guide

## What This Is For
Scroll containers inside a layout — panels, drawers, tables, modals with inner overflow — create friction. It gives the agent a clearer input/output frame for conversion optimization: what context to ask for, what decisions to make, and what usable artifact to return.

Use this as a human-readable version of the Scroll areas agent skill. It is meant for marketers, operators, founders, and other non-coders who want the workflow without reading agent-specific implementation instructions.

## When To Use This
- Use this when you need a repeatable process for scroll areas.
- Use this when the task needs judgment, examples, constraints, or a clear output format rather than a one-off prompt.
- Use this when you want to hand an AI assistant enough context to produce a usable marketing artifact.

## When Not To Use This
- Do not use this when you only need a quick factual answer.
- Do not use this when the work depends on private data you cannot share with the assistant.
- Do not use this as a replacement for legal, compliance, financial, or medical review.

## What You Need Before Starting
- The goal or business outcome you want.
- The audience, customer segment, or market context.
- Any source material the assistant should respect, such as notes, briefs, examples, URLs, or brand guidance.
- Constraints such as tone, length, channel, deadline, region, or approval requirements.
- A clear definition of what a good final answer should look like.

## Step-By-Step Workflow
1. State the job clearly: "Use the Scroll areas guide to help me with..."
2. Add context: audience, goal, offer, channel, source material, and constraints.
3. Ask the assistant to identify missing inputs before producing the final output.
4. Have the assistant follow the skill-specific guidance below.
5. Review the result against the final checklist and ask for revisions where needed.

## Skill-Specific Guidance
- Pagination or load-more for long lists
- Collapsible sections (accordion) for long detail panels
- A separate page or route for content that would otherwise fill a scroll area
- Progressive disclosure — show less by default, expand on demand
- **Fixed-height sidebars** with navigation trees longer than the viewport
- **Data tables** where the header must remain visible while rows scroll
- **Chat or log panels** where the stream is continuous and the surrounding layout is fixed
- **Code editors or terminal panes** embedded in a larger application shell
- **No auto-scrolling** that moves the viewport without the user initiating it
- **No scroll hijacking** — do not intercept the native scroll event to animate or pace it artificially
- **Scroll-to on load** is acceptable only when restoring a previous scroll position (e.g. returning to a list after navigating away)
- **Scroll-to for errors or anchors** is acceptable as a response to a user action (submitting a form with errors, clicking a table-of-contents link)

## Decision Points And Nuance
The original skill emphasizes: Avoid Scroll Areas by Default, When a Scroll Area Is Justified, One Axis Only, Always User-Controlled, Scroll Affordance, Review Checklist.

Use these questions to steer the work:
- What is the intended audience or buyer?
- What source material must be preserved?
- What should the assistant optimize for: clarity, persuasion, accuracy, speed, creativity, or conversion?
- What examples represent the desired quality bar?
- What should the assistant avoid?

## Common Mistakes
- Avoid Scroll Areas by Default
- **Data tables** where the header must remain visible while rows scroll
- Never create a scroll container that scrolls on both axes simultaneously. Two-axis scroll is disorienting, hard to control precisely, and nearly unusable on touch devices.
- Scroll must never happen automatically without user intent. Specifically:
- **No scroll hijacking** — do not intercept the native scroll event to animate or pace it artificially
- Users must be able to tell a region is scrollable before they attempt to scroll it.
- [ ] Is `overflow: auto` (two-axis) avoided on all scroll containers?

## Copy-And-Paste Prompt
```text
Use the Scroll areas human guide.

My goal:
[Describe the business outcome]

Audience:
[Describe who this is for]

Context and source material:
[Paste notes, examples, links, or existing copy]

Constraints:
[Tone, length, channel, timeline, must-include items, must-avoid items]

Before producing the final output, ask me for any missing information that would materially improve the result.
```

## Final Checklist
- [ ] The output matches the original goal.
- [ ] The audience and context are reflected in the answer.
- [ ] Important constraints and source material were preserved.
- [ ] The assistant made the relevant decisions explicit.
- [ ] The final artifact is ready to use, review, or hand to the next person.

## Source
This guide was generated from the dembrandt/dembrandt-skills skill entry for `scroll-areas`.

## Source Skill Notes
These notes preserve the nuance from the original skill. Use them as supporting reference when the workflow above feels too generic.

# Scroll Areas

## Avoid Scroll Areas by Default

Scroll containers inside a layout — panels, drawers, tables, modals with inner overflow — create friction. Users must discover that a region scrolls, manage multiple independent scroll positions simultaneously, and context-switch between scroll areas on the same screen.

**Default: let the page scroll.** A single page-level scroll is universally understood and requires no discovery. Before introducing an inner scroll area, ask whether the layout can be restructured so the page itself handles the overflow.

Alternatives to inner scroll:
- Pagination or load-more for long lists
- Collapsible sections (accordion) for long detail panels
- A separate page or route for content that would otherwise fill a scroll area
- Progressive disclosure — show less by default, expand on demand

## When a Scroll Area Is Justified

Some layouts genuinely require inner scroll:

- **Fixed-height sidebars** with navigation trees longer than the viewport
- **Data tables** where the header must remain visible while rows scroll
- **Chat or log panels** where the stream is continuous and the surrounding layout is fixed
- **Code editors or terminal panes** embedded in a larger application shell

In these cases, proceed — but apply the constraints below.

## One Axis Only

Never create a scroll container that scrolls on both axes simultaneously. Two-axis scroll is disorienting, hard to control precisely, and nearly unusable on touch devices.

```css
/* One axis: vertical */
overflow-y: auto;
overflow-x: hidden;

/* One axis: horizontal (e.g. wide table) */
overflow-x: auto;
overflow-y: hidden;

/* Never */
overflow: auto; /* allows both axes */
```

If content requires both axes — e.g. a wide table inside a constrained panel — restructure the layout so the table's horizontal scroll is the only scroll in the view, with the page itself not scrolling at that point.

## Always User-Controlled

Scroll must never happen automatically without user intent. Specifically:

- **No auto-scrolling** that moves the viewport without the user initiating it
- **No scroll hijacking** — do not intercept the native scroll event to animate or pace it artificially
- **Scroll-to on load** is acceptable only when restoring a previous scroll position (e.g. returning to a list after navigating away)
- **Scroll-to for errors or anchors** is acceptable as a response to a user action (submitting a form with errors, clicking a table-of-contents link)

Exception: chat and log panels may auto-scroll to the bottom on new content, but only if the user is already at the bottom. If the user has scrolled up to read, do not force them back down — show a "new messages" indicator instead.

## Scroll Affordance

Users must be able to tell a region is scrollable before they attempt to scroll it.

- Clip content visually at the edge — a partially visible item signals "there is more"
- Use a subtle scrollbar (not `scrollbar-width: none`) so the track is visible
- On touch, a partial item at the edge is the primary affordance — ensure the container does not have `overflow: hidden` on the trailing edge

## Review Checklist

- [ ] Is every inner scroll area genuinely necessary, or can the layout be restructured to use page scroll?
- [ ] Does every scroll container scroll on one axis only?
- [ ] Is `overflow: auto` (two-axis) avoided on all scroll containers?
- [ ] Is scroll always user-initiated — no hijacking, no forced auto-scroll?
- [ ] Is the scrollable region visually apparent (partial content, visible scrollbar)?
- [ ] On touch devices, is scroll smooth and native (`-webkit-overflow-scrolling: touch` or equivalent)?