what I learned or was reminded of implementing in-browser vector polygon editing

Well, the big thing is that I really should have started this before 3:30 AM.

There’s a widely supported “wheel” event whose “deltaY” property gives you the direction of the scroll wheel, typically 3 for scrolling up or -3 for scrolling down. It also has mouse event attributes.

Old Safari on iOS, and the old Android browser, don’t let JS create a link element and then .click() it in order to initiate a file download. But modern Firefox and Chrome do. The other browsers still let you click the link manually.

There isn’t really a way to do mouse drags on touchscreen browsers. I kind of knew that but it still sucks. I didn’t have time to get touchscreen editing working as a result.

20 pixels is a reasonable fudge factor for finding vertices you might have been trying to click on. At least on my netbook, 10 is too small.

The EPS format is super easy to generate, easier than I expected, and with mime-type application/postscript, Chromium and Iceweasel on Debian correctly direct it to evince. However, QuickPDF on Android doesn't support it, even if I rename the file to end in .ps instead of .eps.

This took a couple of hours primarily because it ended up being like 300 lines, because I didn’t use any libraries beyond the base browser, more than anything else. At this point, I probably have enough experience with this motley collection of things I’m trying to do to come up with some kind of standard library. Like, something that would have reduced this app to more like 100 lines.

It’s a little embarrassing that I used <canvas> for this one because the only browsers I'm interested in that support <canvas> but not SVG are old iOS browsers. On the other hand, <canvas> itself wasn’t what took up my time on this project; only about 15 or 20 lines of the code in here had to do with <canvas> per se, and it’s not clear that those would have been quicker or clearer with SVG.