Skip to content
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

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

Open
12rambau opened this issue Sep 7, 2023 · 7 comments
Open

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

12rambau opened this issue Sep 7, 2023 · 7 comments

Comments

@12rambau
Copy link
Contributor

12rambau commented Sep 7, 2023

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
Copy link
Collaborator

2bndy5 commented Sep 8, 2023

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

@12rambau
Copy link
Contributor Author

12rambau commented Sep 8, 2023

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

@2bndy5
Copy link
Collaborator

2bndy5 commented Sep 8, 2023

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
Copy link
Contributor Author

12rambau commented Sep 8, 2023

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
Copy link
Collaborator

2bndy5 commented Sep 8, 2023

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:

// a rule specifically designed for autosummary tables
// this overrides `.md-typeset code { word-break: break-word; }`
table.longtable.docutils.data.align-default {
tbody > tr > td > p > a.reference.internal {
> code.xref.py.py-obj.docutils.literal.notranslate {
> span.pre {
word-break: normal;
}
}
}
}

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
Copy link
Contributor Author

12rambau commented Sep 8, 2023

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
Copy link
Collaborator

2bndy5 commented Sep 9, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants