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.