Link color using default indigo instead of custom primary
#4755
Comments
|
Thanks for reporting. Does it also happen with the latest beta? Please check #4714. |
|
Thanks for the suggestion! I just tried 9.0.0b4 but stumbled upon an error building/serving the site: That's with the same Trying to isolate the issue now, but I'm not exactly sure where to look, because |
|
Ok, found the cause: turns out we had a Anyway, back to the original question: yes, I can reproduce the same behavior with the latest beta, except that using
|
Could you please report this in #4714? That way we won't forget to add it to the changelog. The format changed and the nameless placeholders were removed in v9. Regarding the issue: I see. The problem is that it is impossible to anticipate and cater to all use cases that users employ to override the CSS. There will always be some combinations that need extra work. I will investigate if this can be fixed, but otherwise I would kindly ask you to make the CSS selector more specific. This will work in any case. |
|
Okay, I think I found the cause. First of all, if you set your colors on :root {
--md-primary-fg-color: #8c1515;
--md-primary-fg-color--light: #b1040e;
--md-primary-fg-color--dark: #820000;
--md-accent-fg-color: #b1040e;
--md-accent-fg-color--transparent: #b1040e0a;
}This does not match the documentation, which I'll update in a second. In fact, we changed it recently (can't find the issue right now, GitHub please improve issue search). The problem is that when you override the variables as part of a color scheme, the typeset variable is not changed and will keep the value that was set on the mkdocs-material/src/assets/stylesheets/main/_colors.scss Lines 48 to 50 in 1a7616a The slate scheme overrides all variables anyway, which is why it doesn't extend the mkdocs-material/src/assets/stylesheets/palette/_scheme.scss Lines 31 to 118 in 1a7616a Yes, it's not ideal, but the problem is that there are so many different combinations of enabling primary and accent colors and overriding stuff, that it is absolutely impossible to cater to all of those cases. [data-md-color-scheme="sherlock"] {
--md-primary-fg-color: #8c1515;
--md-primary-fg-color--light: #b1040e;
--md-primary-fg-color--dark: #820000;
--md-accent-fg-color: #b1040e;
--md-accent-fg-color--transparent: #b1040e0a;
--md-typeset-a-color: var(--md-primary-fg-color);
}This is only the case because you define a new color scheme. I'm closing this issue as not fixable, but it is actually fixable by you, the user, by providing the additional variables that you want overwritten. I'm sorry for the inconvenience. |
squidfunk
added
bug
|
I made up my mind: I changed it to "fix available" because it can be fixed with one additional line. |
|
Thanks @squidfunk !
Sure, done. And thanks for the pointer!
I'm just adding an extra CSS with a custome But I see your point about the need to redefine all the variables.
Looking forward to that fix or documentation update ;) |
|
Actually, I can easily reproduce the original issue just by cloning the MkDocs Material repo, and following the docs to create a custom color scheme.
|
|
Yes, as I said, it's just not possible with custom color schemes. Very few users do that, actually, so it's nothing we can optimize for. Most users override colors on |
|
Got it. So if it's not possible to do it anymore, would it be worth updating the documentation to remove the Custom color schemes section? |
|
Yes, PR appreciated. Something that notes that if you use a custom color scheme, you need to redefine all deduced variables. As said, it's not necessary if you just override colors on |
|
Sorry, but I'm a bit confused here: if the only way to override colors is to do it on Right now, in the documentation, there are two approaches proposed: If the only working way is to use 1., then 2. should probably be removed from the documentation to avoid any confusion. |
|
A custom color scheme would need to enumerate all variables again in order to override all of them. Otherwise for some the defaults would be used, as they are "locked in" one level aboce the We could remove custom color schemes from the documentation, but I put it there for users to know what it's actually possible to create those. The documentation is incomplete though, as it should mention those shortcomings due to technical limitations. For example, you might want to create your own dark theme, which only applied certain colors to the dark mode of your documentation. For this, you could override slate, or create a new scheme. |
Contribution guidelines
I've found a bug and checked that ...
mkdocsorreadthedocsthemescustom_dir,extra_javascriptandextra_cssDescription
This looks a lot like #4620, except the custom primary color is correctly applied to the header, but not to
<a>hyperlinks, which appear to still be using the defaultindigocolor.Expected behaviour
Hyperlinks use the custom
--md-primary-fg-colorcolor.Actual behaviour
Hyperlinks use the default
indigocolor.Steps to reproduce
With the following
extra_css:and this in
mkdocs.yml:the site renders like this:
Hyperlinks are rendered as #4051b5 instead of #8c1515 like the header.
When changing the
extra_csssyntax to use custom colors instead of a custom color scheme, things seem to work as expected.With no
paletteinmkdocs.yml, and the following asextra_css:hyperlinks are correctly rendered as the custom
--md-primary-fg-color:Package versions
3.10.91.4.28.5.11+insiders.4.26.6Configuration
System information
The text was updated successfully, but these errors were encountered: