| Commit message (Collapse) | Author | Age | Files |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This reverts commit 9863ab4f50b81073367145c3edc5a991bada5e53.
Whoops. I should update my local version of `hugo` 😊.
This broke the build, see https://github.com/janraasch/hugo-bearblog/actions/runs/3057300422/jobs/4932310672
|
| |
|
|
| |
The demo is hosted at https://janraasch.github.io/hugo-bearblog/, but currently the link is »/blog«, so we end up at https://janraasch.github.io/blog with a `404` 🥹.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out my original proposal for #20 was correct, but not for the
reasons I thought. We need to set both `background-color` and `color` to
`initial` on `div.highlight pre` because that's where Chroma sets those
colors (including the default `color` if configured). Setting to
`initial` there makes it so that if the selected style *doesn't*
configure a default color, we'll use the `initial` color, which is going
to be the right choice because the reason style author left that unset
because they didn't consider dark color schemes messing with their
style. Then we `unset` the colors on `div.highlight code` because
otherwise the `code` colors from the theme will override the colors that
would otherwise be inherited from Chroma's `<pre>` element.
Stricly speaking I can't say that setting `background-color` to
`initial` is required, because I haven't found a Chroma style that
*doesn't* set a `background-color`, but I figure it's possible (at least
for a light theme) and it makes sense to fix it just in case, and causes
no harm otherwise.
|
| |
|
|
| |
This reverts commit d3a86c7c6d23cfe6f82d7d8405e3ab522e693a22.
|
| |
|
|
| |
Closes #25
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Adds a .Site.Params.dateFormat setting to let users specify a Hugo-style
date format string for content. Previously, the date format was
hardcoded to "02 Jan, 2006", presumably to match the original BearBlog
style. This format gets used by default if the new "dateFormat" setting
is absent from the site config.
|
| |
|
|
|
|
|
|
|
|
| |
Fixes #6.
To be honest I did not think about this at all. I simply copied the code from the original »Bear Blog«
https://github.com/HermanMartinus/bearblog/blob/master/templates/base.html#L7
It seems like iOS ignores the declarations of user-scalable, minimum-scale, and maximum-scale, as of iOS 10, see https://sitebulb.com/hints/mobile-friendly/the-viewport-meta-tag-prevents-the-user-from-scaling/ so we might as well remove this.
|
| | |
|
| |
|
|
| |
see 0c3efa6
|
| |
|
|
| |
see https://github.com/HermanMartinus/bearblog/pull/51
|
| |
|
| |
Allows this theme to be used for sites that do not have a blog.
|
| |
|
