Styling of PEPs

PEPs
41

Sure, but my point is whether it is really worth doing and maintaining all of that just to get consistent-looking fonts on different platforms, OS versions, browsers and user setups, when adding a webfont would be essentially a one-liner? If we were talking a larger, popular theme like Furo, then sure, but this is the bespoke theme of a single technically-focused subdomain of a single site.

Yeah, but that’s missing anything for macOS as well as the more modern Windows fonts.

Right, but my broader point in including those older versions was to highlight that the default monospaced font has changed many times over the recent version history of both OSes, and is likely to change again in the future. I don’t think we should spend time optimizing for any of these OSes, and instead just use a webfont which will render successfully and consistently on all platforms.

42

FYI, this was brought up by @methane on a Python-Dev thread and a corresponding issue, python/peps#2437. This highlighted the issue (and perhaps another that I haven’t yet confirmed) on Android, which is another dimension of the problem space I hadn’t considered—in addition to desktop platforms, we also have Android and iOS to worry about (as well as more niche/heavily modified mobile OSes), particularly with the system font stack approach (though some slowness to load web fonts was also noted, which is a somewhat more practical concern on mobile).

Given this is being widely reported, for a stopgap solution until we agree on a more permanent one, I figure its best to do as @pradyunsg suggested and reduce the size of the code font to the 0.875rem/14px value, which both reduces the perceptible difference between platforms/etc. while making it more obviously distinct from the prose font (reducing the downsides of the system font stack approach), while ensuring that 79 characters fit on a line under any non-heavily-constrained screen configuration.

43

Small suggestion on collapsibles (especially the contents section) to make them more discoverable:

// style.css
details > summary {
    cursor: pointer;
    font-weight: bold;  // already exists
    width: max-content;
}
details > summary:hover {
    text-decoration: underline;
}

For PEPs site styling, is this the best place for suggestions? Would a docs mailing list, new Discourse thread, or GitHub issue be better?

1 Like
44

Here is fine, though it seems right now most of the immediate activity is concentrated on python/peps#2437. I’m about to push a number of tweaks to the PR based on the further feedback there, and in fact actually noticed some issues with the discoverability of the Contents dropdown particularly on mobile and was working on improving that, so your suggestions come at a perfect time (and all look good). I’ll implement them momentarily.

45

Implemented on python/peps#2439, along with a number of other responsiveness improvements.

46

FWIW, I looked at the PEPs on an iPhone 12 with Safari, Firefox, Brave, Edge, and Chrome and they looked fine, even good! to me.

47

Yeah, I’d tested it on my Pixel 3a running Android 12 (using FF, ofc) and it looked pretty good, but apparently the main problem being reported (with content not scaling down to the viewport width due to fixed-width elements) only occurs on specific PEPs (with large tables, like PEP 594) and/or devices with very narrow viewport widths (like the Samsung Galaxy S10 series, with a mere 360 px viewport width on a huge 6.1-6.7 inch 1440p screen…I really don’t understand why manufacturers use such a high DPR on such a large device).

48

The new infra has been working very well for the past year! :rocket:

To follow up on some of the cosmetic issues raised here, please see PR python/peps#3132 to improve readability by using system fonts and more default CSS styling, giving the text more room to breathe.

4 Likes