Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 964
Don't force table widths in versions.rst#1041
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
Uh oh!
There was an error while loading. Please reload this page.
Conversation
hugovk commented Feb 1, 2023
CAM-Gerlach commented Feb 2, 2023
ezio-melotti left a comment
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.
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.
ferdnyc commented Feb 2, 2023 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
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!" |
ferdnyc commented Feb 2, 2023
No, actually, FWIW the current live page does indeed still lay out un-wrapped in Firefox. But only in Firefox, I guess, which... |
ezio-melotti commented Feb 4, 2023
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 |
hugovk commented Mar 14, 2023
@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 68d56d6Compareferdnyc commented Mar 14, 2023
Done, sorry for the delay. |
hugovk commented Mar 14, 2023
ferdnyc commented Mar 14, 2023
Really, Firefox!??! Augh! 😞 |
CAM-Gerlach commented Mar 14, 2023
To be fair, it was "Really, Chrome!??! [sic] Augh!" before, heh... |









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