3/3

Well, I can put both the routing parameters and the scroll target in the hash and implement the scrolling in JS. But that feels more complex than necessary.

Is there a standard solution for this? Or should we have yet another URL component that
- is only available to the client and
- does not interfere with the scrolling functionality of the hash component?

@w3c @tag #WebStandards #WebDevelopers

2/3

Now I have a use case with client-side routing parameters where
A. I would prefer to keep the parameters in the client for data-protection reasons, and
B. I would still like to use the hash for scrolling within the page.

So where to put the parameters? Due to (A) I don't want them in the search and due to (B) I don't want them in the hash.

Any ideas, #WebDevelopers ?
Or at @w3c @tag #WebStandards ?

The app only reads data from mastodon instances and never writes.

You can even use it without any authentication
- If you're only interested in public data
- and if the discussions you follow have at most 60 (direct and indirect) replies.

All your data is stored by your browser, not on a server.

This is good for your privacy but can be inconvenient if you change browsers/devices.
(Any ideas for solving this tradeoff?)

The code uses some relatively new browser features. I did not take care to make it work on older browsers.

I'm developing on Firefox and testing also on Edge. So it should also work with Chrome. I have no Apple devices and don't know how it works on Safari.

I have primarily developed this for desktop browsers, but it is also usable on my tablet.

Some tweaks would be needed for the small screens of mobile phones.

This app is meant as a supplement to a full-fledged #mastodon client, not as a replacement. Ideally I would like to see the functionality integrated in some full-fledged client.

Some interoperation with the standard mastodon web client, #phanpy, and #elk is supported. More clients could be supported easily.