Don't force table widths in versions.rst #1041
Conversation
|
This does look better to me. In Chrome on macOS: Before
After
|
|
Using Firefox on Windows (desktop), at normal widths they look about the same, except with this PR, the widths of the two tables don't match, which looks a little odd and makes them harder to compare.
At substantially narrower widths where they start to get squished, meanwhile, they look essentially exactly the same, as far as I can tell. This seems to be an issue particular to Chrome, since I've seen similar differing table column behavior on other (non-Sphinx) sites I maintain, where Firefox handles the column widths much more sensibly whereas Chrome splits things into multiple columns. While it's perhaps a bit icky to introduce a regression for a community-developed FOSS browser to benefit the monopoly one, the first issue is perhaps better handled in CSS with a custom CSS class that we then have make the table full width. |
There was a problem hiding this comment.
I added these widths for two reasons:
- Make the columns wide enough to fit their content, and prevent it to be split on two lines
- Make the two tables have the same widths and therefore be aligned
Admittedly I think I only tested it on Firefox, which might explain different behaviors on Chrome it other browsers. IIRC there was a discussion about them in the original PR, and eventually I decided to keep them.
Unfortunately, that's the exact thing it's failing to do, but removing the
If you just want the tables to have the same width, setting the
(That's with
Or, it could be that it did originally fit, but some values have gotten wider/narrower since then. That "Georg Brandl, Ned Deily (3.3.7+)" string in the unsupported table is an outlier, and it's going to force that one out of whack no matter what, compared to the supported-versions table. I'm not personally convinced that it's really worth trying to struggle against that, but YMMV. For any table where the data isn't static, fixed column widths will inevitably fall out of alignment with reality unless they're constantly being adjusted to account for every single change in the data. IMHO, that kind of thing gets filed under, "that's the code's problem to solve, not mine!" |
No, actually, FWIW the current live page does indeed still lay out un-wrapped in Firefox. But only in Firefox, I guess, which... |
In the original discussion I'm still using Firefox, so I don't know if the issue got fixed by Firefox, Sphinx, or if it's simply because I'm using a different monitor (which affects the width of the viewport).
This sounds like a good compromise. I tested locally with
Agreed -- aligned columns are nice to have, but hardly essential. IOW, I'm fine with replacing the current |
@ferdnyc Please could you make this change? |
Setting `:widths:` for individual columns leads to weird wrapping, as some columns are too narrow. Just setting the table to 100% width and letting Sphinx figure out the distribution, OTOH, looks fine. Let the software be smart. Signed-off-by: FeRD (Frank Dana) <ferdnyc@gmail.com>
c06e530 to
68d56d6
Compare
|
Done, sorry for the delay. |
|
Preview: https://cpython-devguide--1041.org.readthedocs.build/versions/#supported-versions Chrome on macOS
Firefox on macOS
Safari on macOS
|
|
Really, Firefox!??! Augh! 😞 |
|
To be fair, it was "Really, Chrome!??! [sic] Augh!" before, heh... |
|
Firefox on Linux looks good, even if I horizontally squish the window (up to a certain point, it eventually breaks the "end-of-life"). Screenshot
|
Setting
:widths:leads to weird wrapping, as some columns are too narrow. Just letting Sphinx figure it out, OTOH, looks fine. Let the software be smart.Signed-off-by: FeRD (Frank Dana) ferdnyc@gmail.com