Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork853
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 ourterms of service andprivacy 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
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 commentedFeb 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 thetables to have the same width, setting the (That's with
Or, it could be that itdid 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 thedata isn't static, fixed column widths willinevitably 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. Butonly in Firefox, I guess, which... |
In theoriginal 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% widthand letting Sphinx figure out the distribution, OTOH, looks fine. Letthe software be smart.Signed-off-by: FeRD (Frank Dana) <ferdnyc@gmail.com>
Done, sorry for the delay. |
Really, Firefox!??! Augh! 😞 |
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