Revisit Interact ruels by ydaniv · Pull Request #159 · wix/interact

ydaniv · 2026-03-15T10:17:46Z

Description

Refactor hover.md
Refactor click.md
Refactor viewprogress.md
Refactor viewenter.md
Refactor pointermove.md
Refactor integration.md
Removed ~~scroll-list.md~~
Refactor full-lean.md

ameerabuf

I agree with the direction, and it does seem to be the same information in much less text, but I do not feel comfortable removing so much without first testing to see there is no regression. We can use Monty's QA-flow on this branch or something like this...

Added customEffect rules to hover and click; Fixes to viewprogress.md

Added missing composite effect property in types

Added TOCs

ameerabuf

read click and hover. There were already quite a few comments, some are critical IMO, so I submit now and I will continue with the other triggers.

packages/interact/rules/click.md

packages/interact/rules/hover.md

ameerabuf · 2026-03-18T15:45:33Z

packages/interact/rules/hover.md

+        duration: [DURATION_MS],
+        easing: '[EASING_FUNCTION]',
+        fill: '[FILL_MODE]',
        keyframeEffect: {


namedEffect?

added a comment

I don't think the comment is enough' it just creates a contradiction between the template and the text. Why not the same as in the first rule? maybe shorten it something like

// One of: keyframeEffect: [KEYFRAME_EFFECT_DEF], // Or namedEffect: [NAMED_EFFECT_DEF],

ameerabuf · 2026-03-18T15:47:13Z

packages/interact/rules/hover.md

+- `[SOURCE_KEY]` — same as Rule 1.
+- `[POINTER_TYPE]` — same as Rule 1.
+- `[OFFSET_MS]` — time offset between each child's animation start, in milliseconds.
+- `[OFFSET_EASING]` — easing curve for the stagger distribution (e.g. `'sineOut'`, `'linear'`).


same comment about the different easing format

is it? there is still does not reference motion like the others

packages/interact/rules/viewenter.md

ameerabuf · 2026-03-18T16:13:48Z

packages/interact/rules/viewenter.md

+    {
+      key: 'hero',
+      trigger: 'viewEnter',
+      params: { type: 'once', threshold: 0.2 },


I think we should keep the properties that are not fixed-value templated like in the rules (like threshold, duration, namedEffect), or with placeholder syntax like threshold: <threshold> instead of fixed values

I think that you might not have pushed this fix then

packages/interact/rules/viewenter.md

packages/interact/rules/viewprogress.md

ameerabuf · 2026-03-18T16:59:50Z

packages/interact/rules/viewprogress.md

-                    { opacity: '0', transform: 'translateY(-40px)' }
-                ]
+            key: '[TARGET_KEY]',
+            customEffect: (element: Element, progress: number) => {


let's at least make this whole rule match the time-based structure of the customEffect rule

Not following, looks fine

there it is simply customEffect: [CUSTOM_EFFECT_CALLBACK] and the signature and explanation are in the variables section. There are many such mismatches everywhere since we insist on not pulling/copying it from a single source of truth

packages/interact/rules/viewprogress.md

packages/interact/rules/pointermove.md

ameerabuf · 2026-03-18T17:33:50Z

packages/interact/rules/pointermove.md

+- `hitArea` — determines where mouse movement is tracked:
+  - `'self'` — tracks mouse within the source element's bounds only. Use for local hover effects.
+  - `'root'` — tracks mouse anywhere in the viewport. Use for global cursor followers, ambient effects.
+- `axis` — restricts pointer tracking to a single axis. Only relevant when using `keyframeEffect`:


is it really though? Do we know to ignore it with other types of effects?

packages/interact/rules/integration.md

packages/interact/rules/full-lean.md

ameerabuf · 2026-03-24T12:30:42Z

packages/interact/rules/click.md

- For controlling ongoing animations
- When users should be able to interrupt and resume animations
- For interactive media controls
+**CRITICAL:** Always include `fill: 'both'` for `type: 'alternate'` or `'repeat'` — keeps the effect applied while finished and prevents garbage-collection, allowing efficient toggling. For `type: 'once'`, use `fill: 'backwards'` or `fill: 'none'`.


For type: 'once', use fill: 'backwards' or fill: 'none' - could create bugs. Directing AI to use fill: 'none' on such animation could cause flickering. Also why not use fill: 'both'?
I think a sentence about the initial styling of the target element and how it corresponds to what fill-value to use might be more accurate here

If you use fill: both you prevent the animation from being GC'd.
Maybe we should set it to backwards for now

ameerabuf · 2026-03-24T12:31:29Z

packages/interact/rules/click.md

+**CRITICAL:** Always include `fill: 'both'` for `type: 'alternate'` or `'repeat'` — keeps the effect applied while finished and prevents garbage-collection, allowing efficient toggling. For `type: 'once'`, use `fill: 'backwards'` or `fill: 'none'`.

-**Pattern**:
+**Multiple effects:** The `effects` array can contain multiple effects — all share the same click trigger and fire together. Use this to animate different targets from a single click event.


Another example of something that is true for all trigger-types

yes, this was added later when I thought that the model isn't using this feature. Let's remove and keep the comment below

ameerabuf · 2026-03-24T12:36:55Z

packages/interact/rules/click.md

-}
-```
+- `[SOURCE_KEY]` — identifier matching the element's key (`data-interact-key` for web, `interactKey` for React). The element that listens for clicks.
+- `[TARGET_KEY]` — identifier matching the element's key on the element that animates. Same as `[SOURCE_KEY]` for self-targeting, or different for cross-targeting.


I think the second sentence is unnecessary. A more informative sentence for usage would be empty (undefined) to target the same element as the source or a different key for targeting another element.
Currently it just states something trivial, while in my suggestion it at least gives information about the syntax.

ameerabuf · 2026-03-24T12:39:36Z

packages/interact/rules/click.md

+- `[SOURCE_KEY]` — identifier matching the element's key (`data-interact-key` for web, `interactKey` for React). The element that listens for clicks.
+- `[TARGET_KEY]` — identifier matching the element's key on the element that animates. Same as `[SOURCE_KEY]` for self-targeting, or different for cross-targeting.
+- `[EVENT_TRIGGER_TYPE]` — `PointerTriggerParams.type`. One of:
+  - `'alternate'` — plays forward on first click, reverses on next click. Most common for toggles.


plays backwards on next click, and so on? Just a suggestion, maybe not that important

No, it's intentional. First trigger is play() and then it's reverse(). Think reversing a reversed animation.

No, it's correct

ameerabuf · 2026-03-24T12:41:48Z

packages/interact/rules/click.md

+  - `'alternate'` — plays forward on first click, reverses on next click. Most common for toggles.
+  - `'repeat'` — restarts the animation from the beginning on each click.
+  - `'once'` — plays once on the first click and never again.
+  - `'state'` — resumes/pauses the animation on each click. Useful for continuous loops (`iterations: Infinity`).


another non-critical suggestion - plays/resumes on first click, pauses on the next click, and so on?

It was corrected once by Claude, I think it's ok this way.

ameerabuf · 2026-03-24T13:20:07Z

packages/interact/rules/click.md

+                // can be `selector` or `listContainer` for multiple effects, or a separate effect definitions with
+                {
+                    // can be an inline Effect, or a reference to an effect defined in top level `effects` map
+                    effectId: '[EFFECT_ID]',
+                    listContainer: '[LIST_CONTAINER_SELECTOR]'
+                }
            ]
        }
    ]
 }
 ```

-**Variables**:
-
- `[OFFSET_MS]`: Stagger offset in ms between consecutive effects (typically 100-200ms)
- `[OFFSET_EASING]`: Easing for stagger distribution — `'linear'`, `'quadIn'`, `'sineOut'`, etc.
- `[EFFECT_ID_N]`: Effect id from the effects registry for each element
- `[TARGET_KEY_N]`: Element key for each target
- Other variables same as Rule 1
-
-**Example - Orchestrated Content Reveal**:
-
-```typescript
-{
-    key: 'reveal-button',
-    trigger: 'click',
-    params: {
-        type: 'alternate'
-    },
-    sequences: [
-        {
-            offset: 150,
-            offsetEasing: 'sineOut',
-            effects: [
-                { effectId: 'heading-entrance', key: 'content-heading' },
-                { effectId: 'body-entrance', key: 'content-body' },
-                { effectId: 'image-entrance', key: 'content-image' }
-            ]
-        }
-    ]
-}
-```
+Each `[EFFECT_ID]` must be defined in the top-level `effects` map of the `InteractConfig`:


this is still very confusing and contradicting - I believe we can allow 2 templates for this rule to be more clear. A template using inline effects, and another using ids. I am not sure what to do about the confusion of the selectors, it might require another template.
I think that there is nothing that is click-specific here, and the better solution is to have sequences.md (possibly sequences-and-lists.md) and define the rules of usage with sequences there. It is not trigger-specific, and could get complicated and breaks because we are trying to minimize the context that explains it.

The idea is not to have in these rules ONLY stuff for this trigger. There is some expected overlap so that each rules file can also be used standalone

ameerabuf · 2026-03-24T13:23:49Z

packages/interact/rules/click.md

+        duration: [DURATION_MS],
+        easing: '[EASING_FUNCTION]',
+        fill: 'both',
+        // keyframeEffect or namedEffect


the comment do not match the object underneath and these kind of things are what confuses the LLM. We can change the object to be more general somehow or include both options with OR like in the first rule.

ameerabuf · 2026-03-24T13:24:51Z

packages/interact/rules/click.md

- Simple state toggles
- CSS custom property updates
+- `[SOURCE_KEY]` / `[EVENT_TRIGGER_TYPE]` — same as Rule 1.
+- `[OFFSET_MS]` — time offset between each child's animation start, in milliseconds.


mention 'stagger' as the LLM seemed to not do that connection by itself.

ameerabuf · 2026-03-24T13:27:29Z

packages/interact/rules/click.md

+- `[OFFSET_MS]` — time offset between each child's animation start, in milliseconds.
+- `[OFFSET_EASING]` — easing curve for the stagger distribution.


This is not a standard interface. I think a few words about how the delay is calculated should be here

It's standard in other animation libraries, but improved a bit

ameerabuf · 2026-03-24T13:28:02Z

packages/interact/rules/click.md

+- `[OFFSET_MS]` — time offset between each child's animation start, in milliseconds.
+- `[OFFSET_EASING]` — easing curve for the stagger distribution.
+- `[EFFECT_ID]` — string key referencing an entry in the top-level `effects` map. Same concept as `[UNIQUE_EFFECT_ID]` in Rule 1.
+- `[LIST_CONTAINER_SELECTOR]` — CSS selector for the container whose direct children will be staggered.


and here is our problem - not given as optional.

Maybe we should just replace the whole object with a single placeholder that implies to just use an effect

ameerabuf · 2026-03-24T13:43:31Z

packages/interact/rules/hover.md


-**Pattern**:
+- `[SOURCE_KEY]` (interaction `key`) — a stable wrapper element that receives the mouse events.
+- `[TARGET_KEY]` (effect `key` or `selector`) — the inner element that actually animates.


or selector?

Oh I understand what you mean but that is not so clear from the sentence. You mean that targeting a different element could be used be either giving a different key to the effect or no key and a selector that target an inner element. This is not clear from that sentence and rather seems like there is a single variable TARGET_KEY that could either be a key or a selector and that does not work with the templates below.
I can imagine a scenario of an agent just placing selectors in the key field due to that.

OK, rephrased

ameerabuf · 2026-03-24T13:57:04Z

packages/interact/rules/hover.md

+Use `keyframeEffect` or `namedEffect` when the hover should play an animation (CSS or WAAPI). Pair with `PointerTriggerParams` to control playback behavior.

-**Purpose**: Hover interactions that play forward on mouse enter and reverse on mouse leave (`type: 'alternate'`).
+**CRITICAL:** Always include `fill: 'both'` for `type: 'alternate'`, `'repeat'` — keeps the effect applied while hovering and prevents garbage-collection. For `type: 'once'`, use `fill: 'backwards'` or `fill: 'none'`.


I might be missing something but - type: 'once'+fill: 'none' can only work if the animation's first and last frames are the same and basically apply no transformations? I cannot see how there is no "jump" in any other case

ameerabuf · 2026-03-24T13:59:11Z

packages/interact/rules/hover.md

+            iterations: [ITERATIONS],
+            alternate: [ALTERNATE_BOOL]
+        },
+        // additional effects targeting other elements can be added here


