Reminder: You Can Stitch Together Lots of Little HTML Pages With Navigations For Interactions

提醒：你可以通过页面跳转将许多小型 HTML 页面串联起来，实现交互功能

I wrote about building websites with LLMs — (L)ots of (L)ittle ht(M)l page(s) — and I think it’s time for a post-mortem on that approach: I like it. 我曾写过关于用 LLM（(L)ots of (L)ittle ht(M)l page(s)，即“大量小型 HTML 页面”）构建网站的文章，我认为现在是时候对这种方法进行复盘了：我很喜欢它。

I’ve tweaked a few things from that original post but the underlying idea is still the same, which I would describe as: Avoid in-page interactions that require JavaScript in favor of multi-page navigations that rely on HTML and are enhanced with CSS view transitions (and a dash of JS if/where prudent). 我对最初的文章做了一些微调，但核心理念保持不变，即：尽量避免使用需要 JavaScript 的页内交互，转而采用依赖 HTML 的多页面跳转，并辅以 CSS 视图过渡效果（在必要时适当添加少量 JS）。

As an example, on my blog I have a “Menu”. It doesn’t “expand” or “slide out” or “pop in” or whatever else you can do with JS. Instead, it navigates to an entirely-new page that is focused on just the menu options of my site. 举个例子，我的博客里有一个“菜单”。它不会通过 JS 实现“展开”、“滑出”、“弹出”等效果。相反，它会跳转到一个全新的页面，该页面仅专注于展示我网站的菜单选项。

I say “navigates” because it’s just a link — <a href="/menu/"> — and it functions like a link, but the navigation interaction is enhanced by CSS view transitions. Have a newer device with a modern browser? Great, you get a nicer effect. Have an older device, or an older browser, or JS disabled, Et al.? It’ll still work. If you can follow a link — which is the most fundamental thing a browser can do — it will work. 我之所以说“跳转”，是因为它本质上就是一个链接 —— <a href="/menu/"> —— 它的功能也确实像链接一样，但这种跳转交互通过 CSS 视图过渡得到了增强。如果你使用的是带有现代浏览器的较新设备？太棒了，你会获得更精美的效果。如果你使用的是旧设备、旧浏览器，或者禁用了 JS 等？它依然可以正常工作。只要你能点击链接——这是浏览器最基本的功能——它就能运行。

So how’s it all work under the hood? In essence, all the pages have a link to the menu (except the menu page). When you navigate to the menu, that link is changed to an “X” which “closes” the menu. The closing is still just a link (back to /) but it’s enhanced with JS to actually do a “back” in the browser history. This makes it so “opening/closing” the menu doesn’t add an entry to your browser history. 那么，它的底层原理是什么呢？本质上，所有页面都有一个指向菜单的链接（菜单页面除外）。当你跳转到菜单页时，该链接会变成一个“X”，用于“关闭”菜单。这个关闭操作本质上仍然是一个链接（返回到 /），但通过 JS 增强，使其能够执行浏览器历史记录的“后退”操作。这样一来，“打开/关闭”菜单就不会在你的浏览器历史记录中增加条目。

As a simplified example, the code looks like this: 作为一个简化示例，代码如下所示：

<!-- Normal page -->
<nav>
  <a href="/menu/">
    <svg>...</svg>
  </a>
</nav>

<!-- Menu page -->
<nav>
  <a href="/" onclick="document.referrer ? history.back() : window.location.href = '/'; return false;">
    <svg>...</svg>
  </a>
</nav>

The document.referrer checks whether we came to this page as a navigation (mostly likely from within the blog itself) or via a direct visit (i.e. somebody typed it into the URL bar, unlikely but possible) which is how I suss out whether there’s a meaningful history.back() run or not. document.referrer 会检查我们是跳转到该页面的（很可能是从博客内部跳转），还是通过直接访问（即有人在地址栏输入 URL，虽然不太可能但并非没有可能），这就是我判断是否可以执行有效的 history.back() 的方式。

While this solution seems simplistic, it was not a simple thing to arrive at. It required me to spend time thinking about what was essential to navigation, how that interaction could work across multiple pages, and how I could ensure page size stayed small so the interaction was both fast and robust while remaining intuitive to use. In other words, the approach shaped the design. 虽然这个解决方案看起来很简单，但要得出这个结论并不容易。我花了很多时间思考什么是导航的核心要素，这种交互如何跨多个页面工作，以及如何确保页面体积保持精简，从而使交互既快速又稳健，同时保持直观的使用体验。换句话说，这种方法塑造了设计本身。

Turns out, if you have a website and you think of the browser as a way to navigate documents — rather than a runtime to execute arbitrary code and fetch, compile, and present them — things can be a lot simpler than our tools often prime us to make them. 事实证明，如果你拥有一个网站，并将浏览器视为浏览文档的工具——而不是执行任意代码、获取、编译并呈现它们的运行时环境——那么事情会比我们现有的工具所引导我们去做的要简单得多。