It's getting intense

I'm in the deep end for sure now.

• markdeep server side rendering is not working right now. None of the diagrams are drawing properly.
• I mostly got through some marked/highlight.js related issues to let me get a clean way to insert ansi escape sequence code blocks, but now what I'm dealing with on that front is the fact that plain markdown code blocks are not getting hljs plaintext language classes added. Sure it's a pretty small issue, but it's indicative of one more further issue with marked-highlight that I'd like to see resolved before rolling out my site.

So, still on the home stretch as far as I can see but I couldn't really say anymore if this isn't a train of long tail issues and I have no faith anymore I'll be able to go live by today, and I thought it was gonna be yesterday, yesterday.

I figured out the root problem with marked-highlight, and I made a fork with the fix so I can continue onward.

All I need are two things now:

• fix markdeep styling and SSR rendering
• add basic nav to each html page

The first one might actually be a big one... See I'm already losing track of stuff, I thought I had markdeep totally licked earlier including with separated rendering... I'm gonna do some git spelunking to confirm I'm not going crazy, because the markdeep output is completely jacked right now.

Got markdeep rendering now, it was just a simple oversight of mine, i was exporting the "inline" conversion function earlier, which of course wasn't including any mathjax or markdown stylesheet content into the HTML output, so of course diagrams and math were all broken. I'm fully aware even with this current state although most math works there is some wonkiness in the rendering. But I am really committed to SSR right now and I have little interest in digging into the particulars of markdeep's MathJax implementation and would want to pursue KaTeX in Marked for any math rendering pursuits for sure.

Home stretch actual

I'm in home stretch actual right about now.

The focus is now on navigation. Although it is easy and tempting to directly build navigation structures in html (as this is considered fairly basic HTML competency after all), one of my goals I hadn't clearly set down earlier in my planning, though I hinted at it, is that I would be authoring pages and laying them out in my git repo and that structure would be automatically replicated in the site, with all necessary navigation elements pre-generated. This to me is a basic blog system UX need, and I'm building a bespoke blog system, so I really couldn't neglect this part. I can do something really basic though because the bulk of the work and fun of a site like this is in the CSS.

Here's what I'm planning for this final step now:

• Navigation should probably be in a semantic <nav> element on the page and it will have basic structure with a link to the (home) landing page, one to the about page, and (at the same level) one section to a few other pages adjacent in the page structure.
• There will be a TOC page since my site will have moderately deeply nested structure as I made a recursive directory walker mechanism in the build script, so I may as well take advantage of it. There will also be a concept of tags to categorize pages into, and I will have a little interactive behavior in there to dynamically filter the nav tree based on topics you select. I was going to put this toc tree into my landing page. No it may belong in a blog specific landing page, but the main page will have special design treatment... None of this needs to be figured out at this time, but I'll go ahead and make the separate blog landing page because it would already be insane without that.
• I think only the bare minimum CSS needed to make that nav presentable is enough for go-live. i need to do it. I'm also pushing giscus integration until after go-live. Very naive of me to think of it as a single step, but it might be possible. I already made my giscus repo, for what that's worth.

I have now built nav generation. I opted for directly rendering some structure that I think should stand the test of time, though that's certainly questionable:

function buildNav(curriedParent, page, idx, arr) {
  const prev = Math.max(0, idx - 1);
  const next = Math.min(arr.length - 1, idx + 1);
  // console.log('====== nav page:', page.path, `[ ${prev !== idx && arr[prev].path} <-- ]`, `(↑ ${curriedParent.path} ↑)`, `{ --> ${next !== idx && arr[next].path} }`);
  let nav = `<nav><div class="self">${page.path}</div><ul>`;
  if (prev !== idx) nav += `\n<li class="left">${arr[prev].path}</li>`;
  nav += `\n<li class="up">${curriedParent.path}</li>`;
  if (next !== idx) nav += `\n<li class="right">${arr[next].path}</li>`;
  if (page.children) {
    // console.log('---- children nav:', page.children.map(c => c.path));
    nav += `\n<li class="children"><ul>${page.children.map(c => c.path).map(cp => `<li>${cp}</li>`).join('\n')}</ul></li>`;
  }
  nav += `\n</ul></nav>`;
  page.nav = nav;
}