might be a nit-pick for now, but could also be additional effects on the same target for composition, but maybe leave it like that for now

ameerabuf · 2026-03-24T14:03:00Z

packages/interact/rules/hover.md

+  - `'remove'` — removes a previously applied style state on enter.
+  - `'clear'` — clears all previously applied style states on enter. Useful for resetting multiple stacked style state changes at once.


Also here I think the use-case should be made clear

ameerabuf · 2026-03-24T14:04:16Z

packages/interact/rules/hover.md


-**Purpose**: Hover interactions that stagger animations across multiple targets using a sequence instead of manual delays.
+- `[SOURCE_KEY]` / `[TARGET_KEY]` / `[EVENT_TRIGGER_TYPE]` — same as Rule 1.
+- `[CUSTOM_EFFECT_CALLBACK]` — function with signature `(element: HTMLElement, progress: number) => void`. Called on each animation frame with `progress` from 0 to 1.


target element (not source).
Maybe we could just do (target: HTMLElement, progress: number) => void

ameerabuf · 2026-03-24T14:07:26Z

packages/interact/rules/hover.md

+        duration: [DURATION_MS],
+        easing: '[EASING_FUNCTION]',
+        fill: '[FILL_MODE]',
        keyframeEffect: {


I don't think the comment is enough' it just creates a contradiction between the template and the text. Why not the same as in the first rule? maybe shorten it something like

// One of: keyframeEffect: [KEYFRAME_EFFECT_DEF], // Or namedEffect: [NAMED_EFFECT_DEF],

ameerabuf · 2026-03-24T14:10:01Z

packages/interact/rules/hover.md

+- `[SOURCE_KEY]` — same as Rule 1.
+- `[POINTER_TYPE]` — same as Rule 1.
+- `[OFFSET_MS]` — time offset between each child's animation start, in milliseconds.
+- `[OFFSET_EASING]` — easing curve for the stagger distribution (e.g. `'sineOut'`, `'linear'`).


is it? there is still does not reference motion like the others

ameerabuf · 2026-03-24T14:11:05Z

packages/interact/rules/hover.md

+- `[OFFSET_MS]` — time offset between each child's animation start, in milliseconds.
+- `[OFFSET_EASING]` — easing curve for the stagger distribution (e.g. `'sineOut'`, `'linear'`).
+- `[EFFECT_ID]` — string key referencing an entry in the top-level `effects` map. Same concept as `[UNIQUE_EFFECT_ID]` in Rule 1.
+- `[LIST_CONTAINER_SELECTOR]` — CSS selector for the container whose direct children will be staggered.


again - optional. And the way to use sequence without it is not clear from this rule

ameerabuf · 2026-03-24T14:17:52Z

packages/interact/rules/pointermove.md


-### Hit Area Configuration (`hitArea`)
+- The source element **MUST NOT** have `pointer-events: none` — it needs to receive pointer events.
+- **MUST AVOID** using the same element as both source and target with effects that change size or position (e.g. `transform: translate(…)`, `scale(…)`). The transform shifts the hit area, causing jittery re-entry cycles. Instead, use `selector` to target a child element for the animation.


This is a much more clear explanation of how to use selector maybe copy some of it to hover?

ameerabuf · 2026-03-24T14:20:04Z

packages/interact/rules/pointermove.md

+- `axis` — restricts pointer tracking to a single axis. Only relevant when using `keyframeEffect`:
+  - `'x'` — maps horizontal pointer position to 0–1 progress for keyframe interpolation.
+  - `'y'` — maps vertical pointer position to 0–1 progress for keyframe interpolation. **Default** when `keyframeEffect` is used.
+  - When omitted with `namedEffect` or `customEffect`, both axes are available via the 2D progress object.


Does it have to be ommited? what happens if namedEffect or customEffect are used with axis? is it ignored?

ameerabuf · 2026-03-24T14:25:23Z

packages/interact/rules/pointermove.md

---
-
-## Rule 9: Multi-Element Custom Parallax with customEffect
+For devices with dynamic viewport sizes (e.g. mobile browsers where the address bar collapses), consider using viewport-relative units carefully and prefer `lvh`/`svh` over `dvh` unless dynamic viewport behavior is specifically desired.


I guess Claude did not entirely understand me there, though this is also not a bad advice for keyframeEffects here. This was meant to be added in viewProgress.md in a section parallel to this one (## Device Conditions).

ameerabuf · 2026-03-24T14:28:51Z

packages/interact/rules/pointermove.md

+- `[SOURCE_KEY]` — identifier matching the element's key (`data-interact-key` for web, `interactKey` for React). The element that tracks mouse movement.
+- `[TARGET_KEY]` — identifier matching the element's key on the element to animate. Can be the same as source, or different when separating hit area from animation target.
+- `[HIT_AREA]` — `'self'` (mouse within source element) or `'root'` (mouse anywhere in viewport).
+- `[NAMED_EFFECT_TYPE]` — preset name from `@wix/motion-presets` mouse category:


wow this is extensive and unlike the other triggers. I guess Claude misunderstood my comment above too. This seems like an overkill - let's reference to motion-presets if that is what we are intending to go with. If not, let's put such a list for every trigger.

ameerabuf · 2026-03-24T14:30:32Z

packages/interact/rules/pointermove.md

+  - Refer to motion-presets rules for detailed options of each preset. Do NOT guess preset option names/types; omit unknown options and rely on defaults.
+- `[CENTERED_TO_TARGET]` — `true` or `false`. See **Centering with `centeredToTarget`** above.
+- `[TRANSITION_DURATION_MS]` — optional. Milliseconds for smoothing between progress updates. Adds inertia to the effect.
+- `[TRANSITION_EASING]` — optional. Easing for the smoothing transition (e.g., `'easeOut'`). Adds a natural deceleration feel.


format of the easing should be clear. If it follows some standard easing names, reference this standard.

ameerabuf · 2026-03-24T15:09:45Z

packages/interact/rules/viewprogress.md

-                const visibleText = text.substring(0, visibleLength);
-                element.textContent = visibleText + (progress < 1 ? '|' : '');
+- `[SOURCE_KEY]` — identifier matching the element's key (`data-interact-key` for web, `interactKey` for React). The element whose scroll position drives the animation.
+- `[TARGET_KEY]` — identifier matching the element's key on the element to animate (can be same as source or different).


suddenly no word about data-interact-key, interactKey (+1 for single unified variables JSON)

ameerabuf · 2026-03-24T15:11:51Z

packages/interact/rules/viewprogress.md

+  - `'cover'` — full visibility span from first pixel entering to last pixel leaving.
+  - `'entry'` — the phase while the element is entering the viewport.
+  - `'exit'` — the phase while the element is exiting the viewport.
+  - `'contain'` — while the element is fully contained in the viewport. Typically used with a `position: sticky` container.


let's leav it like that for now, but unfortunately it is not as simple as that. Things change here for "tall" elements

ameerabuf · 2026-03-24T15:14:18Z

packages/interact/rules/viewprogress.md

-                    { opacity: '0', transform: 'translateY(-40px)' }
-                ]
+            key: '[TARGET_KEY]',
+            customEffect: (element: Element, progress: number) => {


there it is simply customEffect: [CUSTOM_EFFECT_CALLBACK] and the signature and explanation are in the variables section. There are many such mismatches everywhere since we insist on not pulling/copying it from a single source of truth

ameerabuf · 2026-03-24T15:16:43Z

packages/interact/rules/viewprogress.md

-    key: 'orchestrated-section',
+    key: '[TALL_WRAPPER_KEY]',
    trigger: 'viewProgress',
+    conditions: ['[CONDITION_NAME]'],  // optional


ameerabuf · 2026-03-24T15:17:59Z

packages/interact/rules/viewprogress.md

+            // Use keyframeEffect, namedEffect, or customEffect as in Rules 1–2
+            keyframeEffect: { name: '[EFFECT_NAME]', keyframes: [EFFECT_KEYFRAMES] },


then let's not write a template of a keyframeEffect, it is just confusing

ameerabuf · 2026-03-24T15:55:06Z

packages/interact/rules/integration.md

+  listContainer?: string;          // CSS selector for a list container
+  listItemSelector?: string;       // optional — CSS selector to filter which children of listContainer are selected


A suggestion for future design change - models might get less confuse if these were separated from the rest - something like

listSelectors?: { container: string; item?: string; }

Maybe, I actually wanted to keep it as flat as possible. Also, if it's just 2 properties then not worth it yet. We can consider.

ameerabuf · 2026-03-24T15:59:40Z

packages/interact/rules/integration.md

+**Most common**: Omit `selector`/`listContainer`/`listItemSelector` entirely — the element with the matching key is used as both source and target. Use `selector` to target a child element within the keyed element. Use `listContainer` for staggered sequences across list items.

-Generates critical CSS styles that prevent flash-of-unstyled-content (FOUC) for elements with `viewEnter` entrance animations.
+`listItemSelector` is **optional** — only use it when you need to **filter** which children of `listContainer` participate (e.g. select only `.active` items). When omitted, all immediate children of the `listContainer` are selected.


This is great, I think the rules in the trigger-files that refer to list-selectors should just refer to integration.md instead for context on how it works

I'm trying to avoid chaining files

ameerabuf · 2026-03-24T16:01:34Z

packages/interact/rules/integration.md

+  key: string;                     // REQUIRED — matches data-interact-key / interactKey
+  trigger: TriggerType;            // REQUIRED — trigger type
+  params?: TriggerParams;          // trigger-specific parameters
+  selector?: string;               // CSS selector to refine target within the element


this is confusing - isn't that selector supposed to be on the effect-level? If not, then do all selectors on the interaction-level actually refer to the target and not the source?

ameerabuf · 2026-03-24T16:02:53Z

packages/interact/rules/integration.md

+1. **`listContainer` + `listItemSelector`** — matches only the elements matching `listItemSelector` within the container (filtering).
+2. **`listContainer` only** — targets all immediate children of the container (common case).
+3. **`listContainer` + `selector`** — matches via `querySelector` within each immediate child of the container.
+4. **`selector` only** — matches via `querySelectorAll` within the root element.
+5. **Fallback** — first child of `<interact-element>` (web) or the root element (react/vanilla).


are these on the interaction level used for the target resolving? How does it work with multiple effects on multiple targets?

It's missing separate text for source and target that's used in full-lean. I'll copy from there.

ameerabuf · 2026-03-24T16:06:22Z

packages/interact/rules/integration.md

+| `click`        | Mouse click                            | Same as `hover`                                                                                                                | [click.md](./click.md)               |
+| `interest`     | Accessible hover (hover + focus)       | Same as `hover`                                                                                                                | [hover.md](./hover.md)               |
+| `activate`     | Accessible click (click + Enter/Space) | Same as `click`                                                                                                                | [click.md](./click.md)               |
+| `viewEnter`    | Element enters viewport                | `type?`: same values as hover; `threshold?`: 0–1; `inset?`: CSS length as strin for viewport margin                            | [viewenter.md](./viewenter.md)       |


ameerabuf · 2026-03-24T16:50:38Z

packages/interact/rules/full-lean.md

+The source element is what the trigger attaches to. Resolved in priority order:
+
+1. **`listContainer` + `listItemSelector`** — trigger attaches to each element matching `listItemSelector` within the `listContainer`. Use `listItemSelector` only when you need to **filter** which children participate (e.g. select only `.active` items). If all immediate children should participate, omit `listItemSelector`.
+2. **`listContainer` only** — trigger attaches to each immediate child of the container. This is the common case for lists.
+3. **`listContainer` + `selector`** — trigger attaches to the element found via `querySelector` within each immediate child of the container.
+4. **`selector` only** — trigger attaches to all elements matching `querySelectorAll` within the root `<interact-element>`.
+5. **Fallback** — first child of `<interact-element>` (web) or the root element (react/vanilla).


It speaks here about the source-resolution while in other places the same segment talks about target-resolution. It is unclear whether these apply to the trigger or the target

ameerabuf · 2026-03-24T16:52:27Z

packages/interact/rules/full-lean.md

+The target element is what the effect animates. Resolved in priority order:
+
+1. **`Effect.key`** — the `<interact-element>` with matching `data-interact-key`.
+2. **Registry Effect's `key`** — if the effect is an `EffectRef`, the `key` from the referenced registry entry is used.


suggestion for future design - effects in the registry should not have keys, it makes no sense. If they are reusable effect definitions they should be target-less IMO.

ameerabuf · 2026-03-24T16:53:08Z

packages/interact/rules/full-lean.md

+
+1. **`Effect.key`** — the `<interact-element>` with matching `data-interact-key`.
+2. **Registry Effect's `key`** — if the effect is an `EffectRef`, the `key` from the referenced registry entry is used.
+3. **Fallback to `Interaction.key`** — the source element acts as the target.


to the key or to the resolved source element? (those are not necessarily the same)

ameerabuf · 2026-03-24T16:54:42Z

packages/interact/rules/full-lean.md

+1. **`Effect.key`** — the `<interact-element>` with matching `data-interact-key`.
+2. **Registry Effect's `key`** — if the effect is an `EffectRef`, the `key` from the referenced registry entry is used.
+3. **Fallback to `Interaction.key`** — the source element acts as the target.
+4. After resolving the root target, `selector`, `listContainer`, and `listItemSelector` on the effect further refine which child elements within that target are animated (same priority order as source resolution).


This is the only place it becomes clear that these could exist on both interaction and effect level. We need to find a way to make this general and less confusing

ameerabuf · 2026-03-24T16:55:29Z

packages/interact/rules/full-lean.md

+| `Interact.destroy()`                | Tear down all instances. Call on unmount or route change to prevent memory leaks.                                  |
+| `Interact.forceReducedMotion`       | `boolean` (default: `false`) — force reduced-motion behavior regardless of OS setting.                             |
+| `Interact.allowA11yTriggers`        | `boolean` (default: `false`) — enable accessibility trigger variants (`interest`, `activate`).                     |
+| `Interact.setup(options)`           | Configure global thresholds and observer options for scroll, pointer, and viewEnter systems. Call before `create`. |


what are the options? when should one use it?

ydaniv added 4 commits March 15, 2026 12:15

Revisiti click and hover ruels

2d39973

Remove old plan

67f6708

Purge old plans

5d8c3b9

Purge old spec

83bb5b1

ameerabuf reviewed Mar 15, 2026

View reviewed changes

ydaniv added 9 commits March 15, 2026 16:56

Small fixes

a70ea9b

Revisit viewprogress rules

74a2bf2

Small cleanup

05bb64a

Revisit viewenter.md;

25e2a51

Added customEffect rules to hover and click; Fixes to viewprogress.md

Fixed format

5f6c703

Revisit pointermove rules;

1ac72ae

Added missing composite effect property in types

Revisit integration.md;

d9641cc

Added TOCs

Fixed format

f68aa3a

Revisit full-lean.md and removed scroll-list.md

5fe9bf9

ameerabuf requested changes Mar 18, 2026

View reviewed changes

ameerabuf reviewed Mar 18, 2026

View reviewed changes

packages/interact/rules/full-lean.md Show resolved Hide resolved

ameerabuf requested changes Mar 19, 2026

View reviewed changes

ydaniv added 5 commits March 20, 2026 11:04

Fixed issues from review

3a899d0

Revisit full-lean

b3efd1f

Merge branch 'master' into interact-revisit-rules

daccd3d

Fixes for FOUC, listItemSelector, multiple effects per trigger

58d725c

Fixed format

7dbb831

ameerabuf reviewed Mar 24, 2026

View reviewed changes

		- `[OFFSET_MS]` — time offset between each child's animation start, in milliseconds.
		- `[OFFSET_EASING]` — easing curve for the stagger distribution.

		- `'remove'` — removes a previously applied style state on enter.
		- `'clear'` — clears all previously applied style states on enter. Useful for resetting multiple stacked style state changes at once.

		// Use keyframeEffect, namedEffect, or customEffect as in Rules 1–2
		keyframeEffect: { name: '[EFFECT_NAME]', keyframes: [EFFECT_KEYFRAMES] },

		listContainer?: string; // CSS selector for a list container
		listItemSelector?: string; // optional — CSS selector to filter which children of listContainer are selected

	\| `viewEnter` \| Element enters viewport \| `type?`: same values as hover; `threshold?`: 0–1; `inset?`: CSS length as strin for viewport margin \| [viewenter.md](./viewenter.md) \|
	\| `viewEnter` \| Element enters viewport \| `type?`: same values as hover; `threshold?`: 0–1; `inset?`: CSS length as string for viewport margin \| [viewenter.md](./viewenter.md) \|

Conversation

ydaniv commented Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

ameerabuf left a comment

Choose a reason for hiding this comment

Uh oh!

ameerabuf left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

ydaniv commented Mar 15, 2026 •

edited

Loading