jbms / sphinx-immaterial

Adaptation of the popular mkdocs-material material design theme to the sphinx documentation system
https://jbms.github.io/sphinx-immaterial/
Other
177 stars 28 forks source link

classes table doesn't take the full width of the article #288

Closed 12rambau closed 2 days ago

12rambau commented 10 months ago

I have some small classes in my project with very short descriptions. When using immaterial along with autoapi, the classes table get reduce making it inconsistent with the Functions one:

image

Is it wanted ?

2bndy5 commented 10 months ago

If you mean the table width being adaptive to its contents, then yes, that is expected.

12rambau commented 10 months ago

ok I'll find the appropriate css selector to change it in custom.css and post it here before closing the issue.

2bndy5 commented 10 months ago

Tried doing this already... Found that removing box-size: inherit changes the width of the entire table, but the rows/headers need additional tweaking.

Please also remember, the Material design rules are fundamental to this theme (and its upstream source in mkdocs).

12rambau commented 10 months ago

I added the follwing to my custom.css and it works as expected:


/* make autosummary tables use all the width available */
table.autosummary {
  width: 100% !important;
}

table.autosummary tr:not(:last-child) {
  white-space: nowrap !important;
}

table.autosummary td:last-child {
  width: 99% !important;
}

Of course as it's my custom one I've been very lazy on the selector description and used !important instead.

image

If it's not a wanted feature feel free to close my issue, if not I can try to find the exact selector in your scss.

2bndy5 commented 10 months ago

Glad to see you got it working. I wouldn't call this a wanted feature. Most of our CSS (& JS) is from upstream mkdocs-material, and we try to keep the changes minimal to make merging in updates from upstream easier.

Since your workaround is more specific to autosummary (something autoapi probably uses underneath), I think what you were expecting is how auto-summary works for other themes that actually use Sphinx basic theme's CSS (this theme is an exception to that assumption).

If you think it necessary that the autosummary tables should be absolutely wide, then I think there may be a place for that after: https://github.com/jbms/sphinx-immaterial/blob/22fd15f3d71c0f08a33713b4f25221406ea1a305/src/assets/stylesheets/main/_api.scss#L273-L283

BTW: we're the reason that autosummary tables have their own CSS class 😉. So the above SCSS rule could be updated now that they've released that change.

12rambau commented 10 months ago

I was doubting so I check the template I'm maintaining (pydata-sphinx-theme) and yes, the autosummary tables are taking the full width of the page (https://pygadm.readthedocs.io/en/stable/api/pygadm/index.html#package-contents). I'm no expert on the mkdocs ecosystem but I never saw tables like the autosummary ones so my guess is that such a change should be harmless as it's not covered by materialDoc itself.

2bndy5 commented 10 months ago

Like I said, there's room for autosummary-specific changes in src/assets/stylesheets/main/_api.scss.

2bndy5 commented 2 days ago

I'm closing this as it isn't a popular request.

Furthermore, using !important in our SCSS would trigger linter errors. The fact that !important is used in the proposed solution suggests that there might be a regression or other CSS conflict (or maybe the selectors just need to be more specific somehow).