wake-marquee

An endless marquee that answers to the scroll. It reverses when the reader scrolls back, and drags against its own direction of travel as it crosses the viewport.

3.9 kB gzipped · 0 dependencies

npm i wake-marquee

You have prefers-reduced-motion: reduce set, so every row below is standing still. That is the library honouring it, not a bug.

the ordinary case

A logo row. fade softens both edges so items are never cut mid-glyph, and wake: 10 means the scroll drags the row against its own travel as the section crosses the viewport.

wake: 0 against wake: 18

no wake constant a banner playing on a loop ignores you wake: 0

with wake dragged has weight answers the scroll knows you are there wake: 18

The same row twice, at the same speed, differing only in wake. The top row is a plain loop and reads as decoration. The bottom row is being pulled through the page, and stops looking like a banner.

the turn

scroll up and I turn eased, not switched ease: 2.5 ↺

I keep going reverse: false still has a wake just no turn →

Scroll up. The top row turns around and the bottom one does not. The turn is eased over ease, not switched, so the row reads as something with momentum rather than a video played backwards.

two rows against each other

travelling left dragged right wake: 14 scroll and we open like shears

travelling right dragged left same wake opposite pull that is the trick

The commonest marquee layout, and the one where the wake earns its keep: the two rows are dragged in opposite directions, because the wake always pulls against travel. Scroll and the pair opens and closes like a pair of shears.

three items

three items that is all there is the rest is copies

A lane narrower than the container, repeated until it covers one. This is where a hand-rolled marquee usually breaks: too few copies and a gap crosses the row once per lap, and the number needed changes with the viewport. The count is derived, not configured.

speed: 8% against speed: 60

speed: 8% of the container every second narrow the window and I slow down with it

speed: 60 pixels a second whatever the window and on a phone that is a different row

Narrow the window. The top row slows down with it and the bottom one does not. A pixel speed is a physical unit on a page whose elements are not physically constant: the same 60 that reads as calm across a desktop crosses a phone in a third of the time, with the items scaled down and three times as many of them going past a second. A percentage is a fraction of the container width per second, so the pace survives the trip.

pauseOnHover

hover me and I hold pointer: fine only let go and I resume

Rest the pointer on the row. Only where there is a real pointer to rest: on touch there is no hover to leave again, so the option is ignored rather than trapping the row in a paused state.

a container that carries a transform

this row is flat the two sides are not rotate(90deg) same loop

turned still counts

measured in the layout not on the screen so the maths holds at any angle

on its side same maths

Four rows framing a block, two of them under rotate(±90deg). A transform moves the box on screen but not in the layout, and the loop is written in the layout: the lanes are translated inside the row's own axis, and the overhang is a percentage the browser resolves against the untransformed box. So every distance the loop is made of is measured there too. Read off the screen instead, a row turned on its side reports its own thickness as its width and runs on numbers wrong by its aspect ratio. The four speeds are percentages, which is why the short sides are the slower pair: a percentage is a fraction of its own container, and theirs is shorter.