Thank you everyone! What a surprise to be on HN today. Happy to answer questions!
Are there shortcomings with the built-in feature compared to your code?
https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement...
https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement...
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
> Note that this is not the HTML Drag and Drop API, which involves dragging an element onto another element. For my diagrams, I’m dragging but not dropping, and the scrubbable number example shows how I’m not necessarily even moving something around. So I need to read the mouse/touch events directly.
The drag and drop API is doing a different thing that isn't always appropriate - you can get it to do roughly what this article is talking about by making the thing being dragged invisible just after the dragging starts, but it can shrink things and doesn't let you edit them as DOM nodes after the dragging has started. It also lets you drag something out of the browser window and try to put it into a completely different window.
I've a quick question. How do you restrict the dragging movement to an axis using the built-in DOM events like dragstart/etc. I had a drag & drop feature implemented using the dragstart/dragenter/dragover/drop/etc events. I couldn't find a quick way to restrict the dragging movement to the x-axis. JQuery's drag and drop API used to support it. I'm trying to use the native DOM events/api only. Any information or pointers are greatly appreciated.
1. When I get the event, I update the underlying state, but leave the DOM element alone.
2. I can apply constraints to that state. To restrict dragging to the x-axis, I would never change y.
3. I use the state to drive the redisplay of the DOM element.
Some examples of constraints I want: https://www.redblobgames.com/articles/curved-paths/making-of...
I think jQuery's drag and drop API is using the mouse events directly and not using the built-in dragstart/etc., and that's why they can apply constraints.
Definitely one of the best websites I know. Cheers!
Do you worry at all about someone’s browser not supporting them, given that Safari added support in 2020? I guess Safari 12 is hopefully no longer used in practice, with macOS Mojave users hopefully running Safari 13 or 14? It would be pretty bad if something as simple as dragging didn’t work in a production app designed for the market of web users at large.
Adding event handlers to the document during a drag is a time-honored practice, and browsers add brand-new features all the time that are intended to simplify some use case or other but have their own edge cases and gotchas, which the article says are not fully addressed. And there’s still a combination of pointer and touch events in the end result. I wonder if the “simplicity” in the sense of less code is worth the additional edge cases, less browser support, and the developer needing to understand the ins and outs and browser differences of pointer events, which are presumably less understood and documented than mouse events.
This page is not prescriptive: I'm not trying to tell everyone else what to do. This page is descriptive: I'm trying to document what works for me. For the use cases I need on my pages, pointer events cleared up a lot of glitches and edge cases I previously had with mouse+touch events. There are some that remain. I'm happy with the switch. This isn't a luxury everyone has. Not all use cases are as well supported as the things I want to do.
Big fan of your writing, btw!
The longer answer is: I'm not actually sure how to solve this problem. The second site, simblob.blogspot.com, is an actual blog. It's time ordered. It has posts. But the main site, redblobgames.com, is structured as a "living document" site, not as a blog. Things are not posted in order.
I could try an automated feed that looks for any changes on pages. But I make small changes all the time. For example on [1] I changed "So far we’ve made step have the same" to "So far we’ve made steps have the same". I've been fixing a lot of broken links and typos this week, so there are lots of pages that have changed, but not in meaningful ways. I don't want those showing up on the RSS feed.
The second problem with an automated feed is that I have pages that aren't meant for publication. I collect notes for myself before I write an article, sometimes for years. For example [2] is something I may never get around to publishing. I don't want new pages to show up on the RSS feed, because most of them aren't ready yet, and some may never be.
So an alternative is for me to manually add entries to an RSS feed when they're "meaningful". I'm trying to do this by posting to the simblob.blogspot.com blog. An example is [3] where I describe the changes I'm making to the mapgen4 page. These wouldn't have been picked up by an automated feed because the HTML didn't change, but the interactive part did, so I wrote about it. Another example is [4] which is about changes to the hexagon page. I'll also go into a lot more details about why I made those changes [5].
But manually writing blog posts means there will be changes that won't show up in the RSS. Ideally I'd have some kind of automated way to flag meaningful changes to the site, but until then I am trying to write meaningful changes on the blog.
[1] https://www.redblobgames.com/pathfinding/a-star/introduction...
[2] https://www.redblobgames.com/articles/probability/loot-drops...
[3] https://simblob.blogspot.com/2023/04/improving-mapgen4s-boun...
[4] https://simblob.blogspot.com/2023/04/explaining-hexagon-layo...
[5] https://simblob.blogspot.com/2022/11/introduction-to-hexagon...
What's your most interesting piece that hasn't gotten sufficient attention yet? I believe HN has had many great threads about the A* and hexagonal grid articles over the years. Is there a comparable one that's been overlooked so far?
I think the best candidate is https://www.redblobgames.com/making-of/draggable/ . It's from earlier this year and hasn't been posted to HN yet (I think).
[1] https://simblob.blogspot.com/2023/04/explaining-hexagon-layo...
[2] https://simblob.blogspot.com/2023/04/improving-mapgen4s-boun...
Obviously, many comments on the thread predate this change, but there's enough context here for readers to figure that out, and hopefully we can get a more specific discussion going.
Generally I feel like links to collections of stuff do well when they are interesting and don’t when they aren’t and that you modding to a specific example isn’t actually improving quality.
But if we're to optimize HN for intellectual curiosity (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...), we have to consider thread quality, and there's no doubt that submissions like this generally lead to generic, and therefore shallow, discussion in the way that I described upthread.
Overall I think the best way for HN readers to discover a site like this is bottom-up: to run across an example of a great article and a great thread about it, and then click around to discover what else is there. This is more in the intended spirit of HN.
Edit: it's a little unorthodox for us to change the URL in midstream after a submission has this many upvotes and pre-existing comments, but I hope everyone understands that I did so to give the site more exposure and appreciation, not less. The alternative would have been to downweight the post as a "list submission" (https://news.ycombinator.com/item?id=37707904), and I didn't want to do that.
Coming back to the thread half a day later now, I suddenly found that I upvoted the page "Draggable objects" despite never having previously visited or hearing of the page.
I read the new page anyway and liked it. But it contradicts the original my intent of the upvote and essentially gaslights me into a fictitious past.