diff --git a/content/blog/intro-to-web-accessibility/index.md b/content/blog/intro-to-web-accessibility/index.md
index e2230a4b..11463296 100644
--- a/content/blog/intro-to-web-accessibility/index.md
+++ b/content/blog/intro-to-web-accessibility/index.md
@@ -23,38 +23,12 @@ Another example is users with limited mobility who utilize specialty hardware, s
 
 Something to keep in mind is that these disabilities may not be permanent. For instance, if you fall and break your arm, you may be only using one arm while healing. Likewise, there are situational impairments as well. If you're holding a cup of coffee in one hand, you'll only be using the other for device usage. Here's a chart that outlines a few more of these examples:
 
-<table>
-	<tr>
-	  <th></th>
-		<th scope="col">Permanent</th>
-		<th scope="col">Temporary</th>
-		<th scope="col">Situational</th>
-	</tr>
-	<tr>
-		<th scope="row">Touch</th>
-		<td><img src="./one_arm.png" style="height: 200px"/><br/>One arm</td>
-		<td><img src="./arm_injury.png" style="height: 200px"/><br/>Arm injury</td>
-		<td><img src="./new_parent.png" style="height: 200px"/><br/>New parent</td>
-	</tr>
-	<tr>
-		<th scope="row">See</th>
-		<td><img src="./blind.png" style="height: 200px"/><br/>Blind</td>
-		<td><img src="./cataract.png" style="height: 200px"/><br/>Cataract</td>
-		<td><img src="./distracted_driver.png" style="height: 200px"/><br/>Distracted driver</td>
-	</tr>
-	<tr>
-		<th scope="row">Hear</th>
-		<td><img src="./deaf.png" style="height: 200px"/><br/>Deaf</td>
-		<td><img src="./ear_infection.png" style="height: 200px"/><br/>Ear infection</td>
-		<td><img src="./bartender.png" style="height: 200px"/><br/>Bartender</td>
-	</tr>
-	<tr>
-		<th scope="row">Speak</th>
-		<td><img src="./non_verbal.png" style="height: 200px"/><br/>Non-verbal</td>
-		<td><img src="./laryngitis.png" style="height: 200px"/><br/>Laryngitis</td>
-		<td><img src="./heavy_accent.png" style="height: 200px"/><br/>Heavy accent</td>
-	</tr>
-</table>
+|       | Permanent | Temporary | Situational |
+|-------|-----------|-----------|-------------|
+| Touch | <img height="200" src="./one_arm.png" alt=""><br> One arm | <img height="200" src="./arm_injury.png" alt=""><br> Arm injury | <img height="200" src="./new_parent.png" alt=""><br> New parent |
+| See   | <img height="200" src="./blind.png" alt=""><br> Blind | <img height="200" src="./cataract.png" alt=""><br> Cataract | <img height="200" src="./distracted_driver.png" alt=""><br> Distracted driver |
+| Hear  | <img height="200" src="./deaf.png" alt=""><br> Deaf | <img height="200" src="./ear_infection.png" alt=""><br> Ear infection | <img height="200" src="./bartender.png" alt=""><br> Bartender |
+| Speak | <img height="200" src="./non_verbal.png" alt=""><br> Non-verbal | <img height="200" src="./laryngitis.png" alt=""><br> Laryngitis | <img height="200" src="./heavy_accent.png" alt=""><br> Heavy accent |
 
 > Microsoft originally created this chart as part of their [Inclusive Toolkit](https://download.microsoft.com/download/b/0/d/b0d4bf87-09ce-4417-8f28-d60703d672ed/inclusive_toolkit_manual_final.pdf) manual
 
diff --git a/content/blog/minecraft-data-packs-introduction/index.md b/content/blog/minecraft-data-packs-introduction/index.md
index 60a80165..2356bb0f 100644
--- a/content/blog/minecraft-data-packs-introduction/index.md
+++ b/content/blog/minecraft-data-packs-introduction/index.md
@@ -3,6 +3,7 @@
 	title: "Minecraft Data Pack Programming: Introduction",
 	description: "Learn the beginnings of data pack development in Minecraft - using commands and functions to add custom behavior from scratch!",
 	published: '2022-06-14T21:12:03.284Z',
+	edited: '2023-09-12',
 	authors: ['fennifith'],
 	tags: ["minecraft"],
 	attached: [],
@@ -93,7 +94,9 @@ The `"pack_format": 10` in this file corresponds to Minecraft 1.19; typically, t
 
 | Minecraft Version | `"pack_format"` value |
 |-------------------|-----------------------|
-| 1.19              | `"pack_format": 10`   |
+| 1.20-1.20.1       | `"pack_format": 15`   |
+| 1.19.4            | `"pack_format": 12`   |
+| 1.19-1.19.3       | `"pack_format": 10`   |
 | 1.18.2            | `"pack_format": 9`    |
 | 1.18-1.18.1       | `"pack_format": 8`    |
 | 1.17-1.17.1       | `"pack_format": 7`    |
@@ -122,15 +125,13 @@ Note that, while a preceding `/` is needed to type these commands into the text
 
 We should now have our data pack organized as follows:
 
-```shell
-1-introduction/
-  pack.mcmeta
-  data/
-    fennifith/
-      functions/
-        animals/
-          spawn.mcfunction
-```
+<!-- filetree:start -->
+- `1-introduction/`
+  - `pack.mcmeta`
+  - `data/`
+    - `fennifith/functions/animals/`
+      - `spawn.mcfunction`
+<!-- filetree:end -->
 
 ## Installing & testing the data pack
 
@@ -189,20 +190,16 @@ In order to run a function automatically, Minecraft provides two built-in [funct
 
 We'll start with `load` &mdash; for which we'll need to create two new files in our folder structure! Below, I'm creating a new `load.mcfunction` next to our previous function, and a `minecraft/tags/functions/load.json` file for the `load` tag.
 
-```shell
-1-introduction/
-  pack.mcmeta
-  data/
-    minecraft/
-      tags/
-        functions/
-          load.json
-    fennifith/
-      functions/
-        animals/
-          load.mcfunction
-          spawn.mcfunction
-```
+<!-- filetree:start -->
+- `1-introduction/`
+  - `pack.mcmeta`
+  - `data/`
+    - `minecraft/tags/functions/`
+      - `load.json`
+    - `fennifith/functions/animals/`
+      - `load.mcfunction`
+      - `spawn.mcfunction`
+<!-- filetree:end -->
 
 Note that, while I'm using the `fennifith/` namespace for my functions, the tag file lives under the `minecraft/` namespace. This helps to keep some data isolated from the rest of the game &mdash; any files in the `minecraft/` folder are *modifying Minecraft's functionality,* while anything in a different namespace is creating something that belongs to my data pack.
 
diff --git a/content/blog/web-components-101-framework-comparison/index.md b/content/blog/web-components-101-framework-comparison/index.md
index 02f4de52..87baeacb 100644
--- a/content/blog/web-components-101-framework-comparison/index.md
+++ b/content/blog/web-components-101-framework-comparison/index.md
@@ -24,8 +24,9 @@ To showcase this, let’s walk through some of these frameworks and compare and
 While web frameworks are the hot new jazz - it’s not like we couldn’t make web applications before them. With the advent of W3C standardized web components (without Lit), doing so today is better than it’s ever been.
 
 Here are some pros and cons of Vanilla JavaScript web components:
-
-<table class="wp-block-table">     <tbody>         <tr>             <th>                 Pros             </th>             <th>                 Cons             </th>         </tr>         <tr>             <td>                 <ul>                     <li><span>No framework knowledge required</span></li>                     <li><span>Less reliance on framework</span></li>                 </ul>                 <ul>                     <li><span>Maintenance</span></li>                     <li><span>Bugs</span></li>                     <li><span>Security issues</span></li>                 </ul>                 <ul>                     <li><span>Smaller “hello world” size</span></li>                     <li><span>More control over render behavior</span></li>                 </ul>             </td>             <td>                 <ul>                     <li><span>Re-rendering un-needed elements is slow</span></li>                     <li><span>Handling event passing is tricky</span></li>                     <li><span>Creating elements can be overly verbose</span></li>                     <li><span>Binding to props requires element query</span></li>                     <li><span>You’ll end up building Lit, anyway</span></li>                 </ul>             </td>         </tr>     </tbody> </table>
+|    Pros    |    Cons    |
+|------------|------------|
+| <ul><li>No framework knowledge required</li><li>Less reliance on framework</li></ul><ul><li>Maintenance</li><li>Bugs</li><li>Security issues</li></ul><ul><li>Smaller “hello world” size</li><li>More control over render behavior</li></ul> | <ul><li>Re-rendering un-needed elements is slow</li><li>Handling event passing is tricky</li><li>Creating elements can be overly verbose</li><li>Binding to props requires element query</li><li>You’ll end up building Lit, anyway</li></ul> |
 
 To the vanilla way of doing things’ credit, there’s a bit of catharsis knowing that you’re relying on a smaller pool of upstream resources. There’s also a lessened likelihood of some bad push to NPM from someone on the Lit team breaking your build.
 
@@ -170,7 +171,9 @@ You could work on fixing these, but ultimately, you’ve created a basis of what
 
 With the downsides (and upsides) of vanilla web components in mind, let’s compare the pros and cons of what building components using Lit looks like:
 
-<table class="wp-block-table">     <tbody>         <tr>             <th>                 Pros             </th>             <th>                 Cons             </th>         </tr>         <tr>             <td>                 <ul>                     <li><span>Faster re-renders* that are automatically                             handled</span></li>                     <li><span>More consolidated UI/logic</span></li>                     <li><span>More advanced tools after mastery</span></li>                     <li><span>Smaller footprint than other frameworks</span></li>                 </ul>             </td>             <td>                 <ul>                     <li><span>Framework knowledge required</span></li>                     <li><span>Future breaking changes</span></li>                     <li><span>Not as widely known/used as other frameworks (Vue,                             React, Angular)</span></li>                 </ul>                 <p><span></span></p>             </td>         </tr>     </tbody> </table>
+|    Pros    |    Cons    |
+|------------|------------|
+| <ul><li>Faster re-renders* that are automatically handled</li><li>More consolidated UI/logic</li><li>More advanced tools after mastery</li><li>Smaller footprint than other frameworks</li></ul> | <ul><li>Framework knowledge required</li><li>Future breaking changes</li><li>Not as widely known/used as other frameworks (Vue, React, Angular)</li></ul> |
 
 While there is some overlap between this list of pros and cons and the one for avoiding Lit in favor of home-growing, there’s a few other items here.
 
diff --git a/content/blog/web-components-101-lit-framework/index.md b/content/blog/web-components-101-lit-framework/index.md
index b7702417..db1fe289 100644
--- a/content/blog/web-components-101-lit-framework/index.md
+++ b/content/blog/web-components-101-lit-framework/index.md
@@ -71,7 +71,7 @@ There are two primary differences from the vanilla JavaScript example. First, we
 
 That said, Lit components fully support the same lifecycle methods as a vanilla custom elements.
 
-The second, easier-to-miss change from the vanilla JavaScript component to the Lit implementation, is that when we set our HTML, we don’t simply use a basic template literal (`<p>test</p>`): we pass the function `html` to the template literal (`html\`<p>test</p>\``).
+The second, easier-to-miss change from the vanilla JavaScript component to the Lit implementation, is that when we set our HTML, we don’t simply use a basic template literal (`<p>test</p>`): we pass the function `html` to the template literal (``html`<p>test</p>`;``).
 
 This leverages [a somewhat infrequently used feature of template literals called tagged templates](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates). Tagged templates allow a template literal to be passed to a function. This function can then transform the output based on the string input and expected interpolated placeholders.
 
diff --git a/src/pages/collections/framework-field-guide/index.astro b/src/pages/collections/framework-field-guide/index.astro
index c65b745b..30dbf6ac 100644
--- a/src/pages/collections/framework-field-guide/index.astro
+++ b/src/pages/collections/framework-field-guide/index.astro
@@ -42,6 +42,7 @@ import WhatDoIGet from "src/views/collections/framework-field-guide/segments/wha
 <Barebones>
 	<SEO
 		slot="head"
+		pathName={`/collections/framework-field-guide`}
 		title={"The Framework Field Guide"}
 		description={"A practical and free way to teach Angular, React, and Vue all at once, so you can choose the right tool for the job and learn the underlying concepts in depth."}
 		unicornsData={[unicorns.find((uni) => uni.id === "crutchcorn")]}
diff --git a/src/pages/confirm.astro b/src/pages/confirm.astro
index 61ca0984..2add111c 100644
--- a/src/pages/confirm.astro
+++ b/src/pages/confirm.astro
@@ -10,7 +10,7 @@ const locale = "en";
 ---
 
 <Document lang={locale}>
-	<SEO title="Confirm Your Email" slot="head" />
+	<SEO title="Confirm Your Email" slot="head" pathName={`/confirm`} />
 
 	<main class="confirmMain">
 		<PageCard
diff --git a/src/pages/thanks.astro b/src/pages/thanks.astro
index 56929785..c19e268e 100644
--- a/src/pages/thanks.astro
+++ b/src/pages/thanks.astro
@@ -10,7 +10,7 @@ const locale = "en";
 ---
 
 <Document lang={locale}>
-	<SEO title="Thank You!" slot="head" />
+	<SEO title="Thank You!" slot="head" pathName={`/thanks`} />
 
 	<main class="thanksMain">
 		<PageCard
diff --git a/src/pages/unicorns/[unicornid]/index.astro b/src/pages/unicorns/[unicornid]/index.astro
index 57ed4783..d4c49e8a 100644
--- a/src/pages/unicorns/[unicornid]/index.astro
+++ b/src/pages/unicorns/[unicornid]/index.astro
@@ -23,6 +23,7 @@ const posts = getPostsByUnicorn(unicorn.id, "en");
 		description={unicorn.description}
 		unicornsData={[unicorn]}
 		type="profile"
+		pathName={`/unicorns/${unicorn.id}`}
 	/>
 	<div class="listViewContent">
 		<UnicornsPage unicorn={unicorn} posts={posts} />
diff --git a/src/pages/unicorns/[unicornid]/page/[page].astro b/src/pages/unicorns/[unicornid]/page/[page].astro
new file mode 100644
index 00000000..0fbc5368
--- /dev/null
+++ b/src/pages/unicorns/[unicornid]/page/[page].astro
@@ -0,0 +1,56 @@
+---
+import Document from "../../../../layouts/document.astro";
+import SEO from "components/seo/seo.astro";
+import UnicornsPage from "../../../../page-components/unicorns/unicorn-page.astro";
+import { getAllPostsForUnicornListView } from "utils/api";
+import { PostInfo } from "types/PostInfo";
+import { unicorns } from "utils/data";
+import { Page } from "astro";
+
+export async function getStaticPaths({ paginate }) {
+	const posts = await Astro.glob<PostInfo>(
+		"../../../../../content/blog/**/*.md",
+	);
+	return unicorns.map((unicorn) => {
+		const allUnicornPosts = getAllPostsForUnicornListView(
+			unicorn.id,
+			posts,
+			"en",
+		);
+		return paginate(allUnicornPosts, {
+			params: { unicornid: unicorn.id },
+			props: { allPosts: allUnicornPosts },
+			pageSize: 8,
+		});
+	});
+}
+
+const { page, allPosts } = Astro.props as {
+	page: Page<PostInfo>;
+	allPosts: PostInfo;
+};
+const params = Astro.params as { unicornid: string };
+
+const unicorn = unicorns.find((unicorn) => unicorn.id === params.unicornid);
+const rootURL = `/unicorns/${unicorn.id}/`;
+---
+
+<Document>
+	<SEO
+		slot="head"
+		title={unicorn.name}
+		description={unicorn.description}
+		unicornsData={[unicorn]}
+		type="profile"
+		pathName={`/unicorns/${unicorn.id}/page/${page.currentPage}`}
+	/>
+	<div class="listViewContent">
+		<UnicornsPage
+			unicorn={unicorn}
+			page={page}
+			posts={page.data}
+			allPosts={allPosts}
+			rootURL={rootURL}
+		/>
+	</div>
+</Document>
diff --git a/src/styles/shiki.scss b/src/styles/shiki.scss
index 2b0756cb..bf64b7f9 100644
--- a/src/styles/shiki.scss
+++ b/src/styles/shiki.scss
@@ -3,16 +3,27 @@
 /*
  * This code handles line of code counting
  */
-code {
+pre code {
 	counter-reset: step;
 	counter-increment: step 0;
+
+	display: block;
+	position: relative;
+	padding-left: 2.5rem;
+	tab-size: 4;
 }
 
-code .line::before {
+pre code .line::before {
 	content: counter(step);
 	counter-increment: step;
+
+	// These must be position: absolute; to avoid contributing
+	// to the tab indent size within the code block.
+	// Otherwise, the first tab is offset by the width of the line counter,
+	// leading to inconsistent tab alignment.
+	position: absolute;
+	left: 0;
 	width: 1rem;
-	margin-right: 1.5rem;
 	display: inline-block;
 	text-align: right;
 	color: rgba(115, 138, 148, 0.4);
@@ -92,7 +103,8 @@ pre.shiki div.highlight {
 	background-color: var(--cardActiveBackground);
 }
 pre.shiki div.line {
-	min-height: 1rem;
+	// must be the same value as used for line-height
+	min-height: 1.7em;
 }
 
 /** Don't show the language identifiers */