A touchy subject

Hi, it’s Megan, tldraw intern, here.

While playing around with tldraw on an iPad, I wanted to make a second finger act as a shift key for drawing. The canvas doesn’t currently do it because it was looking specifically for touch events when on a tablet, so I decided to see if I could add the functionality.

Other apps do it on their iPad app, so it is possible to do natively, but can we do it on the web?

Well, yes and no.

It works really well when I'm using my finger to draw. The pointer events API gives me both positions of my finger presses, so I can trigger a virtual shift key down on the second pointer down.

The second press can conflict with pinching. But that's okay so long as we wait for you to start drawing before the second touch occurs.

So far so good, but what if I want to use the Apple Pencil? It should surely work the same way, right?

I found that when using a stylus, once the pencil is touching the screen, the OS stops sending finger events to the browser entirely, no matter how many settings I tried to tweak. I’m guessing this weird quirk is a palm rejection feature, or just an oversight by whoever made the API.

And so I had to give up on the entire API that drives touchscreen events. Does that mean we’re cooked? Maybe not.

Scroll forever

I looked around for whether any other interactions existed for me to exploit. One of the most versatile options that came up was scrolling.

It turns out that scrolling isn’t handled by the DOM events system. It’s an entirely separate native layer, so you can scroll even when every DOM event is being blocked. Clearly an intentional choice so that doomscrolling can always be an option.

This then triggered a mini prototyping sprint: can I make a scrollable object detect a stationary finger press? What about trying to hook into scrolling velocity? Scrolling direction?

Here’s where I ended, while drawing with the pencil, you can swipe down to trigger the shift button and swipe up to release it.

You’re basically scrolling an invisible div covering the entire screen, which is only present when a stylus is touching the screen. I used the direction of the scroll to determine whether shift should be activated. I hooked directly into the keyboard equivalent of the shift key, so every interaction works exactly the same.

It's slightly cursed, and I don't think it'll ship, but it’s fun to use!

Justice for browser APIs

I wouldn’t have stumbled upon this weird interaction if it weren’t for the elaborate constraints around the touch events API. I was forced to get creative, and this rabbit hole introduced me to a truly fun new interaction.

Still, it would have been nice for the obvious version to just work. Justice for browser APIs!