-
Notifications
You must be signed in to change notification settings - Fork 339
Collapsible sidebar #2159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Collapsible sidebar #2159
Conversation
I made the following accessibility checks:
|
2a0e7c0
to
817ec63
Compare
Update: I have incorporated feedback from @smeragoel. The only thing left to do with this PR is to add a bare minimum of tests, and then I will mark it ready for review. I will not be able to get to writing tests until next week. |
I am really looking forward to this implementation. Thanks @gabalafou and @smeragoel. 👏🏻 |
Note to whoever merges this: please add @smeragoel as |
92186ce
to
b766196
Compare
Okay, I added tests. This is now ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this @gabalafou and thanks for adding the tests.
I did not spot anything major, but left a message about reusing existing test sites to try and avoid adding too many sites, especially since we already have one for sidebars testing.
src/pydata_sphinx_theme/theme/pydata_sphinx_theme/components/sidebar-collapse.html
Show resolved
Hide resolved
@trallard thank you for review! I think I responded and addressed all of your comments. The PR now needs another round of review and then hopefully it will be good to go! :) |
About the failing link checkThe link check is expected to fail because there is a page in the docs that contains links to each of the component files in GitHub. This PR introduces a new component: But there was one unexpected thing. The link check reports several gnu.org links as broken. But I suspect those might just have been a network fluke, because when I go to the links, they work. The error message for all four of those links looks roughly the same:
|
those have been failing regularly for over a week now at least. Currently 🙈 but hopefully fixed by #2174 |
Co-authored-by: Tania Allard <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @gabalafou 🚀 this is a rather exciting new feature.
Will wait for the CI to complete and we can merge this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making the configuration explicit 🌻
These fail only on CI (but not always), and they might be related to some That aside, this PR looks ready to merge so will wait for the rest of the CI to complete and merge it 🚀 |
Ooo thanks! What release will this be in? |
border-right: 1px solid var(--pst-color-border); | ||
background-color: var(--pst-color-background); | ||
overflow-y: auto; | ||
overflow: hidden auto; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to self: this is the one change that I worry about having unintended consequences. I don't see any reason why the primary sidebar should scroll in the horizontal direction and show a horizontal scroll bar, but I may not be aware of some sites or configurations that need the primary sidebar to scroll along the x axis.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(The reason why I don't think it needs horizontal scroll is that the section table of contents is configured to reflow, and ethical ads are also responsive.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can happend when creating API documentation. By design sphinx will use the full path to the method/class you want to describe which can become very very long if unchecked. I have created an example myself. I faced the problem when I was doing this: https://geetools.readthedocs.io/en/stable/autoapi/geetools/index.html and I was forced to change the template which is not straightfoward for new users. I know the title can be responsive as well but I find it easier to understand when things remain on 1 single line (at least for API names)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, this is one such instance where we'd have horizontal overflow.
@12rambau would it be possible to see how the new feature would render for your API docs? I am curious on whether we will be hitting some unexpected behaviours.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm currently travelling with only my phone so I cannot really make checks outside of the github realm and building this documentation requires a new release from my side. I'll let you know once I'm back home and I can locally do a test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No rush at all. Thanks for considering.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By design sphinx will use the full path to the method/class you want to describe which can become very very long if unchecked.
Yeah, we can see that on the PST API docs page with the long method name pydata_sphinx_theme.edit_this_page
.
I believe the alternative would be to force the method name on one line which, if the primary sidebar is narrow enough, will cause part of the string to be hidden on the right side (in the sidebar's overflow). That means the user will have to scroll horizontally in order to see the rest of the name. That feels to me like it makes the table of contents even harder to absorb visually than if the method name is broken across two or more lines.
Here are two screenshots to show the difference.
No wrapping
With the page a bit narrow and text wrapping turned off, the user can only make out "edit this pa":

With wrapping
With the page a bit narrow and with text wrapping enabled, the user can see the entire method name:

There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the text wrap even if it looks a bit chunky at least you see everything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the wrapping is fine, I do not expect this to be a very frequent situation, and if it causes problems we can reevaluate/iterate.
I came back to this PR because I suddenly thought I had forgotten to include @smeragoel on the git commit co-authors, but then I realized that I didn't do the actual merge for this PR (@trallard did). Then I looked at the commit and saw the following at the bottom and it made me happy:
Thanks @drammock, @trallard, @smeragoel for all of your help, you are a great team! 🌻 |
Fixes #1072.
Screenshot showing vertical and horizontal alignment guidelines: