Repository navigation
Font size mismatch between code & prose, and various layout issues at narrow viewport widths #2437
Description
Screenshot of https://peps.python.org/pep-0661/
It seems Web Font caused this issue. PEP site is using "Source Sans Pro" for regular text:
<link href="https://fonts.googleapis.com/css2?family=Source+Sans+Pro:ital,wght@0,400;0,700;1,400&display=swap" rel="stylesheet">
pre code uses Android system monospace (Droid Sans Mono):
font-family: ui-monospace, "Cascadia Mono", "Segoe UI Mono", "DejaVu Sans Mono", Consolas, monospace;
Both font size is 16px. But actual font size is very differ to my eye.
And I need to horizontal scroll to read the text. I am not sure, but I think font caused it.
See this screenshot. It is same page, but I need to zoom-out. Regular text is hard to read because of very small font size.
It seems Chrome can not break _get_parent_frame().f_globals.get('__name__',. Droid Sans Mono 16pix & this line defines site width.
And since "Source Sans Pro 16pix" is very smaller than "Droid Sans 16pix", regular text rendered very small.
Possible solution:
- Stop using "Source Sans Pro" -- it's web font, slow to load.
- Use web font that have size similar to "Source Sans Pro" for
pre codetoo.
Activity
[-]Rendering on Android is not good.[/-][+]Font size mismatch between monospaced (code) and sans (prose) fonts[/+]CAM-Gerlach commentedon Mar 17, 2022
Thanks for opening an issue here. As far as I can see described above, the font size inconsistency issue is common to all platforms, rather than anything specific to Android (though it does vary somewhat by platform due to the use of a system font stack for the code font), and has been discussed at length on the Styling of PEPs thread devoted to it.
I saw it noted on the linked Python-Dev thread that there was apparently some sort of responsiveness issue specific to Android, but there did not seem to be any screenshot attached to the message noting such, and I could not reproduce it on my Pixel 3a, and everything looked great even on its relatively small screen (aside from the aforementioned font size of the code font being too large). If there's another issue I'm missing here, please let me know and I'd be happy to try to look into it further.
In any case, wrt the font size issue, all involved agree that either of your two options (consistent web fonts or using the status quo) makes more sense than the mixed status quo, where the monospaced (code) font uses a system font stack, but the sans (prose) font uses a web font. However, there is still disagreement about the best approach to take; at present, it seems there are more people advocating a system font stack approach, but also concerns (full disclosure: mostly raised by me) about maintainability and cross-platform consistency (given the obvious differences between various platforms, OS versions and user configurations, which is a non-trivial burden for a bespoke theme intended for a single subdomain), and we'd also need to test and decide on which of the many possible system font stacks to use (and the ones I'm aware of don't even really consider mobile OSes).
As a stopgap solution, to ensure 79 characters fit on a line under all but the most constrained screen resolutions, and reduce the perceptible size difference between the prose and code fonts while making it more motivated, I'm going to open a PR to just reduce the code font size to something similar to what Furo uses, 0.875rem/14px as was suggested and discussed there, until we decide on a final resolution to the font stack issue.
methane commentedon Mar 17, 2022
How about adding
word-break: break-all;topre codein style.css?It doesn't solve the font size mismatch issue. But Chrome can break line at any point in code so page width is consistent. I don't need to horizontal scroll or zoom-out to read regular paragraph.
And wrapping at any-point is very common for code editors including Vim.
CAM-Gerlach commentedon Mar 17, 2022
Ah, I understand now—I wasn't clear on the exact issue on my first read of the above. Sure; I can add that to just
presince it will ensure that inline code literals still break cleanly by word, while longer blocks of code in code blocks break on each letter.I've implemented both in #2439
cooknl commentedon Mar 17, 2022
Here's the screenshot that I attached via Gmail that didn't make it through to the web forum
Screenshot
It seems like my browser always starts zoomed in.
When I zoom out, the line breaks are appropriate, but the font size mismatch is evident.
More screenshots below
cooknl commentedon Mar 17, 2022
Screenshot 1
Screenshot 2
Screenshot 1
methane commentedon Mar 17, 2022
Oh, I thought "I can reproduce", but actually, that is different issue.
In the PEP 594, table caused horizontal scroll or very small font. Not caused by pre tag.
[-]Font size mismatch between monospaced (code) and sans (prose) fonts[/-][+]Font size mismatch between code & prose, and various layout issues at narrow viewport widths[/+]CAM-Gerlach commentedon Mar 17, 2022
Ah, yeah. It looks like the table results in the width being fixed at wider than the default viewport (i.e. the device width), which requires either scrolling or zooming out.
@methane @cooknl I've made a number of additional improvements in PR #2439 to improve rendering at narrow screen widths, particularly on PEPs with wide tables and large code blocks, as well as general responsiveness enhancements. I tested them in various simulated devices at various widths, with particular attention to the Pixel 3/A/XL, as well as my actual Pixel 3A.
These further improvements include:
Here are some example screenshots on PEP 594 on similar parts to those you posted, using a simulated Pixel 3, before on the left and after on the right:
Top of Page
Contents and Headings
Version Section
Table
Code Block
Does this help mitigate the above issues in your testing? Or what else specifically do you think needs to be done?
cooknl commentedon Mar 17, 2022
sfermigier commentedon Mar 17, 2022
I think a bit more margin wouldn't hurt. Not sure if you've changed it or not.
CAM-Gerlach commentedon Mar 17, 2022
@sfermigier Thanks; assuming you're talking about the padding/margin (particularly horizontal) around the main content container, I noticed that as well. I've increased it a bit at the narrower width breakpoints it was a problem at to avoid the content being too cramped and not having any margin to the screen edge.