This weekend, while working on a re-design of tldraw's overlays, I found myself reviewing the geometries that we use for our selection box. When a user has one or more shapes selected, we display an interactive overlay that allows the user to transform their selection: a drag inside the box will translate the selection; a drag on the edges will resize along that axis; a drag from the corner will resize along both axes; and a drag from further out on the corners will rotate the selection.

Like many features in tldraw, my design here was meant to follow the conventions of design tools. This meant a broad survey of other applications, both new and old, reconciling differences between them, and picking a design that I felt best served the user while remaining conventional.

With the selection box, I remember being surprised by how much variation I found between tools. Some apps let me resize from edges, some didn't. The rotation corners were less common than I thought, perhaps because they're less discoverable than a rotation handle. Even the interactions, like flipping from a right edge side across the left edge, were only variously supported or weirdly divergent.

One of the most interesting questions was: where are the different hover areas? If a user could drag both the edges and the corners, how did those two hit areas fit together? Where was the rotation area? Every app I tried seemed to do things in a slightly different way. Working on my design in 2021, I struggled to find the patterns. Because there was no way to see the hit areas, my investigations were limited to moving my mouse around very carefully and seeing where the cursor changed.

Coming back to the issue five years later, I decided to find out for sure.

To do this, I fired up Claude Code and put together a Hammerspoon script that would move my mouse in a 50x50 grid, keep track of what the cursor was at every position, and then generate a PNG of the result.

And here are the results:

tldraw

As a baseline of correctness and perfection, here are tldraw's own hit areas looks. The resize corner area is a square slightly offset from the box geometry's corner, with an area slightly bigger than the edges. The rotate area is also a square with its inside corner at the geometry corner.

Figma

In Figma, the edges are bigger, the rotate area a circle that shares the outer edges with the edge hit areas, but is smaller than the edges. The rotate area is an arc segment that wraps around the corner. The yellow area is the corner radius control.

Sketch

Sketch uses a similar wrapping corner radius, though it is a square centered on the corner control. Its edges are smaller, with a slightly larger corner area, similar to tldraw's.

Paper

Paper's results were unusual: it looks like the app uses a square rotation handle, pinned to the inside corner of its edges, with a "teardrop" shaped resize handle formed of a circle and square.

Framer

Framer sadly must lose a point due to its right edge overlapping slightly the top edge. The corner resize area is a circle centered on the corner of the shape geometry with the same radius as the edges, and a healthy rotate area aligned to the inside of the edges.

Excalidraw

A beacon of rationality, Excalidraw uses the same size used for edges and corner. No rotation handle here, as the app uses a rotation knob instead. The yellow area here shows a resize cursor. Most applications surveyed here don't show this until the user starts a click, or long press in tldraw's case.

Pencil

A new entrant to the design tools space, Pencil also uses the same size for both its corner and edge areas, with an offset square rotation area centered on the geometry corner and clipped from the internal space of the geometry. Similar to Sketch but without the slightly more narrow edges.

Mural

Similar to Excalidraw, Mural also uses the same size for both its corner and edge areas, though with more generous spacing overall, and a healthy offset for its rotation area.

Canva

Canva also uses the same size for its corner and edge areas, though Canva's outside corner is rounded off. Fantastic! It uses a separate knob for rotation, so no area for rotation here.

Miro

Miro's hover areas are in a poor state, with a corner area smaller than its edges as well as edges that overlap. It also uses a rotation knob so no rotation area here either.

Spline (3D)

Spline is an interesting case because it actually appears twice on this list. These are the areas for its 3D app's corner and edge areas. Rotation is handled with a widget. The app gets extra credit because it handles edge and corner resizing in three dimensions quite reliably.

Spline (2D / Hana)

Spline's other editor is their 2D application, Hana, that has my personal favorite in niche designs for hover areas. Its edges are tapered! Its corner is a circle, centered on the corner of the selection geometry, with a second circle for rotation aligned to the inside corner. How strange!

Draw.io

With no edges, Draw.io's only claim to fame on this list is that its rotation area is placed in front of its corner resize area.

Adobe Illustrator

This unusual result from Adobe Illustrator is quite interesting. Illustrator has separate interaction controls for its edges, which do not include a change in cursor, and which take precedence over the corner resize and rotate controls. These are centered on the outside of the selection geometry.

MSPaint

Well, at least JSPaint. What is lost from edge resizing is made up for by a big honking corner resize.

Rive

Finally, the most unusual of the group belongs to Rive, an animation tool whose selection box features large edges, a very large corner rotation, and a bizarre arc for rotation that to my practiced eyes appears to be rotated by degrees, rather than radians, or perhaps a misplaced decimal. -4.5° rather than -45°?

Conclusion

What a lovely collection of hover areas, and so diverse as well.

Upon reflection, maybe I shouldn't have been so surprised: every time I've done these deep explorations of application features, I've found the canvas to be filled with slight variations and interpretations of the conventions of canvas software. There are just so many.

In any case, I might tweak tldraw's resize areas to be even more general and rational in design. While there are many ways to do this design, at least all of the downstream applications that use the tldraw SDK will benefit from having consistency among their hover areas. If we do our jobs right, and those designs diffuse via the SDK to thousands of dependent apps, then perhaps we'll define the next conventions. I hope we get it right!

After I posted about this on Twitter/X, Egor Chistyakov pointed out another article on the same topic by the team at Bjango. If you need even more design tool area discourse, check it out here. If you would like to read more like this about tldraw, you're on the right blog! Follow me on Twitter/X at steveruizok and follow tldraw, too.