虽然对于一个博客而言，内容才是关键，但我还是花了很多时间在博客系统上。
手写 HTML
最初之时，因为我对技术的偏执，我没有选择常见的页面生成器，选择了手写 HTML 的方案。纯正的 HTML 和 CSS。能不用 JS 就不用的传统就此诞生。因为基本上都是些文本，手写 HTML 的负担并不大，而且对网页呈现效果有着 100% 的操控权。
简单脚本
其实从 2021 年年后开始我就打算对我的博客进行现代化改造，但是迟迟没有完成。直到 2021 年下半年，我才确定了现代化的方向：使用 markdown 文件生成页面，同时保证 markdown 的部分可读性。这也诞生第二条传统，保证 markdown 源文本在 Github 上的渲染结果一定程度上是可读的。并据此进行了简单的改造。因为先前的博文里存在交互性的内容，所以简单 markdown 并不能满足我的需求，所以利用 markdown 的一个 bug 或者说是 feature，[foo]: #(bar) 不会被渲染，配合 python 做预处理。同时将元数据塞进注释里来避免被显示出来。之后，我打算为系统添加 tex 代码渲染功能，用了 katex 做离线渲染。我发现我没有办法在 python 上用非常优雅的方式去调用 js。而且我发现现有使用简单预处理脚本的方式，对后续添加功能和维护不是很友好。所以规范我对 markdown 的定制和使用 js 重写的计划被提上了日程。
定制与造轮子
2022 年年后，我才正式完成了 markdown 的定制草案，取名为 Puelloc Tailored Markdown，下称 PuellocMark。在 CommonMark 的基础上，我对削减了大部分不常见的语法，使 markdown 的解析工作可以尽可能的简单。并引入了 GFM 的表格扩展。对于 CommonMark 和 GFM 都没有的扩展，我都将其定义在 CommonMark 不可见的范围内。因为我希望原始的 markdown 文件在 Github 中打开也是可以阅读的。随后我大概花费了两到三周的时间完成了一份简单的解析器。然后就把网站的构建系统迁移到了 PuellocMark 上。因为 PuellocMark 的主要使用者（也可能使唯一使用者）就是我这个博客，所以之后 Bug 的发现修复或者新功能的添加都是随着博客构建系统的开发而进行。伴随着 PuellocMark 的引入，扩展功能可以与 markdown 的解析解耦，我可以更自由便捷地去添加新的扩展功能。
HISTORY
使用 Shiki 做代码着色
原本使用的是经典的 highlight.js，通常来说基于语法的都大差不差。原本还想做一个像主流代码编辑器一样通过 LSP 的语义着色，但是还没到尾就烂了。之所以换呢主要是我有差不多长这样的 rust 的代码：
fn some(a: StructA) -> StructB { StructB {} }highlight 它着不出函数参数里 StructA 那个色，在这个位置一眼就该知道是类型吧。于是就换了 Shiki 这个库，看作者应该是 Vue 的那群人做的。这个新世纪前端库，它是 style 直接写进返回的 html 里，没有弄一个 css 什么的。看了 Shiki 才知道原来 TypeScript 他们可以把代码提示一起带上去搞得就像在编辑器里一样的高级效果是用 TwoSlash 做出的。