Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

Merged
ezio-melotti merged 1 commit intopython:mainfromferdnyc:no-forced-tbl-widths
Mar 14, 2023

Conversation

ferdnyc
Copy link
Contributor

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

@hugovk
Copy link
Member

This does look better to me.

In Chrome on macOS:

Before

image

After

image

ferdnyc reacted with thumbs up emoji

@ezio-melottiezio-melotti self-requested a reviewFebruary 1, 2023 20:26
@ezio-melottiezio-melotti self-assigned thisFeb 1, 2023
@CAM-Gerlach
Copy link
Member

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.

BeforeAfter
imageimage

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.

Copy link
Member

@ezio-melottiezio-melotti left a 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:

  1. Make the columns wide enough to fit their content, and prevent it to be split on two lines
  2. 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
Copy link
ContributorAuthor

ferdnyc commentedFeb 2, 2023
edited
Loading

I added these widths for two reasons:

  1. Make the columns wide enough to fit their content, and prevent it to be split on two lines

Unfortunately, that's the exact thing it's failing to do, but removing the:widths: easily achieves.

  1. Make the two tables have the same widths and therefore be aligned

If you just want thetables to have the same width, setting the:width: 100% option on both might be better than setting column widths explicitly. Granted, thecolumns won't align between the two tables, but... I'm not sold on that being important, TBH. It looks fine without it, at least to me:

image

(That's with:width: 100% set on both tables, but:widths: still removed.)

Admittedly I think I only tested it on Firefox, which might explain different behaviors on Chrome it other browsers.

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!"

@ferdnyc
Copy link
ContributorAuthor

Admittedly I think I only tested it on Firefox, which might explain different behaviors on Chrome it other browsers.

Or, it could be that itdid originally fit, but some values have gotten wider/narrower since then.

No, actually, FWIW the current live page does indeed still lay out un-wrapped in Firefox. Butonly in Firefox, I guess, which...¯\_(ツ)_/¯

@ezio-melotti
Copy link
Member

IIRC there was a discussion about them in the original PR, and eventually I decided to keep them.

In theoriginal discussion:widths: auto was suggested, and at the time it didn't seem to work too well, however I tried again now and it seems to work (even the preview in the original discussion looks ok now).

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).

If you just want the tables to have the same width, setting the:width: 100% option on both might be better than setting column widths explicitly.

This sounds like a good compromise. I tested locally with:width: 100% and no:widths: and it looks ok. With:widths: auto it also looks ok, but I think that's already the default and can be omitted.

Granted, the columns won't align between the two tables, but... I'm not sold on that being important, TBH. It looks fine without it, at least to me

Agreed -- aligned columns are nice to have, but hardly essential.

IOW, I'm fine with replacing the current:widths: with:width: 100%.

CAM-Gerlach reacted with thumbs up emoji

@hugovk
Copy link
Member

IOW, I'm fine with replacing the current:widths: with:width: 100%.

@ferdnyc Please could you make this change?

CAM-Gerlach and ferdnyc reacted with thumbs up emoji

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>
@ferdnyc
Copy link
ContributorAuthor

@ezio-melotti@hugovk

Done, sorry for the delay.

@hugovk
Copy link
Member

Preview:https://cpython-devguide--1041.org.readthedocs.build/versions/#supported-versions

Chrome on macOS

image

Firefox on macOS

image

Safari on macOS

image

@ferdnyc
Copy link
ContributorAuthor

Really, Firefox!??! Augh! 😞

@CAM-Gerlach
Copy link
Member

To be fair, it was "Really, Chrome!??![sic] Augh!" before, heh...

ferdnyc reacted with thumbs up emoji

@ezio-melotti
Copy link
Member

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

image

@ezio-melottiezio-melotti merged commit5803a02 intopython:mainMar 14, 2023
@ferdnycferdnyc deleted the no-forced-tbl-widths branchMarch 24, 2023 05:00
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@hugovkhugovkhugovk approved these changes

@ezio-melottiezio-melottiezio-melotti approved these changes

Assignees

@ezio-melottiezio-melotti

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

4 participants
@ferdnyc@hugovk@CAM-Gerlach@ezio-melotti

[8]ページ先頭

©2009-2025 Movatter.jp