Editorial layouts: hero backdrops, section dividers, and rhythmic vertical grids. Each column is a segmented string simulation; the pointer plucks the nearest line with optional bleed to neighbors.
Layout (buyer-first):
Columns + responsive tablet/mobile counts
Gap between lines only (first/last lines pin to inset edges)
Inset Left / Right — moves lines inside the full-width component (use Framer frame padding for page spacing)
Min height, line padding, clip bends, stroke, background, entrance stagger
Physics panel: bend amount, pluck intensity, pointer reach, tension, damping, spread, sensitivity, segments.
Production guardrails: useIsOnFramerCanvas, useReducedMotion, useInView, touch capture, SSR-safe resize handling.
Paste Kern_KineticLinesGrid.tsx as a Code Component in Framer.
Set parent frame to Fill width; component defaults to full bleed.
Layout: start with 6 columns, Gap 24, Inset 0 — lines span edge to edge inside the component.
Tune Inset Right to pull the last line inward; adjust Physics for feel.
Q: Why doesn’t margin move the lines?A: Use Inset Left/Right (inner padding). Margin on a Fill-width component shifts the box in the parent, not line positions inside the grid.
Q: Multiple instances on one page?A: Yes. Each instance runs its own lightweight simulation when in view.
Q: Canvas performance?A: Static straight lines in the editor; physics runs in preview and on the published site only.
Not a CSS grid or Lottie loop: coordinate-mapped pluck on N parallel vertical strings with shared RAF, edge-pinned column distribution, and buyer-facing inset/gap math—behavior that cannot be replicated in the visual editor alone.