-
Seems a reasonable fix. Given that you ideally want to expose an API then it makes sense to replace the anchor-based scrolling with a query string based one. It also makes it easier to implement posts-per-page options in the query string. You could even replace the single post permlinks with ones that kept the requested post in its thread context.
bq-
Given that you ideally want to expose an API then it makes sense to replace the anchor-based scrolling with a query string based one.
We already expose an API. The frontend is fully separated from the back end and anything you can do via the frontend is driven from the API: https://lfgss.microcosm.app/api/v1
REST APIs are fine returning URLs with anchors in them, urls in RESTful documents are supposed to be navigable by clients (including web browsers, not just API consumers), and so using an #anchor is fine.
The addition of a "Safari has bugs so we'll build in workarounds everywhere" anchor param in the GET query would be in addition to the real anchor, so that browsers that don't have this webkit bug won't require a JavaScript cludge to work properly. In fact, if the #anchor is present, I'll make sure that the JavaScript didn't run.
Velocio
Ah, found it.
It's a WebKit bug that Chrome independently fixed in their version but Apple have not: https://bugs.webkit.org/show_bug.cgi?id=24175
If a redirect occurs, then Safari discards the anchor.
I have an idea for a fix, to copy the anchor into the querystring and then to have JavaScript check for it... and if it exists jump to that part of the page. But it might be messy and involve a reload or will insert things into the browser history. I'll check before I do it.