Add additional-theme option

[expikr]

Closes #2048

This allows users to specify additional themes without replacing the presets.

Example usage

book.toml

[output.html]
additional-css = ["orange.css"]
additional-theme = ["Orange"]

orange.css

Click to expand

.orange {
    --bg: #f6f6ef;
    --fg: Black;

    --sidebar-bg: #ff6600;
    --sidebar-fg: Black;
    --sidebar-non-existant: color-mix(in srgb, var(--sidebar-bg) 75%, Black);
    --sidebar-active: White;
    --sidebar-spacer: color-mix(in srgb, var(--sidebar-bg) 95%, Black);

    --scrollbar: #8F8F8F;

    --icons: #747474;
    --icons-hover: #000000;

    --links: #828282;

    --inline-code-color: Black

    --theme-popup-bg: #fafafa;
    --theme-popup-border: #cccccc;
    --theme-hover: #e6e6e6;

    --quote-bg: #e9e9ed;
    --quote-border: #8f8f9d;

    --table-border-color: hsl(0, 0%, 95%);
    --table-header-bg: hsl(0, 0%, 80%);
    --table-alternate-bg: hsl(0, 0%, 97%);

    --searchbar-border-color: #aaa;
    --searchbar-bg: #fafafa;
    --searchbar-fg: #000;
    --searchbar-shadow-color: #aaa;
    --searchresults-header-fg: #666;
    --searchresults-border-color: #888;
    --searchresults-li-bg: #e4f2fe;
    --search-mark-bg: #a2cff5;
}

Limitations

• The theme class needs to specify ALL the variables, otherwise they default to no-style.
  Can we figure out an easy way to derive the variable values from the presets?
• The syntax highlighting defaults to that of an assumed light mode (see here).
  What would be the most appropriate way for the theme class to declare itself as a dark-based or light-based theme and have the correct syntax highlight selected?

[ghost]

Is there anything that needs to be done before this can be merged upstream? Myself and a few people in the Catppuccin discord were curious as to the status of this since this PR would greatly help out our theming project for mdBook

I am more than willing to help out where I can with anything that needs to be finished up.

[ghost]

@ehuss forgot to ping you in my original comment. Please see #2059 (comment)

[tmandry]

Thanks, I think this would help with my use case. Since I thought about implementing this independently I'll leave some comments for the benefit of the maintainers.

• The theme class needs to specify ALL the variables, otherwise they default to no-style.
  Can we figure out an easy way to derive the variable values from the presets?

I think this is fine for now. A theme inheritance mechanism would just add complexity and should be done later.

• The syntax highlighting defaults to that of an assumed light mode (see here).
  What would be the most appropriate way for the theme class to declare itself as a dark-based or light-based theme and have the correct syntax highlight selected?

The highlight CSS is easy enough to override with selectors like .my_theme .hljs-type. In a future change the builtin themes can be refactored to use this instead of depending on the javascript logic as they do now.

The only thing this doesn't work for is the editor theme. Maybe there is a CSS-only way to style that or maybe we'll need to extend the configuration to specify whether the theme is light or dark. Either way since the editor is an optional feature, I think it's fine to merge this PR as-is.

[tmandry]

It would be ideal to decouple the theme name in the UI from the class name used for the theme.

[tmandry]

I opened #2594 with a smaller diff that requires no JS logic.