-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Make the table of contents collapsed by default #2364
Conversation
Personally, if given the option between having a duplicate ToC and not, I'd ✔️ this PR, but what about making it collapsed by default, as suggested and discussed on the Discourse thread? It seems like we all agreed that approach would be the best of both worlds. |
Agree that a collapsed-by-default ToC would be most useful. |
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.
Isn’t it confusing to use PEP 676 in the PR title?
Hmm, perhaps. I don't want to break the pattern of 'PEP N: Description', and so I co-opted it for the PEP 676 implementation PRs. Happy to take suggestions for another prefix scheme. (I'm against 'Infra' as it isn't a proper word, and 'Infrastructure' is far too long). A |
That pattern is supposed to indicate the PEP being modified, not the PEP that directs the changes. The pattern is pretty informal, so you could just start with
That argument seem weak. :-) |
This is also how I interpreted it, and personally I've found it rather confusing, for the same reasons @gvanrossum did.
Agreed. Abbreviations are common, encouraged and sometimes (e.g. conventional commits) even required in PR titles and commit messages. So long as those likely to see and care about it know what it means (which AFAIK "infra" is a widely-used abbreviation in dev circles), I don't think it's terribly relevant if it's not "proper" Queen's English. After all, neither is "docs" or other abbreviations we regularly use. |
@AA-Turner Please could you rebase this so we get a build preview? (Another huge benefit of build previews: easy to test on mobile!) |
a765e87
to
67355b2
Compare
The ToC is now collapsed by default with a toggle: https://pep-previews--2364.org.readthedocs.build/pep-0008/ A |
a) What does “PRS” mean? b) I object to the styling of the table at the top with alternating gray and white background color. My mind always wonders why the gray ones get emphasis. |
"PEP Rendering System", I've removed the prefix for simplicity.
I copied this from the old python.org styling -- would it be better just to have them all white & remove the gray highlights? A |
Okay, and Yes. Thank you! |
Here's a comparison of the old and new sites:
Before there were two greys: Now it's |
https://pep-previews--2425.org.readthedocs.build/ is a preview without the highlights, I might add an inner horizontal border though. A |
At least in the PEPs table is a lot better for accessibility. Even to my eyes, I have a really hard time clearly separating them otherwise. But I can see @gvanrossum concerns in the PEP headers. If we're going to remove it there, though, we should ad horizontal rules separating the fields, to make it easier to track what goes with what and make it look a little less odd and unstructured. |
See the PR, I've done this. A |
After having reviewed that one (and left a detailed review comment on it), I think you might have mistakenly pushed your changes to #2425 instead of this PR. If you want to move that over here, I can move my comment as well. |
Sorry for the confusion -- my fault for putting the discussion of field styling in this PR. I was referring to adding horizontal rules on each field, which I did -- you then commented that the colour should have greater contrast on said other PR. This PR only actually deals with the ToC! If the implementation of the collapsed-by-default ToC here is OK, I will merge this PR to help clear up the discussion. A |
On mobile, I see the collapsed Contents toggle near the top but not other ToC at the bottom. But that's fine, I wouldn't really expect it down there. |
Sorry, I guess I was the one that got confused—I didn't see #2425 explicitly referenced anywhere on this PR (or on that one) and the discussion that prompted the change was here (on a PR rather than an issue), so I guess I was expecting to see those changes here. I'll review this one for just the collapsing ToC. |
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.
As can be seen in the preview, the Contents
dropdown is not styled as intended, and thus looks rather odd.
Specifically, a h2
element wasn't used inside Summary
for the title so that rule doesn't have any effect, and in any case the current content is redundant as h2
already has font-weight: bold;
, while it needs display: inline
to render on the same line as the drop-down arrow.
However, this still doesn't quite fix the issue, as the triangle drop-down marker is not sized or aligned with the rest of the text, but this too can be fixed by making summary the h2 size. Final result:
Alternatively, we could drop the h2
and just style summary directly, though that would be less DRY.
details > summary > h2 { | ||
font-weight: bold; | ||
} |
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.
details > summary > h2 { | |
font-weight: bold; | |
} | |
details > summary { | |
font-size: 1.6rem; | |
} | |
details > summary > h2 { | |
display: inline; | |
} |
@@ -89,6 +89,17 @@ def depart_label(self, node) -> None: | |||
# Close the def tags | |||
self.body.append("</dt>\n<dd>") | |||
|
|||
def visit_bullet_list(self, node): | |||
if isinstance(node.parent, nodes.section) and "contents" in node.parent["names"]: | |||
self.body.append("<details><summary>Contents</summary>") |
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.
self.body.append("<details><summary>Contents</summary>") | |
self.body.append("<details><summary><h2>Contents</h2></summary>") |
Fixed now. I had the A |
It looks a little odd and out of place to me, thought I'm not 100% sold on the look of my suggestions either (i.e. the same as it looked previously). What do you all think @hugovk @JelleZijlstra @gvanrossum ? If you prefer the appearance above, I can implement my suggestions instead in another PR, or if you have other ideas, I'd be happy to help implement them in @AA-Turner 's absence.
To note, I address this above; it can be fixed by applying the size to the summary section as well. |
I think it's fine as is, and the screenshot above also looks okay. No strong opinion either way. |
+1 to Petr's suggestion. FWIW the one usability improvement you could make in PEP 0 with the biggest effect would be to make PEP titles clickable. Having to aim at the little number in front of e.g. PEP 1 is awkward for someone with as clumsy a mouse as myself. |
@gvanrossum Agreed; implemented in #2429 |
Still in two minds about this one, but as a proof of concept.
If on mobile, the sidebar ToC goes to the bottom, so there's no immediate navigation mechanism.
A