CrosshairCursor
A viewfinder that follows the pointer and squares up around anything you can press.
Options
-
colour#c44400 -
css colour
The lines and the brackets. One colour: a reticle is an instrument, and an instrument is drawn in one ink.
-
thickness1 -
0.5 to 4 px
Thickness of a hairline. 1 is right, and anything above about 2 stops being a sight and starts being a frame. In pixels rather than relative, because a hairline is a hairline at any size.
-
size13 -
3 to 60 px
Half-width of the reticle when it is not locked on to anything. Small, so that locking on is a visible change: a free reticle the size of a button has nowhere to go when it finds one.
-
corner9 -
2 to 40 px
Length of a bracket's arms. Fixed rather than a share of the box it is framing, which is what keeps a bracket round a wide button from turning into a box round it.
-
padding6 -
0 to 40 px
Space left around a locked target. At 0 the brackets sit exactly on the element's edge, which reads as a border rather than as a sight trained on it.
-
ease0.22 -
0.02 to 1, good: 0.12 to 0.35
How fast the crosshair follows the hand, per frame. At 1 it is welded to the pointer, which is the same as not having an effect. Low enough to have weight, high enough that it is never somewhere the hand has left.
-
snap0.42 -
0.02 to 1
How fast the brackets take a target, per frame. Higher than the ease on purpose. This is the one number that decides whether the effect reads as locking on or as catching up.
-
targeta, button, [data-target] -
What the brackets will lock on to, as a CSS selector. The data attribute is there so you can nominate anything else without changing the selector: put it on the card, the image, the row.
-
linestrue -
true · false
Draw the long hairlines as well as the brackets. Off leaves the brackets alone, which is quieter and better over text: the lines cross everything on the page, and over a paragraph that is a strikethrough following the cursor.
What it needs
- Category
- Pointer, an effect
- Dependencies
- None at all
- Browser
- No WebGL
- Frame budget
- ~0.3 ms · 0 context
- Pinned to
- v0.13.0
- The part worth having is the lock: when the reticle passes over something you can press, the brackets leave the cursor and square up around that element. Without it this is two divs tracking a mouse. Nothing locks on to empty space
- What counts as a target is a CSS selector rather than a guess at what is clickable. Sniffing gets it wrong in both directions: it misses the div somebody wired a handler to, and it locks on to every link in a paragraph of running text
- The lock comes from a hit test at the pointer rather than from a listener for entering an element. A scripted path moves no real pointer and fires no events, so an effect that locked on only for a live cursor would record as a reticle that never finds anything
- The hit test is skipped while the pointer is still. It flushes layout, and the answer cannot have changed if nothing moved
- The brackets take a target faster than the crosshair follows the hand. A reticle that drifts lazily into place has not locked on to anything: the snap is the feedback
- Four corner brackets rather than a box, because a box round a button is a selection and a bracket at each corner is a sight. Each is the same two borders turned a quarter further round
- Like every pointer effect here it eases against its own last frame, so it is deliberately not pure in t, and the recorder drives it from the scripted path in this file
- The element keeps its own content: the reticle is drawn in a layer over the top that the pointer cannot touch. Set `cursor: none` on the element yourself if you want the real one hidden, which is a decision about the page rather than about the effect
- Six elements, all composited transforms. Nothing is created or destroyed after mount
- One hit test and two rects per frame in which the pointer moved, and none at all in a frame where it did not