Missing docs for https://github.com/adityatelange/hugo-PaperMod/pull/1364

[jimangel]

Describe the bug https://github.com/adityatelange/hugo-PaperMod/pull/1364 landed, it would be good to cover in the docs what needs to be done to use / impact / migrate.

I don't think it's a huge deal, but I was doing some different things with chroma and took a bit to resolve because css files were overriding the new approach.

Ref: https://github.com/jimangel/jimangel.io/commit/a78a7563ee45b1a2c57a3c395033be6c4da015da

[chkuendig]

I encountered a similar issue. post-single.css has the following block that's overriding chroma:

.post-content pre code {
    display: grid;
    margin: auto 0;
    padding: 10px;
    color: rgb(213, 213, 214);
    background: var(--code-block-bg) !important;
    border-radius: var(--radius);
    overflow-x: auto;
    word-break: break-all;
}

The PR says

Users can change syntax-highlight theme using: hugo gen chromastyles --style=stylename > assets/css/includes/chroma-styles.css but the rule pasted above will take precendence.

what's the correct way to handle/override this behaviour? I was trying to use my own different chroma styles, but that obviously won't work if there's a !important property set here to fix the background to a color different from the style in assets/css/includes/chroma-styles.css.

Is it possible this behaviour itself is a bug? Or am I missing something?

Update: I tried to clear these rules in my custom.css with the following (text color also was overwritten with some of these rules)

.post-content pre code ,
.post-content .highlight:not(table) ,
.post-content .highlight table
 {
    background: unset !important;
    color: unset !important;
}

there's still the following in chroma-mod.css

.chroma {
    background-color: unset !important;
}

which directly conflicts with the background set by the chroma-style.css so I don't think there's a good way to adopt this other then just override the whole file with my own chroma-mod.css...

Any hint on how to actually use my own chroma styles would be appreciated.

[jimangel]

Is it possible this behaviour itself is a bug? Or am I missing something?

I ran into this when trying to have two .css files for light and dark mode. I had one code-block-bg background for light and one background for dark.

When I was trying to fix this, after upgrading, I eventually stripped all the custom chroma away and used a theme (and noticed the same thing you are pointing out).

Instead of fighting the statically set !important code-block-bg, I just left it.

The original author might have assumed that forcing the background color (for both via background: var(--code-block-bg) !important;) is the best option vs. change/toggle based on mode. You can test this out by adding a monokailight theme via hugo gen chromastyles --style=monokailight > assets/css/includes/chroma-styles.css.

I wouldn't mind having light/dark mode support for the code block background, but I can get by with monokai in both settings.

[adityatelange]

Hi,

Describe the bug #1364 landed, it would be good to cover in the docs what needs to be done to use / impact / migrate.

I don't think it's a huge deal, but I was doing some different things with chroma and took a bit to resolve because css files were overriding the new approach.

Ref: jimangel/jimangel.io@a78a756

There is no impact as such if you are using no customization PaperMod. Of course there can be if you have customized it.

If you have disabled HLJS and using own chromastyles, all you need to do is move your chromastyles css to assets/css/includes/chroma-styles.css.

I encountered a similar issue. post-single.css has the following block that's overriding chroma:

This we are doing it from very long time and is not introduced with this PR.

Chromastyles have their own background color set for each theme and this may or may not look good with PaperMod. Making users use only a few themes isn't an option either which will add more css to support each theme. The PR sticks to what we had by default from a long time.

[yunyit]

which directly conflicts with the background set by the chroma-style.css so I don't think there's a good way to adopt this other then just override the whole file with my own chroma-mod.css...

I have the following setup in assets/css/extended/blank.css :

.post-content pre code , 
.post-content .highlight:not(table) ,
.post-content .highlight table
 {
    background: unset !important;
    background-color: var(--code-bg) !important; /* support light/dark */
    color: var(--secondary) !important; /* support light/dark */
}

and assets/css/includes/chroma-mod.css unchanged for

.chroma {
    background-color: unset !important;
}

I choose trac for

hugo gen chromastyles --style=trac > assets/css/includes/chroma-styles.css

and it works well :)