aboutsummaryrefslogtreecommitdiff
path: root/layouts/partials/style.html
Commit message (Collapse)AuthorAgeFiles
* Revert "Do not touch div.highlight styles"Jan Raasch2021-08-131
| | | | This reverts commit d3a86c7c6d23cfe6f82d7d8405e3ab522e693a22.
* Do not touch div.highlight stylesJan Raasch2021-08-091
| | | | Closes #25
* fix: code highlighting using Chroma (#20)Andrew Jorgensen2021-04-131
| | | | | | | | | | | | | | | | | | | | | | | | | Chroma sets `color` (usually) and `background-color` directly on a `<pre>` element under a `<div class="highlight">` but the theme was interfering with those color settings from both the `code` and `pre code` selectors. Since Chroma highlighting is under a `highlight` class we can `unset` the colors that are set by the `code` selector elsewhere, so that under a `<code>` element that's under a `<div class="highlight">` it will just inherit from the `<pre>` above it where Chroma sets all it's colors. The `color: initial;` instead of `color: unset;` is needed because some Chroma styles don't set a default text color, and if you use `unset` instead that lets the browser use a lighter default text color when using a dark color scheme. That's a sort of long winded way of saying that I think I've fixed the color interference problem in a way that won't mess with anything else in the theme. I've tested this on a wide selection of Chroma styles, with both light and dark color schemes and it seems to work correctly in all cases. Which is to say that Chroma appears to have full control of both `color` and `background-color` for code blocks that it's highlighting. Fixes #19
* feat: add dark color scheme for dark modeJan Raasch2020-10-011
| | | | see https://github.com/HermanMartinus/bearblog/pull/51
* chore: initial commitJan Raasch2020-09-031