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

Customization via CSS variables #197

Open
humitos opened this issue Nov 21, 2023 · 6 comments · May be fixed by #282
Open

Customization via CSS variables #197

humitos opened this issue Nov 21, 2023 · 6 comments · May be fixed by #282
Assignees
Labels
Accepted Accepted issue on our roadmap Improvement Minor improvement to code

Comments

@humitos
Copy link
Member

humitos commented Nov 21, 2023

I've been using --readthedocs-flyout-font-size and --readthedocs-notification-font-size and I found them pretty good. Mainly the ones for flyout since by defining one variable the rest of font-sizes are calculated based on only that variable. This is thank to the PR #181

However, we may need to calculate other variables based on a global setting. For example line-height and similar stuffs. Otherwise, when reducing the font-size it looks weird since the line-height is not reduced:

Normal style

Screenshot_2023-11-21_16-58-04

Using --readthedocs-notification-font-size: 0.8rem

Screenshot_2023-11-21_16-58-28


It's clear how the line-height is bigger in the Material for MkDocs example.

Questions:

  • Is there a simple way to "change all them together" that makes sense?
  • Should we add more CSS variables to change line-height as well? (e.g. --readthedocs-flyout-line-height)
  • What approach should we take here?
@humitos humitos added the Needed: design decision A core team decision is required label Nov 21, 2023
@zanderle
Copy link
Collaborator

I think we could have stuff like line-height depend on font-size (for example, it could use --readthedocs-notification-font-size). I don't think we need a separate CSS variable for line-height.

I think that should suffice. I don't think we need a more clever approach than that.

@humitos humitos added Improvement Minor improvement to code Accepted Accepted issue on our roadmap and removed Needed: design decision A core team decision is required labels Nov 22, 2023
@humitos
Copy link
Member Author

humitos commented Nov 22, 2023

@zanderle sounds good to me! I'm assigning this issue to you to work on when you have time 👍🏼

@humitos
Copy link
Member Author

humitos commented Nov 22, 2023

Note there are other properties that need to be adjusted as well. For example the svg.header.icon { height } is also based on rem. I'm not sure if there is an easy way to do this in a generic way, but padding and other properties will also need to be based on this setting.

@humitos
Copy link
Member Author

humitos commented Nov 22, 2023

Could use something like the following to make all the rem units relative to this particular font-size?

readthedocs-notification {
  font-size: 16px;
}

readthedocs-flyout {
  font-size: 18px;
}

@humitos
Copy link
Member Author

humitos commented Dec 13, 2023

Here is another example that doesn't look good when updating CSS variable for notification: https://sphinx-extensions--47.org.readthedocs.build/en/47/

Screenshot_2023-12-13_10-36-28

Note that I made the font-size smaller, but the icon size and the padding need to be updated accordingly as well.

@flying-sheep
Copy link

flying-sheep commented Jan 15, 2024

This issue has a generic title but the description only mentions flyout.

Is this the right issue to talk about making everything customizable using CSS variables? Because that’s what I want.
I want to easily override every single color used in e.g. the search popup by redefining four or so CSS variables.

The alternative is the the frustrating task of overriding specific properties of specific classes and have that break whenever the upstream repository changes how it does things (e.g. if this repo switches border to outline, suddenly a downstream border-color: ... frustratingly does nothing anymore)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Accepted Accepted issue on our roadmap Improvement Minor improvement to code
Projects
Status: No status
Status: Needs review
Development

Successfully merging a pull request may close this issue.

3 participants