Skip to content
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

Merged
merged 5 commits into from
Mar 14, 2022

Conversation

AA-Turner
Copy link
Member

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

@CAM-Gerlach
Copy link
Member

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.

@JelleZijlstra
Copy link
Member

Agree that a collapsed-by-default ToC would be most useful.

Copy link
Member

@gvanrossum gvanrossum left a 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?

@AA-Turner
Copy link
Member Author

AA-Turner commented Feb 27, 2022

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

@gvanrossum
Copy link
Member

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.

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 PEP 249, PEP 512: ...

(I'm against 'Infra' as it isn't a proper word, and 'Infrastructure' is far too long).

That argument seem weak. :-)

@CAM-Gerlach
Copy link
Member

That pattern is supposed to indicate the PEP being modified, not the PEP that directs the changes.

This is also how I interpreted it, and personally I've found it rather confusing, for the same reasons @gvanrossum did.

That argument seem weak. :-)

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.

@hugovk
Copy link
Member

hugovk commented Mar 13, 2022

@AA-Turner Please could you rebase this so we get a build preview?

(Another huge benefit of build previews: easy to test on mobile!)

@AA-Turner AA-Turner changed the title PEP 676: Remove automatic table of contents PRS: Make the table of contents collapsed by default Mar 13, 2022
@AA-Turner AA-Turner marked this pull request as ready for review March 13, 2022 15:30
@AA-Turner
Copy link
Member Author

The ToC is now collapsed by default with a toggle:

https://pep-previews--2364.org.readthedocs.build/pep-0008/

A

@gvanrossum
Copy link
Member

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.

@AA-Turner AA-Turner changed the title PRS: Make the table of contents collapsed by default Make the table of contents collapsed by default Mar 13, 2022
@AA-Turner
Copy link
Member Author

a) What does “PRS” mean?

"PEP Rendering System", I've removed the prefix for simplicity.

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.

I copied this from the old python.org styling -- would it be better just to have them all white & remove the gray highlights?

A

@gvanrossum
Copy link
Member

Okay, and Yes. Thank you!

@hugovk
Copy link
Member

hugovk commented Mar 13, 2022

Here's a comparison of the old and new sites:

image

Before there were two greys: #f0f0f0 and #f6f6f6.

Now it's #eeeeee and #ffffff white, showing a larger difference.

@AA-Turner
Copy link
Member Author

https://pep-previews--2425.org.readthedocs.build/ is a preview without the highlights, I might add an inner horizontal border though.

image

A

@CAM-Gerlach
Copy link
Member

Here's a comparison of the old and new sites

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.

@AA-Turner
Copy link
Member Author

we should add horizontal rules separating the fields

See the PR, I've done this.

A

@CAM-Gerlach
Copy link
Member

CAM-Gerlach commented Mar 13, 2022

See the PR, I've done this.

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.

@AA-Turner
Copy link
Member Author

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

@hugovk
Copy link
Member

hugovk commented Mar 13, 2022

If on mobile, the sidebar ToC goes to the bottom, so there's no immediate navigation mechanism.

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.

@CAM-Gerlach
Copy link
Member

CAM-Gerlach commented Mar 13, 2022

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.

Copy link
Member

@CAM-Gerlach CAM-Gerlach left a 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:

image

Alternatively, we could drop the h2 and just style summary directly, though that would be less DRY.

Comment on lines 122 to 124
details > summary > h2 {
font-weight: bold;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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>")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
self.body.append("<details><summary>Contents</summary>")
self.body.append("<details><summary><h2>Contents</h2></summary>")

@AA-Turner AA-Turner merged commit 13aa4b1 into python:main Mar 14, 2022
@AA-Turner
Copy link
Member Author

As can be seen in the preview, the Contents dropdown is not styled as intended

Fixed now. I had the <h2> selector in the rule from testing -- the intent was to de-emphasise the contents, as it is now a navigation aid not a section proper, and a full H2 header looked odd with the small triangle.

A

@CAM-Gerlach
Copy link
Member

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.

a full H2 header looked odd with the small triangle.

To note, I address this above; it can be fixed by applying the size to the summary section as well.

@hugovk
Copy link
Member

hugovk commented Mar 14, 2022

I think it's fine as is, and the screenshot above also looks okay. No strong opinion either way.

@encukou
Copy link
Member

encukou commented Mar 14, 2022

There's more than enough whitespace to set the lines apart visually. This isn't a dense multi-column table where eyes would need help to follow the lines.
How about deleting all the rules?
image

@gvanrossum
Copy link
Member

+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.

@CAM-Gerlach
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants