只要内容结构完整，样式不是问题~
LXGW WenKai ( https://lxgw.github.io/ )是一个比较不错的中英文等宽字体，可以试试 。
1 个赞
原生支持 org 格式为 hugo 拉了不少粉
Netlify ，服务器到期了试试
这种频繁部署的话，会不会很烦 
org-roam hugo
不会，因为每个步骤都可以自动化，比如我之前提问过的
就是在自动化批量 ox-hugo 这一步。
看来你是没看懂我的意思，但更多的是你可能没用过Hugo 
-
比如你在本地先用Hugo生成站点基础文件，然后配置主题等等，全部调试好了以后，直接把整个目录push到Github。
-
好了！上面就是搭建。
-
接下来在Github上的Action里面点击那个新建，会有一堆的模版让你选，你选了就行了，甚至不用修改。
-
然后你在Netlify上新建站点并链接到Github，选择构建用的仓库。那么以后只要你Github有变更就会自动构建
-
文章怎么写？每次都要构建？肯定不像你理解的那样，甚至和动态网站差不多。比如你打开Github，在文章目录下面在线新建md文件写入内容，然后commit。好了，现在又开始自动化构建部署了。要么就是本地在文章目录下面新建md文件写入内容，然后commit。
- 看我写的挺多，实际操作就非常简单：Hugo本地构建调试，push到Github，新建Action选择模版，登录Netlify新建站点并链接Github
- 发布文章：本地或者在线，在文章目录下新建 文章md文件，写完commit，剩下的都是自动化完成，和你无关
- 建议实际动手试试，比你想的和看到的简单太多了
刚去dev.to逛了一下，置顶的是个Netlify悬赏，附上链接：Join us for the Netlify Dynamic Site Challenge: $3,000 in Prizes! - DEV Community
想搞3000美元就去试试 
我目前是用这种方式部署的 - 如何使用 hugo-theme-virgo 主题#部署篇 。
Netlify 没有用过，按你的描述应该是类似于 Vercel 。目前一直在使用服务器，到期了可以试一下你说的这种方法。
太长了大概扫了一眼，肯定比那个方便。你看我上面写的使用教程多简短，详细点也就加几个命令。而且用Action部署也是选模板就行。可以说是纯小白操作了，强烈建议尝试一下，几分钟就搞定了
你那个我没有用过。还有就是现在搞博客本身就赚不了钱，Netlify的速度也挺快了，还不用备案，成本最低化。
当然要是嫌速度不够极致快，可以加个cdn，或者备案域名加个国内的。当然也可以直接用腾讯，阿里，七牛的oss部署
1 个赞
org-mode 编辑，然后导出 markdown 放在 iA Writer 里面修订，然后通过 iA Writer 直接发布到用 Ghost 搭建的博客，部署在 DigitalOcean。
另外一个是 org-roam 编辑，ox-hugo 导出，直接推到 github，会自动更新到 hugo 搭建的博客，部署在 Vercel。
1 个赞
花点心思总能做到的吧。大部分人只是没听说过 Html 还有 validator 这种东西……听说过的还有不以为然和不以为意（比如我）的人。
我更关心
- 我的网页在 a11y 上有没有做好，对残障人士有没有比较好的支持。这点 validator 检查不出来
- 加载速度怎么样
- 移动端有没有正确布局，手机和平板查看网页的体验好不好
1 个赞
我有一个非常长的用生成器（Jekyll, Hexo, Hugo）生成博客的历史，目前 主站 是用 Hugo 的。但是我觉得这种生成器强迫我写模板代码，以及我更乐意写 React 而不是原生 Dom 操作。所以我最近做了一个基于 Pandoc 和 Next.js 的生成器，把 Pandoc 的语法树编译到 jsx. 不过目前问题还是挺多的，可以看看 效果
相对来说，模板还是方便一些的~
差不多，生成器使用历程如下：
Jekyll > Hexo > Hugo > ox-publish > Hugo
其中，ox-publish 和 Hugo 的编译速度最快。
ox-publish 因为可以只编译当前文件成 html ，所以最快。
我做的这个东西，pandoc 部分的编译速度肯定没问题，应该不输 hugo 的，但是 next.js 编译整个项目确实会比较慢。（不过比 hexo 好像还是快一些的）
以及，另一个诱人的地方是，可以用几乎任何 markup language 写博客，比如 markdown，org-mode，甚至是 latex 和 typst（但这俩 pandoc 支持也一般，听说 latex 的 parser 就是糊了一个）
And the HTML5 validator takes care of most of my issues.
这个链接主要批评的是 HTML4/XHTML validation，并且肯定了我在用的 HTML5 validator
很多 HTML 生成还在用 HTML4 的 mindset，或者兼容 IE，根本没有用好 semantic markup。
a11y 的第一标准就是用 valid HTML 和 CSS，而且 HTML5 validator 的 error 里就包括了 img 必须要 alt 属性的规则。如果这样还不以为意的话，那只能是嘴硬了。
因为 a11y 也有专门的 validator，而你的网站不管主页还是文章部分 failed 和 warning 都比我多
https://qualweb.di.fc.ul.pt/evaluator/https%253A%252F%252Fayayaya.org%252Fzh-cn%252F
如果不用 JavaScript，加载速度肯定会快。我还考虑了 Emacs eww 或者 w3m 这种不支持 JavaScript 的 reader 显示的效果，比如这个代码块行号在 eww 里还能保持显示效果，是我自己实现技巧后提议给 DocBook XSLtng 的。
Pandoc 靜态渲染代码块高亮，粗看起来还像那么回事，其实既没考虑到 eww 里的效果，在支持 CSS 的浏览器里连避免复制到行号都没做。
1 个赞
org-mode + css …阿里云99一年的ubuntu服务器
我的问题是，HTML Validator 的作用是什么呢？或者说，完全符合规范的 HTML，它的好处是什么呢？（跨平台？更好的 a11y 支持？）这点我确实不太懂，感觉也没什么人在研究这个。但是通过比较仔细地避免生成 invalid 的 HTML，这个问题肯定是容易解决的。没人解决，或者 Hugo 本身也没做好，这某种意义上说只是 Hugo 的开发者不重视（不知道）这点，而不是静态生成器这种 approach 本身做不到生成 valid 的 HTML.
我承认我的网站目前是有很多问题，所以我决定彻底切换到自己可以控制的东西上。
至于代码高亮，Pandoc 默认的 HTML Writter 问题还是比较多的，也不太好和 React 结合，所以我现在的办法是把代码块直接送给 React，通过 JS 侧的 prism.js，在 next.js 构建时渲染。不过这有一些其他的问题，我对这块的处理目前也不是很满意。
关于 eww 之类的，我觉得支持这个很 awesome，但是目前确实不在我的考虑范围内
MarkText + Hugo + Gitlab Pages.
考虑一下 Obsidan 啊，哈哈~
当用 JavaScript 等通过 DOM 操作页面没有得到预期效果时，及时排除因为 parse 问题导致得到非预期 DOM tree 的可能，节约 debug 时间。
哪怕浏览器的 HTML parser 有一定纠错功能，如果有 syntax error，就不能保证 DOM 在不同实现上的一致性，因为浏览器本身不见得会报错，到时候 debug 起来会很惨。
用 XSLT3.0 输出 HTML，因为是遵守 HTML data model 实现的，可以容易地杜绝生成 HTML 有 syntax error。而 Hugo 在主题模版里都能找到没有匹配的 </p> 这样的 syntax 问题，实在说让人担忧 HTML 生成的质量。
实际上在工具链最后挂个 HTML tidy，配上合理的选项， 就能自动解决大部分问题。