This replaces the metadata that Hugo's own schema.html template had
been providing, but does so in JSON-LD notation rather than via the
use of <meta> tags (this is Google's currently recommended form of
specifying this markup). There are a few exceptions where I did not
follow the conventions used in Hugo's template, for example the use
of up to six images from a post's frontmatter, because Google's tool
only recognizes one image, as well as different logic for a post's
publish and modified dates (using enableGitInfo = true).
Using this new markup, Google's Structured Data Testing Tool is now
able to understand site metadata much better (before it was reading
none).
The implementation here is a mix of the elements and types from the
official Schema.org types—for example, Blog and BlogPosting—as well
as from Google's search documentation. Note that Google's docs are
geared towards AMP, where some metadata is required, while for non-
AMP pages the metadata is just recommended.
We will have to re-evaluate this in the future, for example to add
height and width information to image metadata.
See: https://schema.org/Blog
See: https://schema.org/BlogPosting
See: https://developers.google.com/search/docs/data-types/data-type-selector
See: https://search.google.com/structured-data/testing-tool
As of Hugo 0.18 .Site.Pages now returns all pages, including pages,
home, taxonomies, etc, and you are expected to filter them by their
"kind". There is a new variable .Site.RegularPages which returns a
range of "regular" pages like in pre-0.18 Hugo.
In this instance we are limiting the range to pages with the type
"post", so our current behavior works, but I'd rather be consistent
with other ranges we're using, like on the homepage and taxonomy
list pages.
See: https://github.com/spf13/hugo/releases/tag/v0.18
Subresource integrity allows user agents to verify that a fetched
resource has been delivered without unexpected manipulation[0]. I
put theme assets in a json configuration file and save the hashes
to a TOML file that Hugo loads via its theme data mechanism[1].
[0] https://www.w3.org/TR/SRI/
[1] https://gohugo.io/extras/datafiles/
It seems this is actually the preferred way to do it, but something
in the Bootstrap v4 Alpha 6 release—perhaps the upgraded version of
Normalize.css with that release—caused our styles to be overridden
and now I realize that it should have never been working before!
The theme really needs some config options in order to look decent,
so I will change the wording here from "optional" to "recommended".
Hopefully some users actually read this rather sparse readme, as
there have been several GitHub issues opened due to misconfigured
sites.
If the user's config doesn't have [params.sidebar] defined they get
errors when trying to build the site. It's better if we just check
that this config block is defined before trying to use it, and then
add something to the docs telling people that the site looks really
bad without this defined.
Since we're using cleancss there is no need to compress or optimize
anything in the node-sass step. Also, the Bootstrap project itself
is using the expanded output style as well so we should too.
The Bootstrap project itself uses this, so I think we should just
use it as well. As an added bonus we actually even save 2KiB from
the size of the generated style.css.
When both sharing and Disqus blocks are present, the Disqus block
needs a top margin. Otherwise, if sharing is hidden, then the hr
following the blog post's article tag already provides enough of
a bottom margin.
Bring the Disqus comments inside the <article> tag. The article has
a sizeable bottom margin seprating it from the blog footer, and if
Disqus comments are active they appear after this margin, and this
looks ugly.
Semantically, I think the comments should actually be inside the
article tag anyways (since they are directly related), as well as
further wrapped in article tags, but we don't control the code that
Disqus injects so we'll have to make do with this.
See: https://www.w3.org/TR/html5/sections.html#the-article-element
Prepending the site's URL to relative links was a hack but at the
time I couldn't understand why href="#" didn't take us to the top
of the page. It turns out that this was because of the <base> tag
that I have now removed.
It was screwing up relative links like the ones in footnotes. I'm
not sure why I added it in the first place, actually, as the docs
specifically say "specifies the base URL to use for all relative
URLs contained within a document".
See: https://developer.mozilla.org/en/docs/Web/HTML/Element/base