I restarted working on my version of the Nixpkgs manual that renders CommonMark directly to HTML using my project mmdoc instead of how it currently goes through Pandoc and Docbook.
It currently renders the manual on my computer in about 2 seconds, outputting both single page, multi-page versions. mmdoc is written in C with minimal dependencies to keep the closure size down if we were to use it in the NixOS manual.
I’d appreciate it if you could look at the latest version of the multi-page manual and reply to this post with any encouragement, usability feedback, and bug reports!
What phone is it and what browser? On my phone, it defaults to not showing the sidebar (because the screen is small). Is that what happened for you? What do you want to happen when you have the sidebar open?
This happens to me on Firefox mobile (fennec) too, and is especially annoying when I have JS disabled for the page, because the menu button won’t work to hide the sidebar (which is expected, losing half the screen due to that maybe less so).
I’ve seen this on a Samsung S8 and a Google pixel 6.
Ideally the sidebar would be collapsed by default, because if I open a page on my phone I probably would rather read it than try to find something else in the sidebar, at least initially. If I must, flipping on JS and opening the sidebar isn’t terribly difficult, but it gets in the way at first.
It affects the nix docs as well. It’s a common thing for various doc sites, I believe this is default behavior for bootstrap, just usually its menus come from the top down, where this is much more clearly desirable behavior. But not when it’s repurposed for a sidebar
Edit: Ah, enabling JS fixes it. I knew there was a reason; could a <noscript> with some CSS fix this reasonably? Even display: none; on the sidebar is probbaly ok, since there’s no way to open it without JS, and that’s understood by someone disabling it. Wish the W3C guys did something about navigation requiring JS one day, so much wasted bandwidth and processing power…
I’ve found a broken link to invalidateFetcherByDrvHashhere. mmdoc did figure out that the fragment leads to a different page, but it seems to get the page wrong.
I suppose you have an index of which ids are on which page to achieve this. Would it be possible to add a bit of JS on the root page to redirect to the right page for any fragment?
That way we can switch to multi-page docs without breaking many many links out there on the web.
