After an update to the newest version of Documenter.jl some things changed, most of which are positive changes. The colors of backticked code (e.g. a_typical_variable) has changed. It is now foreground red, and used to be only foreground black (and bg gray). Is there a way to change these colors?
I try to write the documentation in way that directs the readers attention to what I think is important, and the change from gray background to red foreground changes where the readers attention ends up. In particular in documentation with a lot of backticked code, e.g.:
Thanks. I was hoping for a higher-level solution. A custom css-file seems error prone, e.g. in the next release of documenter. To be a bit more honest, I think this change of color is not a good idea, and I think other package maintainers would agree. I would be okay if I could add a flag somewhere. I do understand that one cannot expect to get a flag for every “old behavior”. Recommending a lot of package maintainers to hack css-files is like asking for trouble. It seems julialang’s main pages use more or less the default Documenter setting. If the red colors for backticked code are adapted there, I will stop complaining, assume my opinion is an outlier, and just do the css-solution.
Design choices are always somewhat subjective. I think that CSS is the best way to keep these things customizable. You should always pin to a specific version in any case.
The “solution” (if this should be seen as a problem) seems to be to add a custom css-file as @findmyway pointed out like given here Resizing images in docs - #8 by Tamas_Papp. The entry that needs to be modified is in documenter-light.css:
code {
background-color: rgba(0, 0, 0, 0.05);
color: #da0b00; /* would need to be removed */
font-size: 0.875em;
font-weight: normal;
padding: 0.1em; }
While customizability is great, improving the default style also makes sense. Maybe open an issue in the GitHub repos? It would be nice if you can convince Documenter.jl devs. I also think emphasizing inline code too much does not make sense.