# How to Determine if a Website Section Is Driven by Clicks, Scrolling, or Time

> Discover how to determine if a website section is driven by clicks, scrolling, or time. Learn to inspect UI triggers and document thresholds for effective cloning.

- Repository: [JCodesMore/ai-website-cloner-template](https://github.com/JCodesMore/ai-website-cloner-template)
- Tags: how-to-guide
- Published: 2026-07-03

---

**Use a scroll-first inspection workflow to identify whether UI changes trigger on viewport position, user clicks, or automatic timers, then document the specific thresholds and CSS states before writing any clone code.**

Reverse-engineering a website requires understanding whether each section is driven by clicks, scrolling, or time before writing code. The JCodesMore/ai-website-cloner-template repository codifies a systematic approach to classify interactions through deliberate observation and browser-based detection. Misidentifying the interaction type forces a complete rewrite of the logic, making this identification step the most critical phase of any cloning project.

## The Scroll-First Inspection Sequence

According to the [`INSPECTION_GUIDE.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/INSPECTION_GUIDE.md) located in `docs/research/`, the analysis must begin with a **pure scroll pass**. Scroll slowly through the target section and observe any visual changes that occur without clicking. If the UI updates—such as headers shrinking, elements becoming sticky, or parallax layers shifting—this indicates a **scroll-driven** component.

Document the exact mechanism triggering the change. Common triggers include `IntersectionObserver` thresholds (e.g., `rootMargin: "-30% 0px"` with `threshold: 0.5`), CSS scroll-snap points, or custom smooth-scroll libraries like Lenis or Locomotive Scroll (often identified by the `.lenis` class). The [`.opencode/commands/clone-website.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/.opencode/commands/clone-website.md) file emphasizes the "don't click first" rule to prevent incorrect assumptions about interaction models.

## Detecting Click and Hover Interactions

If scrolling produces no visual changes, proceed to test clickable elements. Click buttons, anchors, and tap targets while monitoring for state updates. This identifies **click-driven** or **hover-driven** interactions. Capture the selector that triggered the change (e.g., `.nav-button`) and use `getComputedStyle()` to record the CSS before and after the interaction.

The inspection guide specifies recording the **Interaction Model** as `click-driven` and the **Trigger** as the specific DOM event or class toggle. This data prevents implementing scroll listeners where simple click handlers are required.

## Identifying Time-Based Animations

When UI elements animate automatically after page load without user input, the behavior is **time-driven**. Carousels that advance automatically, fade-in sequences, and delayed reveals fall into this category. Use the browser's Performance tab to measure the exact delay from navigation start to animation beginning.

Record the delay duration (e.g., `500ms after load`) and the animation type, typically CSS keyframes or JavaScript timers (`setTimeout`). The [`.github/skills/clone-website/SKILL.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/.github/skills/clone-website/SKILL.md) file mirrors this instruction for AI-assisted workflows, ensuring time-based triggers are captured before code generation.

## Documenting the Interaction Model

For each section analyzed, create a specification block containing four required fields:

- **Interaction Model**: Classify as `static`, `click-driven`, `scroll-driven`, or `time-driven`
- **Trigger**: Record the scroll position in pixels, `IntersectionObserver` configuration, CSS class name, or timer duration
- **Before/After Styles**: Capture computed CSS values at each state using `getComputedStyle()`
- **Implementation Approach**: Decide between CSS transitions, `IntersectionObserver`, scroll listeners, or CSS animation-timeline

Store this specification in the component's markdown or JSON file. This documentation feeds directly into the implementation phase in [`src/app/page.tsx`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/src/app/page.tsx), where the cloned component will be constructed.

## Automated Detection with JavaScript

While manual inspection provides the definitive classification, these browser console scripts from the clone-website command files accelerate the detection process.

### Detect Scroll-Driven Changes

Run this snippet to identify elements reacting to scroll position via `IntersectionObserver`:

```javascript
// Replace '#my-section' with your target selector
const target = document.querySelector('#my-section');
let before = getComputedStyle(target).opacity;

const observer = new IntersectionObserver(entries => {
  entries.forEach(entry => {
    const after = getComputedStyle(entry.target).opacity;
    if (before !== after) {
      console.log('Scroll-driven change detected:', {
        before,
        after,
        scrollY: window.scrollY,
        intersectionRatio: entry.intersectionRatio,
      });
    }
    before = after;
  });
}, { threshold: [0, 0.5, 1] });

observer.observe(target);

```

When the console logs a change, the element's visual state depends on scrolling. Record the `intersectionRatio` and `scrollY` values for the specification.

### Detect Click-Driven Interactions

Attach listeners to interactive elements to capture click-based state changes:

```javascript
document.querySelectorAll('button, a, [role="button"]').forEach(btn => {
  const before = getComputedStyle(btn).backgroundColor;
  btn.addEventListener('click', () => {
    const after = getComputedStyle(btn).backgroundColor;
    if (before !== after) {
      console.log('Click-driven change on', btn, {
        before,
        after,
      });
    }
  }, { once: true });
});

```

This confirms the UI is click-driven when console output appears after interaction.

### Detect Time-Driven Animations

Identify automatically starting animations by checking for CSS animation properties:

```javascript
document.querySelectorAll('*').forEach(el => {
  const style = getComputedStyle(el);
  if (style.animationName !== 'none') {
    console.log('Time-based animation found on', el, {
      animationName: style.animationName,
      duration: style.animationDuration,
    });
  }
});

```

Elements with non-`none` `animation-name` values are typically time-driven. Combine this with `performance.timing` to capture the exact start delay relative to page load.

## Implementation Context

When reproducing the detected behaviors, reference [`src/lib/utils.ts`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/src/lib/utils.ts) for the `cn()` helper function. This utility merges computed CSS classes concisely, matching the utility patterns found in the original site's class toggling logic.

## Summary

- **Always scroll first** to identify scroll-driven interactions before testing clicks, as mandated in [`docs/research/INSPECTION_GUIDE.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/docs/research/INSPECTION_GUIDE.md).
- **Document four critical fields** for each section: Interaction Model, Trigger, Before/After Styles, and Implementation Approach.
- **Use `IntersectionObserver`** for scroll detection rather than expensive scroll listeners when possible.
- **Capture computed styles** with `getComputedStyle()` to ensure the clone matches the original visual states exactly.
- **Reference the repository's command files** at [`.opencode/commands/clone-website.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/.opencode/commands/clone-website.md) and [`.github/skills/clone-website/SKILL.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/.github/skills/clone-website/SKILL.md) for the complete workflow specification.

## Frequently Asked Questions

### How do I distinguish between scroll-driven and parallax effects?

Parallax effects are a subset of scroll-driven interactions. If the element moves at a different rate than the scroll (slower or faster), it is scroll-driven with a transform calculation based on scroll position. Use the IntersectionObserver snippet to confirm the dependency on viewport position, then check if the element uses `transform: translateY()` values that update continuously during scroll rather than at discrete thresholds.

### What if an element responds to both clicks and scroll events?

Hybrid interactions require documenting both triggers separately. Classify the primary interaction model based on which trigger initiates the main state change, but note the secondary trigger in the Implementation Approach field. For example, a sticky header that shrinks on scroll but expands on click would list `scroll-driven` as the model with a note that click events override the scroll state.

### Can I automate the entire detection process?

While the JavaScript snippets provide automated detection for simple cases, complex interactions involving custom event emitters or third-party libraries like Lenis require manual inspection. The `clone-website` command files recommend combining automated detection with visual verification to catch edge cases that scripts might miss, such as delegated events or Shadow DOM encapsulated behaviors.

### Why does the inspection guide emphasize "don't click first"?

Clicking prematurely can trigger state changes that mask scroll behaviors. For example, clicking a navigation item might scroll the page automatically, making it appear scroll-driven when it is actually click-driven. By observing scroll behavior in isolation first, you establish the baseline interaction model before introducing click events that might modify the viewport position.