Description
MarkBind styles inline code inside a highlight so that the highlight shows through it, rather than letting the code keep its usual opaque chip:
/* markbind.min.css */
mark code { background: #ffffffd4 }
[data-bs-theme="dark"] mark code { background: rgba(255, 248, 198, .25) }
Neither rule ever applies. Both are outranked by the highlight.js theme stylesheets, which style the same element with two classes:
/* codeblock-light.min.css (and markbind.min.css) */
.hljs.inline { background: #f8f8f8 }
/* codeblock-dark.min.css */
.hljs.inline { background: #444 }
| selector |
specificity |
mark code |
(0,0,2) |
[data-bs-theme="dark"] mark code |
(0,1,2) |
.hljs.inline |
(0,2,0) |
Two classes outrank two elements, and also outrank one attribute plus two elements, so inline code inside <mark> always keeps its ordinary code-chip background.
Effect
In light mode the accidental winner is #f8f8f8. It is near-white, close enough to the intended translucent chip that nothing looks wrong, which is probably why this has gone unnoticed.
In dark mode the winner is #444. Against the default --bs-highlight-bg (#664d03) it is merely muddy, but on any lighter highlight ground it reads as a dark hole punched through the middle of the highlight band. The <mark> stops looking like one continuous stripe.
Steps to reproduce
-
site.json with "style": { "darkMode": true }.
-
Put this on any page:
==If the `.jar` file is smaller than 5MB, most likely JavaFX libraries are not inside it.==
-
Build, view in dark mode, and inspect the <code> element.
Expected: computed background-color is rgba(255, 248, 198, 0.25), per [data-bs-theme="dark"] mark code.
Actual: computed background-color is rgb(68, 68, 68), from .hljs.inline.
The same substitution happens in light mode (rgb(248, 248, 248) instead of #ffffffd4); it is just far less visible.
Suggested fix
Raise the specificity of the two mark code rules so they clear .hljs.inline:
mark code.hljs { background: #ffffffd4 }
[data-bs-theme="dark"] mark code.hljs { background: rgba(255, 248, 198, .25) }
Two things worth deciding alongside it:
- The dark rule also needs a
color. Once the chip is light, the dark code theme's #dcdcdc text sits on it at roughly 1.2:1. The light side is already covered by .hljs.inline.no-lang { color: #e83e8c }; the dark side has no counterpart.
- Scoping to
.no-lang may be safer. A language-highlighted snippet inside a <mark> carries dark-theme token colours that will not read on a light chip either, so leaving those with their own dark ground may be preferable to giving them a chip they cannot be read on.
Environment
MarkBind v7.2.1
Issue crafted by Calude, Opus 5
Description
MarkBind styles inline code inside a highlight so that the highlight shows through it, rather than letting the code keep its usual opaque chip:
Neither rule ever applies. Both are outranked by the highlight.js theme stylesheets, which style the same element with two classes:
mark code[data-bs-theme="dark"] mark code.hljs.inlineTwo classes outrank two elements, and also outrank one attribute plus two elements, so inline code inside
<mark>always keeps its ordinary code-chip background.Effect
In light mode the accidental winner is
#f8f8f8. It is near-white, close enough to the intended translucent chip that nothing looks wrong, which is probably why this has gone unnoticed.In dark mode the winner is
#444. Against the default--bs-highlight-bg(#664d03) it is merely muddy, but on any lighter highlight ground it reads as a dark hole punched through the middle of the highlight band. The<mark>stops looking like one continuous stripe.Steps to reproduce
site.jsonwith"style": { "darkMode": true }.Put this on any page:
Build, view in dark mode, and inspect the
<code>element.Expected: computed
background-colorisrgba(255, 248, 198, 0.25), per[data-bs-theme="dark"] mark code.Actual: computed
background-colorisrgb(68, 68, 68), from.hljs.inline.The same substitution happens in light mode (
rgb(248, 248, 248)instead of#ffffffd4); it is just far less visible.Suggested fix
Raise the specificity of the two
mark coderules so they clear.hljs.inline:Two things worth deciding alongside it:
color. Once the chip is light, the dark code theme's#dcdcdctext sits on it at roughly 1.2:1. The light side is already covered by.hljs.inline.no-lang { color: #e83e8c }; the dark side has no counterpart..no-langmay be safer. A language-highlighted snippet inside a<mark>carries dark-theme token colours that will not read on a light chip either, so leaving those with their own dark ground may be preferable to giving them a chip they cannot be read on.Environment
MarkBind v7.2.1
Issue crafted by Calude, Opus 5