gitea
gitea copied to clipboard
go-gitea
Makes wiki ToC sticky
Makes ToC follows viewport on wiki pages to ease navigation.
Top of page
Scrolled
It just occured to me that this might do exciting things if the ToC is, itself, as tall as the viewport. I don't know if that's a case we care to account for.
Yes, sticky big TOC can get annoying because one has to scroll to the page end to scroll the TOC. For that reason, I'm undecided whether this change is a good idea.
Yes, sticky big TOC can get annoying because one has to scroll to the page end to scroll the TOC. For that reason, I'm undecided whether this change is a good idea.
We could give the TOC a max height with a scrollbar?
We could give the TOC a max height with a scrollbar?
No, nested scrollbars are generally confusing UX.
One solution might be to sticky only if TOC height is less than viewport height but that'll probably require some JavaScript until container queries arrive.
Even as is, I think this is more useful than not?
At present, you always have to scroll to the top of the page to get back to the ToC. With this change, at least you only need to do it with very long ToCs.
Querying the container height in JS seems like the full package, but I am less familiar with the JS usage in the front end...
No, I think a JS solution is probably not what we want right now. Let's see what others think about this change. I personally am undecided, pro's and con's are about equal.
if you add _Sidebar.md which has a lot of list elements (a manually kept Index of pages for example), with this change the TOC box starts scrolling "into itself" as the Sidebar goes up, until the Sidebar reaches the top then the TOC box scrolls off screen. As soon as the Sidebar scrolls out of view, the TOC will reappear again below it. Add a _Sidebar.md with say 30 list items, a very long wiki article (pages long) and then test this change and you should see the behaviour.
if you add
_Sidebar.mdwhich has a lot of list elements (a manually kept Index of pages for example), with this change the TOC box starts scrolling "into itself" as the Sidebar goes up, until the Sidebar reaches the top then the TOC box scrolls off screen. As soon as the Sidebar scrolls out of view, the TOC will reappear again below it. Add a _Sidebar.md with say 30 list items, a very long wiki article (pages long) and then test this change and you should see the behaviour.
Good catch! Perhaps in the presence of a custom sidebar, the ToC should not attempt to be sticky?
Good catch! Perhaps in the presence of a custom sidebar, the ToC should not attempt to be sticky?
That sounds like the best idea. On mobile, the TOC/Sidebar is already really bad looking and makes the wiki document "too skinny", a scrolling TOC on mobile would make it worse. We could probably use a "hide TOC and Sidebar in Mobile mode" setting to make the content more readable, and not show/scroll the TOC at all on Mobile. (to be fair, Mobile mode on 1.17.x is a great upgrade from 1.16.x)
@tepozoa Would be a good issue for a separate PR I think - style the ToC differently on Mobile so it appears above, rather than next to, the wiki.
I think it would be good idea to make it sticky only if toc height is less than screen height by adding custom class on load with js
@lafriks that would be the ideal UX. But I was trying to avoid a js solution because I'm not sure how to implement it in this codebase.
@tepozoa Would be a good issue for a separate PR I think - style the ToC differently on Mobile so it appears above, rather than next to, the wiki.
Done, thanks - found an unrelated TOC+Sidebar bug while creating the demo page to report this, so we get two Issues for the price of one test document. :)
Thank you for the contribution.
I can see that there are some unresolved review comments. Actually, I also have the same concern about "long TOC scrolling" problem (no idea at the moment, either).
Gitea's wiki system is far from ideal, there are too many design problems from beginning. For the TOC part, there are many issues discussing about how it should be displayed, etc, it's difficult to come to some agreements and it's difficult to improve and satisfy everyone at the moment.
So, before there is a whole good/clear design for the wiki system, I guess users could fine tune the wiki UI by using customized CSS styles/JS scripts.
Could this PR be closed? Thank you again.
