Part 26: Metadata and Short Browsers

More devblog

Project Scope and ToDos

Static Site Generator that can build the blog and let me host it on Github Pages
I want to write posts in Markdown because I'm lazy, it's easy, and it is how I take notes now.
I don't want to spend a ton of time doing design work. I'm doing complicated designs for other projects, so I want to pull a theme I like that I can rely on someone else to keep up.
Once it gets going, I want template changes to be easy.
It should be as easy as Jekyll, so I need to be able to build it using GitHub Actions, where I can just commit a template change or Markdown file and away it goes. If I can't figure this out than fk it, just use Jekyll.
I require it to be used by a significant percent of my professional peers so I can get easy answers when something goes wrong.
I want source maps. This is a dev log site which means whatever I do with it should be easy for other developers to read.

Also the sitemap plugin looks cool. Should grab that later.
So does the reading time one.
Also this TOC plugin mby?
Use Data Deep Merge in this blog.
Decide if I want to render the CSS fancier than just a base file and do per-template splitting.

~~Can I use the template inside of dinky that already exists instead of copy/pasting it?~~

~~Is there a way to have permalinks to posts contain metadata without organizing them into subfolders?~~

Day 26

Wait... what am I using the subtitle metadata for? Maybe that should go under the title on post pages? Yeah let's do that.

{% raw %}

                        {% if '/posts' not in page.url %}
                        <p class="header">{{ description }}</p>
                        {% endif %}
                        {% if '/posts' in page.url and subtitle %}
                        <p class="header">{{ subtitle }}</p>
                        {% endif %}

{% endraw %}

Short Browsers

Also, there's a chance the user can really make the browser short if they do it may cause the footer elements to overlap, so let's try and get rid of that.

Using @media (min-width: variables.$large-mobile) and [height argument] I'll hide specific fixed elements in my makeshift sidebar based on window height. By using and (max-height: 850px) I can restrict fixed elements to appear only when there is room for them.

I'll hide the table of contents when the window is 850px or smaller with @media (min-width: variables.$large-mobile) and (max-height: 850px) and hide the taglist and footer at shorter heights so if the window is very short, we'll only have the title.

Actually... I'd prefer not to totally hide the Table of Contents, but have it return to place above the content if the browser is too short. While I'll keep the CSS Media Query and rule for the tags and footer as is, I can switch the #toc-container rule to be and (min-height: 962px)

But wait... the element is not going to scroll when it gets too high. Hmmm. Let's try a containing element... hmm no that's not it by itself. Oh, let's set a max-height on the content itself. Hmm, it makes it a little narrow. Let's try and attach that scrollbar somewhere else.

Ok, I'll use the container div I set up when I was playing with getting max-height working and set my overflow CSS on that. Oh yeah, that looks much better.

git commit -m "Fix height and positioning for short browser windows"

Autolinks for Git Commits?

Ok, I found some interesting ideas for traversing the Github API to get the actual commit links that I can auto apply to links here. Finding the strings will be it's own interesting task but for now I am experimenting with the API with the following requests:

None are exactly right, but I might be able to walk backwards through parent commits if I start at the HEAD. I think I'll also want to cache commits so I don't have to walk the tree of commits on every build.

git commit -m "Add repo URL for future API calls."

Ok, I know I said I'd lock scope, but this one last expansion! I want to have useful links on the homepage and a blogroll as well. Easy enough to do right? This is the last extra feature, I promise! I'm going to add them as non-post collections in their own folders at src/links and src/blogroll. I'll follow the same pattern I did with posts and projects and create a base json file with default values including the initial collection "tag" and the template I want to use (which won't be the standard one). As an example, I'll put a file at src/blogroll/blogroll.json that has these valeus:

{% raw %}

{
	"layout": "fwd.njk",
	"description": "Aram is regularly reading",
	"tags": [ "blogroll" ],
	"date": "Last Modified"
}

{% endraw %}

Good stuff! Now I need a template that can handle forwarding users to the correct off-site location. There's some fun and fancy ways to do this with Netlify I know, but I'm not using Netlify. So basic is the goal.

I'm going to use isBasedOn as the YAML metadata for the origin URL. This is broadly applicable if I write posts that are not intended to forward, so it means less metadata fields to get confused over and syncs with the Schema.org property, which I like to use for this sort of thing. For the page itself, I'm going to steal an iteration of the template from Bit.ly and make some modifications. I'll give it a title, a canonical link, and a JSON-LD block. Finally, the key to all this is a META refresh tag with the refresh time sent to 0 so it forwards immediately.

Here's the final template (for now).

{% raw %}

<html>
    <head>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <link rel="canonical" href="{{ isBasedOn }}" />
        <meta http-equiv="Link" rel="canonical" content="{{ isBasedOn }}" />
        <meta http-equiv="refresh" content="0; URL='{{ isBasedOn }}'" />
        <title>Fight With Tools Redirect: {{title}}</title>
		<script type="application/ld+json">
        {
            "@context": "http://schema.org",
            "@type": "BlogPosting",
            "headline": "{{title}}",
            "description": "{{description}}",
            "mainEntityOfPage": {
                "@type": "WebPage",
                "@id": "{{ isBasedOn }}"
            },
            "isBasedOn": "{{ isBasedOn }}",
            "isPartOf": {
                "@type": ["CreativeWork", "Product", "Blog"],
                "name": "Fight With Tools.dev",
                "productID": "fightwithtools.dev"
            }
        }
    </script>
    </head>
    <body>
        <a href="{{isBasedOn}}">moved here</a>
    </body>
</html>

{% endraw %}

And here's a YAML statement in src/blogroll/hacktext.md.

{% raw %}

title: "Hack Text"
description: "Thinking about Narrative"
date: 2021-09-27 22:59:43.10 -4
isBasedOn: "https://hacktext.com"
tags:
  - Personal Blog

{% endraw %}

Looks like it works! I think for a fast put-together, this works just fine and lets me do what I want! Good stuff. If I'm going to open a scope, I might as well close it on the same day. But no more of that, let's focus on closing the last remaining todos for next days.

git commit -am "Set up blogroll and links and write up day 26"

Oops forgot to add the raw tags to escape my code.

git commit -am "Add escaping tags to day 26

Touching up this post and realized, I didn't expand the scope, the reading log was already in there, lol.

Add a technical reading log to the homepage

git commit -m "Touching up day 26 post"

Previous Day Next Day

Project Scope and ToDos

Day 26

Short Browsers

Autolinks for Git Commits?

Blogroll and Links