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

Variables shouldn't use color-mod outside of initial palette generation #163

Open
dsmmcken opened this issue Jul 29, 2021 · 4 comments
Open

Comments

@dsmmcken
Copy link
Contributor

I have customized theme where I re-defined root variables for primary/warning/danger/etc to match my colors scheming.

The new variables as used in blockquote (and admonitions, separate but related to this issue) introduce new colors not defined by the base palette, and are hardcoded with color-mod. For someone who has customized their theme with just redefining the base set of colors, this introduces a whole bunch of hardcoded new root variables that also now need to be customized to match.

6 * 2 base colors
--ifm-color-XXX-contrast-background
--ifm-color-XXX-contrast-foreground

3 block quote colors
--ifm-blockquote-base-background
--ifm-blockquote-background-color
--ifm-blockquote-border-color

and 6 new admonition colors
--ifm-alert-background-color-highlight

For a total of 21 new colors that now need to be manually specified, for theming.

Suggestions:

I used the color generator https://docusaurus.io/docs/next/styling-layout#styling-your-site-with-infima initially to generate the primary/success/etc dark/darkest/dark versions of my color palette, so a) could extend that to add the new contrast color mods, so there's at least a tool. I like that less, but its workable.

Second, make a hard rule of not using color-mod outside of generating the base palette. Where its used in admonitions and block-quote make theming difficult as it introduces a bunch of new root variable to override.

Third consider a different approach approach to palette generation. If you are okay with HSL https://caniuse.com/?search=hsl , then could do something like https://blog.maximeheckel.com/posts/the-power-of-composition-with-css-variables/ allowing someone to specify just 6 colors base colors, and have everything composed from those.

@slorber
Copy link
Collaborator

slorber commented Jul 29, 2021

Agree that I'm not a fan of having all those hex codes, it makes it harder to customize.

The HLSA solution looks great to me and this is definitively a solution I'd like to use more in the future.

Do you want to work on this refactor?
If you are able to open a PR with the exact same colors (or very close) as we currently have, but with a different method natively supported (not color-mod(), I'd be happy to merge it. Alert colors have been picked quite carefully to match contrast accessibility requirements with a quite high score so we really want to keep them (or at least get a similar score)

Most people are using the default admonition design, and despite the boilerplate needed to customize them it remains possible, so this refactor is not a high priority for me now, but agree that it should be done at some point

@dsmmcken
Copy link
Contributor Author

dsmmcken commented Jul 29, 2021

Looked further: --ifm-alert-background-color-highlight could use #RRGGBBAA instead of color-mod to add alpha, and maintain themeability. That's an easy fix. Same with --ifm-blockquote-background-color.

--ifm-blockquote-base-background introduces a new yellow that is only very slightly off the existing warning-foreground color. Any reason to not just use that, since its so similar? @lex111

Nevermind, that's still a pcss concatenation. Forgot what you can and can't do in the browser, doh.

Those changes would remove 9 variables that would require separate theming, I can live with the contrast-foreground/background new variables. But we should update the generator https://docusaurus.io/docs/next/styling-layout#styling-your-site-with-infima

I can open PR's for both if acceptable

@slorber
Copy link
Collaborator

slorber commented Aug 2, 2021

Hey, I'm not sure what you are suggesting exactly.

The goal to me is not to remove new/existing css variables (those remain useful for customization). But more to create some kind of dependency graph between the css variables, so that modifying one primary var would cascade and update the css variable color variants with native mod functions such as hlsa.

If you feel the docusaurus generator can be updated to do more and simplify customizing a Docusaurus site, I'd be happy to have a PR for that. Even having a dedicated page with a full-color config engine where the user could easily modify live the Docusaurus site and then just copy-paste the CSS would be a useful tool. Currently it's just a best-effort to generate some kind of color palette, but I would be happy to have something better.

@slorber
Copy link
Collaborator

slorber commented Aug 13, 2021

Starting to use this technique on our own website and it looks like it's working fine: facebook/docusaurus#5351

We'll need a few refactors to port something to Infima, and also be careful about annoying breaking changes for users, but this is definitively something I'd like to try make happen

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