别忘了这些能让 HTML 正常工作的标签
我观看了Alex Petros的演讲，其中有一张幻灯片标题为“让HTML正确运行的咒语”。
这让我开始思考那些为确保网站在浏览器中正常运行而必须添加的基础HTML片段——就像“嘿，我刚在磁盘上创建了一个.html文件，准备用浏览器打开。里面应该放什么内容？”
以下是我想到的内容：
<!doctype html>
<html lang="en">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1.0">
为何每个都重要？
文档类型声明
<!doctype html>
若缺少<!doctype html>，浏览器可能切换至怪异模式，模拟早期非标准行为。这将改变布局、尺寸和对齐的计算方式。
<!doctype html>能确保渲染一致性。若想重温1998年的标记风格，也可用<!DOCTYPE HTML>。若完全无视社会规范，甚至可使用<!doCTypE HTml>。因大小写不敏感，上述形式均有效。
html lang
<html lang="en">
声明文档语言。浏览器、搜索引擎、辅助技术等可据此实现：
- 为屏幕阅读器提供准确发音与语音支持
- 提升索引与翻译准确性
- 应用区域化工具（如拼写检查）
- 以及更多功能…
省略该声明时页面外观正常，但许多基础网络工具可能出现错误。明确声明能让HTML周边功能更精准高效，因此我始终坚持添加此声明。
meta utf-8
该信息可由服务器作为头部返回，例如：
return new Response(
"<!doctype html><h1>Hello world</h1>",
{
status: 200,
headers: { "Content-Type": "text/html; charset=utf-8" },
}
);
但我更倾向于在HTML中设置，尤其当我创建本地文件并手动在浏览器中打开时。
<meta charset="utf-8">
这能指导浏览器如何解析文本，确保é、ü等特殊字符正确显示。
我曾多次遇到未包含此标签的文档显示异常的情况——比如我的智能引号。
例如：复制以下代码片段，粘贴到HTML文件中，在电脑上打开：
<!doctype html>
<h1>Without meta utf-8</h1>
<dl>
<dt>Smart quotes</dt>
<dd>“” and ‘’</dd>
<dt>Symbols</dt>
<dd>©, ™, ®, etc.</dd>
<dt>Ellipsis</dt>
<dd>…</dd>
<dt>Emojis</dt>
<dd>👍</dd>
<dt>Non-latin characters</dt>
<dd>é, ñ, etc.</dd>
</dl>
页面可能显示异常。但只要添加<meta charset="utf-8">标签，问题就能迎刃而解。
视口元标签
<meta name="viewport" content="width=device-width,initial-scale=1.0">
有时快速编写HTML原型时，我会欣喜地发现“太棒了，效果完全符合预期！”。但打开移动端查看时，所有内容都变得微小——“[扶额] 忘了添加meta viewport标签！”
请看这张截图：左侧忘记添加meta viewport标签，右侧则包含该标签：
你遇到过这种情况吗？只有我这样？不管怎样，添加这个标签能让HTML按预期运行，非常值得推荐。
最后但同样重要…
我知道你在想什么，我漏掉了写HTML最重要的代码片段：
<div id="root"></div>
<script src="bundle.js"></script>
哈哈。
本文文字及图片出自 Don’t Forget These Tags to Make HTML Work Like You Expect
趣闻：既非巧合，HN和paulgraham.com均未声明DOCTYPE，且以怪异模式渲染。可在开发者工具中通过评估
document.compatMode验证此现象。我遇到这个问题是因为有个用户脚本，用于在悬停元素(不限于链接)上复制文本。它通过：
[…document.querySelectorAll(“:hover”)].at(-1)
获取最内层悬停元素。在标准模式页面运行正常，但在怪异模式页面却时好时坏。
问题：作为用户，是否有简洁直接的方法强制怪异模式页面以标准模式渲染？我知道可以使用类似代码：
document.write(“” + document.documentElement.innerHTML);
但这会清空整个文档并引发大量问题。是否有更优雅的解决方案？
希望`dang`能抽空优化网站可用性。HN至今仍默认使用12px字号，在多数现代设备上显示效果极其微小。
粗略观察发现，他们似乎仍在使用约13年前公开的CSS样式：
https://github.com/wting/hackernews/blob/5a3296417d23d1ecc90…
暂且不论12pt与16pt字号的优劣，网站理应通过使用“rem”单位尊重用户的浏览器设置，但HN(主要指[1])对此视若无睹。
测试方法：尝试调整浏览器字号大小，观察哪些网站会同步更新字号。此举不仅能满足用户个性化需求，对提升无障碍访问体验也大有裨益。
[1] 经测试发现“回复”和“帮助”按钮会响应浏览器大字号设置。
自我宣传一下：我制作了这款用户样式，让HN在桌面端和移动端都更舒适。仅做微调(字号、三角标记、少量配色)，却带来显著改善，尤其在移动屏幕上效果显著。
https://userstyles.world/style/9931/
感谢分享，效果很棒，字体选择也很得我心！不过我个人觉得字重稍轻，已调整为400。
我对dang相当信任；但总体而言，我对网站所谓的“可用性更新”心存戒备。
现代设计潮流正在倒退：元素间堆砌大量留白，信息密度极低，优先适配触控界面(即超大点击区域)，还有诸多十年前就被视为劣质设计的做法。
所以HN虽有怪癖，但比起那些二十多岁设计师会把它改成什么样子，我宁愿保留现状。看看旧版reddit和新版reddit的对比，甚至他们的应用就知道了。
确保HN呈现出十五年前网页的样貌，这根本谈不上什么潮流。相对字号设置如此基础，本应归类为bug修复而非“可用性更新”。
总体上我认同，但也赞同上条评论。移动端尚可接受，但在1080p以上的桌面视图中字号过小。缩放功能虽可用却无法固定。只需在CSS中简单调整字号，就能让内容在移动端、桌面端、终端甚至太空环境下都清晰可读——比如设置 font-size:2vw 这类可缩放的单位。
移动端体验更糟。若不先缩放至目标区域，点击时会频繁误触。
确实如此，我标记或隐藏的大多数内容都是因跳过缩放步骤导致的意外操作。
> 缩放功能可用但无法保持。
或许可以尝试使用能记住设置的用户代理？比如火狐浏览器
说得对。我太久没调整缩放了都没注意到，但在HN重置后，标准高清21英寸显示器上文字宽度仅有2毫米左右。
> 但若在HN重置缩放，标准高清21英寸显示器上的文字宽度仅约2毫米。
我这台1920×1080的24英寸屏幕，像素间距0.274毫米，恰好100dpi。HN的标准文字宽度也约2毫米——用尺子贴着屏幕估算的简单测量结果。
若你连这都看不清，或许该去检查视力了。很可能需要配老花镜。我对老花镜的需求是悄然滋生的——毕竟日常要么操作路虎引擎级别的部件，要么处理砂糖粒大小的元件，后者需在SMD返修台的双目显微镜下观察，前者则大得肉眼即可轻松辨识 😉
请别这么做。HN默认的小字号恰到好处，信息密度完美。多数浏览器支持字号调节，若点错链接，用双指缩放功能即可解决。
绝不采用那种“内容需要留白和超大字体才能呼吸”的设计，也不像其他网站那样需要点击才能查看回复。这些只会让交互变得复杂。
我此刻正用iPhone SE发布这条留言，而我的视力正因年岁渐长而衰退。
没错，我要求默认字号采用浏览器标准值(16px)，并更新至符合2025年主流显示分辨率——而非2006年创建时的标准——这恰恰说明我极度渴望海量留白空间，让所有内容都能舒展呼吸。
HN是我唯一需要放大缩放的网站，下面其他用户也和我一样操作。但问题肯定出在我们身上。显然PG早在2006年就预见了未来几十年的需求。
反观之，HN是唯一无需缩小显示也能保持舒适度的网站。多数网站需调至90%，极少数才用80%。
16px字号实在太大。
听起来你的显示缩放比例有点问题？
这就像把音响系统调校成适合某张专辑的均衡效果，却断言现代母带处理永远均衡失当。系统应按标准调校，对特殊情况调整直至重新母带处理。
但我们都清楚“标准”在音量大战中遭遇了什么。
至少在移动端，我发现经常能放大显示，却几乎无法缩小。因此小字体反而比大字体更便于操作。
浏览器(及操作系统)的缩放功能本就是为辅助功能设计的；若视力允许，请用它来缩小显示。双指缩放更适用于探索那些不易察觉的内容(以及尺寸过小的触控目标)。
你显然在讽刺，但我认为“那些是旧版字号默认值”并不必然等同于“那些是糟糕的默认字号”。我个人偏好HN的默认字号。我的偏好不该凌驾于你之上，你的偏好也不该凌驾于我之上。我认为“其他网站都这样”的论调刻意回避了HN的文化特质，因此无需套用在HN的HTML设计上。
别这么做。
赞同，别把2025年的默认字号设成12px等效值。
[已删除]
你觉得“别这么做”这种回复符合指南精神吗？在我看来既不周全也不具实质意义。
内容确实需要留白。
HN的留白处理恰到好处。过多则冗余，过少则不足。
> HN至今仍默认使用等效12px的字号，导致在多数现代设备上显示异常微小。
在哪些设备(或浏览器？)上你会觉得“小得离谱”？CSS像素并非物理像素——在桌面设备上按1/96英寸比例缩放，而在智能手机等设备上则会根据人眼与屏幕的典型距离(使视角大小大致相当)进行缩放，因此高PPI显示屏上一个CSS像素可能覆盖多个物理像素。以像素为单位指定的字号在不同设备上应保持一致。我在32英寸4K显示器(137 PPI)、24英寸94 PPI显示器以及416 PPI的智能手机上，都感觉HN的字号大小完全一致。
在我的MacBook上字号并非“小得离谱”，但放大至120%能获得更佳体验。默认状态下阅读也完全没问题。
在我的标准1080p屏幕上，必须放大到200%才能舒适阅读。屏幕上依然能显示大量内容且毫无浪费。
这个字号对我来说完美，希望别搞什么“可用性更新”。
“既然我用着顺手，没必要迁就他人需求”
敢打赌99.9%的移动端用户隐藏帖子都是误操作
> 粗略一看，他们似乎仍在使用约13年前公开的CSS：
当然此后肯定做过修改。几年前的移动端体验远不如现在，显然有所改进。记得某个臭名昭著的“内联代码不换行”CSS漏洞也被修复了，但记不清是数月、数年还是数十年之前的事了。
另需说明的是，他们对邮件反馈非常积极。若您有具体需要修复的问题，甚至对优化方案有建设性建议，可发送邮件至hn@ycombinator.com。他们通常会快速回复，要么表示“感谢，好主意”，要么说明“可能不可行，原因如下”。至少这是我的亲身体验。
文本大小可通过浏览器缩放功能轻松调整。若允许Chrome记住设置，它会针对每个网站分别保存缩放比例。
12像素(自适应布局下为13.333像素)确实偏小——这完全是个合理观点，无需争论是否该放弃绝对尺寸字体而追求主观感受。
若不再参照物理尺寸校准，便不存在所谓的合理默认字号。若你选择将手机缩放比例调整为1英寸对应0.75英寸，这属于个人设置问题，而非要求网站为所有人放大字号。
我确信他们接受PR提交，不过评估CSS变更对各类设备的影响确实颇具挑战。
在我笔记本上文字尺寸完全正常。
真的吗？我在Pixel XL上觉得字体非常美观。不像其他现代网站那样占用过多空间。
无论电脑还是手机，我认为当前字号恰到好处。
如今流行加大字体，但我始终不解其用意。难道用户真的难以辨认？
我更倾向于同时查看更多信息。以前用Discord(电脑版)时，甚至切换到IRC模式并缩小字体以容纳更多内容。
你用的显示器分辨率应该很低吧？在27英寸4K显示器上，即使放大到150%，字体依然微小——我此刻输入的文本框(使用浏览器默认字号)显示效果，竟比HN评论区本身大三倍之多。
同意。我使用的是苹果雷雳显示器(2560×1440分辨率)，同样放大至150%。
我并非要求彻底重设计。16px本是浏览器默认值，如今多数网站也不再使用12px这类微小字号。
HN坚持使用12px的唯一原因，是2006年由`pg`设定时，这种规格尚属合理且符合当时标准。
没错，如今CSS支持相对单位，我们无需硬编码像素值，这让各方都受益(em、rem)。这样用户就能根据浏览器默认设置获得可用性，实现全局可配置。
1920×1080分辨率，24英寸屏幕
问题或许不在于DPI缩放？
另一方面，使用30+英寸屏幕的用户通常会坐得稍远些，这样无需转动头部就能看清所有内容。因此即使考虑DPI的网站也采用较大字体，这其实是合理的——关键不在于屏幕上元素的物理尺寸，而在于相对于眼睛的视角大小。
没错，另一位网友提到36英寸的距离。他们似乎没意识到自己属于极端情况。屏幕距离远超常规时，当然需要把所有内容都放大。
我将HN放大至150%，屏幕距离眼睛32至36英寸(端坐办公桌时)。
其他网站无需如此操作，因此我觉得12px字号对现代4K设备而言可能略显过小。
我是低视力用户，必须将HN放大到175%才能舒适阅读，这基本是我唯一需要如此极端设置的网站。
我有轻微视力问题，需要大幅放大默认字号才能舒适阅读。每个人的眼睛都不一样，视力也会随年龄变化很大。
更优方案：该功能能完美适配浏览器的缩放设置。
uBlock过滤器可实现：
||news.ycombinator.com/*$replace=/<html/<!DOCTYPE html><html/也可用Tampermonkey实现相同功能，与楼主方案效果一致。
存在更优解，但通常答案是否定的；最佳方案是让WHATWG将document.compatMode定义为可写属性而非只读属性。
更优方案是创建并保存旧节点引用(如 `var old = document.documentElement`)，在用 document.write 清空页面(仅保留空* html元素，无需序列化整棵树)后，将其重新插入到新的 document.documentElement 下。
* 需注意：您的方法无法保留html元素的属性。可通过两种方式修复：在document.write调用前主动移除子节点，并借助document.documentElement.outerHTML序列化属性(与原始实现一致)；或遍历旧元素的属性并逐个重新设置。
关于此议题，我认为浏览器始终采用标准模式渲染完全可行，或至少提供用户配置选项实现此功能。
没必要让默认模式兼容已淘汰的浏览器。
补充想法：刚读完MDN怪异模式文档，或许我会开始发送Content-Type: application/xhtml+xml，因为实在不喜欢添加doctype声明。这个标签实在太古怪，导致我原本优雅的HTML输出引擎不得不为其添加特殊处理。
我知道这是个玩笑：
<div id="root"></div>
<script src="bundle.js"></script>
但我感觉最后缺了一个闭合标签：
<main>...</main>
这能确保屏幕阅读器跳过页面所有“界面元素”，为许多用户带来极大便利。额外建议：用<nav>标签(或role=“navigation”属性)标记main区域内的导航元素。
我虽非视障人士，但曾因尝试打造超优化网站而对此产生兴趣。当时我以为取悦屏幕阅读器的最佳方式是将导航HTML置于末尾，但通过样式使其视觉上优先显示(手机端顶部导航栏，宽屏设备左侧导航菜单)。
值得称赞的是你花时间用屏幕阅读器实际测试，而非仅阅读最佳实践指南。这样做的人太少了。不同屏幕阅读器的表现略有差异，因此实际测试至关重要。值得注意的是，许多替代输入/输出设备采用相同的屏幕阅读协议，这意味着你不仅在帮助视障人士，更在服务所有使用非传统设备的用户。
导航元素应在文档和标签顺序中靠前。屏幕阅读器提供快速跳转和跳过内容的快捷键，这是用户体验的常态。部分屏幕阅读器会优先快速朗读标题而降低导航元素的优先级，因此若未立即听到导航提示，未必是程序错误，通常存在快捷方式可跳转至导航。最关键的测试点在于动态复杂组件(如按钮和表单)的语音反馈是否符合预期——例如能否准确传达进度、错误及成功状态？实现起来通常相当简单，但这正是许多应用出错的地方。
“每款屏幕阅读器的表现略有不同，因此测试实际行为至关重要。”
更正：每款屏幕阅读器+操作系统+浏览器的组合表现都略有差异，尤其在多语言React网站上。用屏幕阅读器测试网站堪称全职工作。
要是能有个工具能全面测试所有导航方式(鼠标、触控、Tab键、屏幕阅读器控制、吸气吹气摇杆、下巴摇杆、眼动追踪器、盲文终端等)下的所有组合就好了……可惜不存在。
你需要将隐藏的“跳转至内容”链接设为Tab键可访问的首个元素。
这是否会违反视觉顺序与Tab顺序一致性等规则？屏幕阅读器用户习惯跳过链接等标准导航技巧。
需说明的是，此设计同样提升文本浏览器的可用性，并优化键盘交互体验。
记得HTML支持在页面内创建全局快捷键，按下组合键即可将光标直接定位到预设位置。若我没记错，建议添加指向菜单、主内容区及其他相关区域的快捷键。
我…没get到梗——有人能解释下吗？谢谢。
虽非前端工程师，但推测这个模板代码是为加载选定的JavaScript渲染引擎，使其将内容渲染到DIV中，而非直接在页面本身显示内容。
因为“现代”网页开发者不再用标准HTML/CSS/JS编写网页，而是用JavaScript在根元素内部渲染全部内容。
这虽成“标准”，却让不支持JavaScript的浏览器彻底报废。这对SEO、无障碍访问及诸多方面(如内存、CPU和电池消耗)都是噩梦。
但嘿，这可是“现代”技术！
原文本身就存在错误的DOCTYPE声明。“DOCTYPE”与“html”之间缺少空格。此外，所有HTML属性间的空格均被移除，尽管HTML规范明确规定：“若使用双引号属性语法的属性后接另一个属性，则两者之间必须保留ASCII空格。”(https://html.spec.whatwg.org/multipage/syntax.html#attribute…) 不过浏览器似乎仍能正常解析。这很可能是HTML压缩工具自动处理的结果。实际上，该压缩工具若采用未加引号的属性值语法(如
lang=en-us id=top而非lang=“en-us”id=“top”)，本可进一步压缩字节数。编辑：在Rust的
minify-html库中可指定“enable_possibly_noncompliant”选项，就会出现这种情况。它们利用了HTML解析器必须接受此类内容的事实——尽管根据HTML编写规范这并非有效HTML，但解析规范允许如此。致所有在TFA原文与本评论间反复切换的读者：此处指的是TFA网站本身存在这些错误，而非TFA内容本身。
或许是个愚蠢的问题，但我一直困惑：既然合规解析器必须支持“doctypehtml”，为何(作者？)规范不将其视为有效HTML？为何允许这种情况——非合规HTML在合规解析器上必然能运行？
这被视为解析错误[0]：规范基本规定解析器遇到此情况时 可 拒绝整个文档，但若接受文档，则 必须 将其视为存在空格。实际中浏览器倾向于忽略所有解析错误，尽可能接受更多文档。
[0] https://html.spec.whatwg.org/multipage/parsing.html#parse-er…
> 若出现此类情况，解析器 可 完全拒绝该文档
啊，原来是我漏看了这点。感谢！规范相关条款如下：
> 用户代理在解析HTML文档时，若遇到首个不愿应用本规范所述规则的解析错误，可终止解析器。
(https://html.spec.whatwg.org/multipage/parsing.html#parse-er…)
因为可使用的文档类型声明有多种。同理“varx”无效，必须写成“var x”。
同理<ahref=“/page.html”>也是无效的。
我常使用HTML5模板处理这类情况：
https://github.com/h5bp/html5-boilerplate/blob/main/dist/ind…
颇具讽刺意味的是，当时Facebook专有的元数据行(即“og:…”行)竟包含其中。如今更名为“Meta”后，反而显得比从前更具专有属性。
或许这个名称从一开始就与元宇宙毫无关联…
它们专有吗？怎么说？开放图谱不就是个标准吗？众多机构都在使用，包括许多开源软件？
完全不是。虽然由Facebook发明，但本质上只是几行元数据，应用程序可自主选择是否读取。
由$公司发明并不妨碍其成为标准。
https://en.wikipedia.org/wiki/Technical_standard
> 技术标准可能由企业、监管机构、军事组织等私营或单方面主体制定。
PDF现为国际标准(ISO 32000)，但由Adobe发明。HTML诞生于欧洲核子研究中心，现由W3C(私营联盟)管理。OpenGL由SGI创建，由Khronos集团维护。
这些标准拥有不同的“所有权”路径，但我认为它们都是标准。
开头那句是否应为“does not”？否则后续论述反而自相矛盾。
确实是笔误，感谢指正已修正。
需要时怎么找到这个？
用DuckDuckGo搜索“html5 boilerplate”，点击官网，点“source code”，顺着路径找到index.html文件
还有人喜欢不打包直接用Web组件吗？
我可能不该承认，但我一直在用Lit Elements配合原生JavaScript代码。因为我早就停用自动补全功能了。
现在不使用TypeScript，大概相当于对很多人说“我还在用穿孔卡片”吧。
37 Signals [0] 团队以在多数产品中使用自研 Stimulus [1] 框架闻名。其CEO倡导完全不打包的开发模式，认为打包会增加额外复杂性，且阻碍他人拆解代码学习。
[0]: https://basecamp.com/ [1]: https://stimulus.hotwired.dev/
观察基于Stimulus的网站(或任何类似的SSR/超媒体应用)时，除了浅层网页设计外根本无法从中汲取实质性知识——所有关键工作都在网络请求的另一端完成。仅凭作者原文中的“data-action”或“hx-swap”标签，在缺乏服务器端代码的情况下根本无法真正学习。这意味着讨论本身毫无意义——无论是团队成员还是开源学习者，原始代码与压缩版代码本就可供参考。
更何况在 Ruby 环境下进行 JS 打包本就复杂——当 Ruby 本身无法高效完成打包任务时，唯一可靠的解决方案是调用外部二进制工具。这种做法在外界看来无异于“自掘坟墓后大谈立于死角的优越性”。相较于 Bun 项目，这种思路显得相当过时。
DHH 观点颇多，许多见解虽不失偏颇，却也非放之四海皆准的真理，况且世界早在2010年左右就已超越了他。
确实能从中领悟到无构建流程在特定规模下可行，也能窥见技术栈的构成及其大致运作机制。
但无论如何，我并非要为这种做法辩护或反对，只是指出这是DHH曾经提出过的观点之一。
说不清。若追求(基本)可读性，完全可以不压缩代码。但我职业生涯中绝不愿再放弃静态类型系统。
即使使用 TypeScript，当我开发 Web Components 而非完整框架时，也倾向于不打包。这样每个页面能精确加载所需组件。配合 HTTP/2，我乐见文件独立存在——只需哈希处理并设置不可变缓存头，即便代码变更，用户也只需拉取实际修改部分的新版本。
近年来我越来越倾向这种做法。当前浏览器对ESM的加载已相当成熟(无论是否启用HTTP/2+)。无打包的生活确实惬意。
即便是依赖关系更复杂的框架，只要在包升级时打包/分发依赖项，并通过importmap加载，体验依然良好。
目前我不会放弃TypeScript，但采用现代
“target”配置选项的TypeScript(主要进行类型剥离)体验极佳，尤其在简单的--watch循环中。停止使用自动补全功能？想听听更多细节。
我做不到。
> 还有人喜欢不打包直接用Web组件吗？
没错！不仅如此，连ShadowDOM都不用。
虽然我不赞成完全弃用TS转JS，但小项目确实更容易这么操作。不过这里有人比你更彻底地认同这个观点https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701…
我是在Lex Fridman/DHH播客中了解到这个决定的。他多次提到TypeScript让元编程变得极其困难。我能理解这种情况，但不太明白JS能实现何种元编程——虽然它普遍的动态特性我倒是明白。
幸运的是Lit支持TypeScript，所以你不必放弃它。
天啊没错，工具链越精简越好。
我不是网页开发者，恳请有人能解答：为什么这个网站以及众多类似的“现代”网站，实际内容只占据我屏幕20%的空间？
我的浏览器窗口是2560×1487。80%的屏幕是空白的。我不得不放大170%才能阅读内容。旧博客没有这个问题，它们就是正常显示。这是故意为之还是CSS设计缺陷？考虑到帖子的标题，我觉得这多少有些相关性。
你会发现报纸采用分栏排版，同样不会让文字横向延伸至屏幕边缘。这是兼顾功能与美学的排版考量。
功能层面：让眼睛横向扫视过长距离阅读会增加视觉疲劳。当然这存在争议，用户偏好各异，但限制内容宽度正是基于此原理。
从风格角度：文字若从左到右贯穿整个版面会显得“难看”，因为段落会显得“过窄”，仿佛“内容不足”且“留白过多”。关键在于实现背景与文字的视觉比例协调。当宽度极大时，段落左侧会过早截断，导致末行显得“裸露”——某些段落后会出现不规则的空白区域。虽然我无法更深入解释这种视觉不适感，但这类似于配色选择：决定性因素并非规则，而是“是否赏心悦目”。
就该网站而言，内容宽度确实很窄。但请注意每个段落词数极少，可能是出于美学考量刻意压缩。换作是我也会做同样选择。
不过，若读者必须放大170%才能阅读内容，而屏幕其他元素却未同步缩小，这可能就是CSS设计失当的表现。
报纸留白边距不足5%，但它们足够聪明地采用多栏排版。这其实是按行计价的副产品——每页内容都必须塞满信息，才能最大化利用版面价值。
我理解没必要让文本从头到尾折返显示，甚至理解设置边距的必要性，但这些都应根据屏幕尺寸动态调整。我认为问题在于固定宽度。为避免段落显得过窄，或许根据屏幕尺寸动态增大字号更合理？应该存在向浏览器指定参考屏幕分辨率的方法，使其能自动增大字号并/或调整div宽度。
你的观点没错。增大字号确实是种方法。
另一种我常用的方法是根据媒介调整每段文字量。我会刻意增减字数，只为达到个人偏好的每段3-6行视觉效果。
有时也会更频繁地合并或拆分段落来实现目标。
缩减宽度其实非常简单，且在内容类型多变时效果显著。
我明白这些细节处理看似过度，但对某些人而言确是至关重要。就像多数人成年结婚后不再注重日常着装——毕竟这已无关紧要(他们完全正确)——但时尚爱好者却会终生保持这份执着。
通常是为了营造舒适的阅读宽度。(https://ux.stackexchange.com/questions/108801/what-is-the-be…)
我怀疑这项研究是否真正有效。它发表于20年前，摘要中未提及弧度单位，全文又无法查阅，且引用时完全未考量实际呈现的内容。
若维基百科每行仅70个字符，我绝不会阅读。
说得对，当年2560p还没普及。用4K浏览的人体验肯定更糟。
可能是为了避免段落过宽。不过我得说，我浏览器默认把HN放大到150%左右。他们确实该把默认字号调大些。不过在移动端看起来还行。
我的HN也放大到170%。这设计模式很糟糕，不该让用户在每个网站都得放大字体。要么增大字号，要么确保内容至少占页面50%区域，这样对我来说就完美了。
这个网站设计于遥远的过去，属于另一个时代。这既是福也是祸，但福大于祸。正如你发现的，缩放问题可以解决。
像HN这样人气极高的网站，其界面在整个历史中几乎毫无改动，实属罕见。
我不确定，但多年前从事用户体验设计时，团队总采用固定宽度布局并居中显示。
就像HackerNews这样——内容居中且无法适配我显示器的全宽。
理解不占满宽度的设计，但除非放大显示，否则感觉像在竖屏模式的智能手机上阅读微小文字。
网站只需指定“将内容div居中并设置60%宽度”之类参数，浏览器本应自动处理剩余布局。
你的像素太小了。请为高DPI屏幕启用系统缩放功能。
我通常会添加：
这样就能“免费”获得漂亮的自动深色主题
啊这个好！或许该考虑将其设为默认选项…
为保持清晰度和规范性，尽管如今可选，我坚持将元信息置于
内。> `<html lang=”en”>`
作者或许应考虑改为：
`<html lang=”en-US”>`
是时候为国际通用英语创建“en-INTL”(或类似标识)了——它基本等同于“en-US”，但暗示使用美式国际键盘布局并去除美式表达，例如引号内的逻辑标点[1]。这样AI就能面向更广阔的受众写作(还能默认使用常规ISO单位而非英制婴儿食品单位)。
更何况，当今时代竟无法用任意键盘书写任意语言，这种状况实在荒谬——毕竟我们永远无法预知键盘后方使用者需要何种表达方式。
[1] https://slate.com/human-interest/2011/05/logical-punctuation…
我们还应推行一项标准：所有网站必须根据用户偏好的俚语骂法调整内容，无论是“你妈”、‘这蛋蛋’、“六七”，还是用Ogg Vorbis格式录制的霍屯督人舌音点击系列。
但这不正是“en”这个词本身该有的状态吗？
这两者却有着截然不同的含义，作者为何如此处理？请参阅RFC 5646 [0]：“en”表示英语且无任何额外限制，而“en-US”则指美国使用的英语。
[0] https://datatracker.ietf.org/doc/html/rfc5646
有意思。
据我所知，这允许某些屏幕阅读器选择特定的口音。浏览器也能选择合适的拼写检查器(美式英语 vs 英式英语)。
> <html lange=”en”>
s/lange/lang/
> <meta name=”viewport” content=”width=device-width,initial-scale=1.0″>
无需添加“.0”。事实上，该功能的规范存在严重缺陷<https://www.w3.org/TR/css-viewport-1/> 规定使用strtod解析数字，这取决于 区域设置，因此理论上在使用不同小数点分隔符的区域设置(如法语)中，“.0”会被忽略。
我尚未测试在任何用户代理上，当LC_NUMERIC=fr_FR.UTF-8时，是否会出现异常行为(解析为1而非1½)。
哇。这让我想起Google表格公式，其中函数参数根据区域设置用逗号或分号分隔。
更别说函数名称也会被翻译成其他语言。说实话我觉得这两点都是Excel的过错。早在谷歌出现前我就遇到过这个问题。
当电脑朗读含数字的内容时尤其恼人。53.1 km能正常读出，但53,1 km却变成“五十三(长停顿)一公里”。
> 更不用说函数也会被翻译成其他语言。
当你意识到Excel公式与正规编程语言不同——它们未必由精通英语的人编写时，这种现象就合情合理了。尤其涉及抽象数学概念时，这些内容在中学英语课上并未教授，而是在母语数学课堂中传授。
不确定现在是否依然如此，但Excel过去若遇到非逗号分隔符(如分号)的CSV文件，就无法正确打开。
很高兴地报告：这个问题至今未改，仍让我痛苦不堪。
真的吗？LibreOffice至少提供“文件>打开”菜单，可自定义分隔符及其他CSV设置，比如引号字符。
必须在Excel内部使用数据导入工具。双击打开会把所有内容塞进单个单元格…
有时双击打开明明没问题，却会在 毫无预警的情况下悄然损坏数据、修改内容甚至丢失信息，且完全无法阻止这种行为。
发现Intellij内置CSV表格编辑器和查看器那天，堪称我最幸福的日子。
Excel也有类似功能。但你不能直接双击CSV文件打开。
考虑到全球对小数点分隔符[0](及对应的千位分隔符)的分歧几乎势均力敌，这种情况难以避免。若统一采用分号作为参数分隔符，“1,000”仍会产生歧义。
[0] https://en.wikipedia.org/wiki/Decimal_separator#Conventions_…
试试苹果Numbers吧，连函数名称都会被翻译，如果你使用的是德语等地区设置，复制粘贴时还会报错。
啊哈，微软Excel连快捷键都翻译。巴西版Ctrl-s变成“下划线”而非“保存”。我每张表格最后都堆满带下划线的单元格 🙂
这种行为早于谷歌表格出现，很可能源自Excel(谷歌表格在许多地方都模仿/逆向工程了Excel的行为)。若Excel是从Lotus继承的，我也不会惊讶。
Excel和LibreOffice肯定也是这样吧？
是的
哦，原来取决于区域设置啊！我一直对这个行为感到困惑！
注意：和
标签会自动闭合，无需显式结束。此外，用
包裹标签是可选的。只要属性值不含空格等特殊字符，引号也可省略； 完全有效。
(虽然如今网站每次加载都会拉取海量JavaScript数据，这种优化显得有些多余，但尽可能精简代码的过程本身很有趣且令人满足)
这种做法在我看来永远显得粗制滥造。正确闭合标签本不需要多少功夫。相较于网站的其他任何方面，节省的字节数根本微不足道。避免不必要的div滥用反而能节省更多资源。比如确保CSS不臃肿，当然还有避免下载3MB的JS文件。
这种做法只会让语法更不规范、更难解析。真希望HTML5能彻底消除这些容错机制，让浏览器直接报错而非宽容处理。这将极大简化浏览器代码和HTML规范。
隐式元素与闭合标签自HTML诞生起便存在。它们完全消除了语言歧义，应用极其广泛，任何无法处理它们的解析器都违反规范，且无法处理现实世界中大量严格合规的HTML。
> 我希望HTML5能彻底消除这些容错机制，浏览器直接报错而非宽容处理。
W3C曾尝试在XHTML中推行此方案，却遭到网页作者和浏览器厂商的强烈抵制。没人愿意看到“死亡黄屏”。https://en.wikipedia.org/wiki/File:Yellow_screen_of_death.pn…
> 它们消除了语言中的所有歧义
对机器解析确实如此，但对人类编写和阅读而言却很有帮助。例如，当你拥有
并将其改为
就会突然出现语法错误(或在某些怪异模式下渲染为嵌套div)。
闭合标签的“冗余性”本质上就像校验和，能抵御人类编辑带来的“背景辐射”。如果你在没有闭合标签自动补全功能的编辑器中手写HTML，那本身就是错误的做法。没错，这种做法曾经很常见，对语言而言确实是种有用的向后兼容/新手友好特性，但这并不意味着你应该在清楚自己在做什么时还使用它。
听起来你正走向XHTML的道路。XHTML的兴衰历程已有详尽记载，若你感兴趣可以深入研究。
但 我 的总结是：它失败的根源在于严格文档规范对人类而言过于苛刻。当浏览器竞争尚存时，那些对无效内容“尽力而为”的渲染者最终赢得了市场。
XHTML的优劣已在讨论串中反复提及，我对此心知肚明。
> 当浏览器竞争尚存时，那个对无效内容“尽力而为”的渲染者才是赢家。
没错，我的观点是：仅因向后兼容性支持而继续编写“无效”代码毫无必要。你似乎忽略了我评论的90%，或者你回复错了对象？
我对HTML有效性要求极严，但规范中明确规定<p>和<li>的闭合标签可选。而<br>、<img>和<hr>的闭合标签是 <em>禁止</em> 使用的。类似XML的自闭合斜杠在HTML中毫无意义。
<script>的闭合标签是必需的。但若有人将其视为XML处理，就会写成<script src=”…” />。这种写法会失败，因为script元素要求闭合，而该斜杠在XML中毫无意义。
我认为有效性很重要，但必须依据实际规范衡量有效性，而非你期望或认为应有的标准。真正了解规则本身无可替代。
你是在故意曲解吗？我清楚它们是可选的。我的论点是：没有理由在HTML中省略它们。C语言中空格(大多)可选，难道这意味着省略空格是好做法？当然，br标签无需闭合标签，因为它内部没有内容。这究竟如何成为省略p标签闭合的论据？XML标准与当前讨论无关，因为我从未主张“开始像对待XML那样处理HTML”。
我开始怀疑自己是否误解了，但绝非故意为之。
将闭合标签作为通用规则可能让读者误以为其存在具有可靠性。此外某些情况下闭合标签是被禁止的。因此根本无法制定简单统一的规则。
语法允许某件事并不意味着它是好主意，这正是几乎所有语言都配备代码检查工具的原因。
我认为确实存在一条普适规则：所有非空元素都应显式闭合。空元素仅有14种，要求读者掌握它们并不苛求。正如你所言：“真正了解规则本身无可替代”。
我的意思是，你的方法需要记住哪15个元素可以省略闭合标签(否则你会错误地解析文档——比如认为br标签需要闭合的可能性，和认为p标签可以嵌套的可能性一样大)。
有人 可能 期待hr元素需要闭合标签的风险微乎其微，而这种便利性(如我前述的能将p标签或li标签批量替换为div标签)所付出的代价微不足道。
当年我对XHTML并无异议；后来花了不少时间才摆脱这种思维定式； 我总会下意识地闭合那些标签：
等等。
真正压垮骆驼的最后一根稻草，是XHTML 2.0规范[1]放弃了对HTML 4的向后兼容性。例如我们熟悉的表单彻底消失，取而代之的是XFORMS。
正是那时WHATWG成立，脱离W3C并创建了HTML5。
谢天谢地。
[1]: https://en.wikipedia.org/wiki/XHTML#XHTML_2.0
XHTML 2.0确实包含许多优秀构想，其中不少在后续年月中被“回溯移植”到HTML5中。
XHTML 2.0 其实并未彻底抛弃向后兼容性：其兼容性机制通过 XML 名称空间实现。正如如今仍可在 HTML 5 中嵌入 SVG 或 MathML，你同样能将 XHTML 1.0 嵌入 XHTML 2.0 文档中。XForms预计需要数年才能成熟，当时业界普遍预期在XHTML 2.0生命周期内仍需继续嵌入XHTML 1.0表单。
至少从我这个外部观察者的角度看，WHATWG的成立本质上是“文档平台”与“应用平台”两种网络观之间的代理战争。XHTML 2.0追求更强烈的文档导向型网络。
(此外，XForms本身也包含诸多优秀理念。当人们呼吁将HTMX这类“表单辅助工具”纳入浏览器标准时，其中部分功能——如无需JS的表单提交异步刷新机制——本就属于XForms的范畴。HTML5逐步添加的INPUT标签验证功能，某种程度上也是从XForms“回溯移植”而来，尽管不再依赖XSD规范。)
实际应用中XHTML过于严苛，其设计理念(无论利弊)往往破坏其他功能，因此无人采用…
话虽如此，编写可通过XML解析器处理的HTML本质上是种友善的做法——这能让浏览器与非浏览器应用程序更轻松地抓取和解析内容。基于此，我还会为元素添加额外的data-*属性，仅为方便测试(及数据抓取)。
你并非孤例，这叫XHTML，曾被尝试过但缺乏足够使用者
是啊，记得上学初学HTML时，偶然接触XHTML后我立刻调整方法确保页面通过XHTML验证。看来我始终站在技术派立场。或许是机器同理心？也可能是人类同理心——毕竟总得有人编写解析器和处理逻辑。
唉，真希望XHTML能赢得这场战争。可惜太多人(包括内容管理系统)编写了漏洞百出的标记，导致页面直接变成致命的黄色屏幕，最终无人问津 🙁
幸好它没流行起来。大小写敏感(尤其CSS)、必须记住根元素的xmlns命名空间URI、内联脚本的CDATA区块，还有企业那些用更多XML命名空间元素扩展它的疯狂想法…简直是疯了。
它确实包含过多冗余元数据，但编程中采用大小写不敏感设计永远是错误的(比如不区分大小写的文件系统路径)。这种特性仅适用于人名地址等现实场景。CSS类名本就不该混用大小写，若真要混用，为何不直接实现驼峰式命名与蛇形命名自动转换？
我复制几天前写的内容：
XHTML未能普及的事实，是我们数十年来持续付出的代价。
浏览器引擎本可以更简单；网页开发工具本可以更早具备更强大的功能；我们本可以依赖XSLT并创造其他处理和消费网页内容的方式；我们本可以拥有完善的XHTML模块，而非如今这些半成品的Web Components。诸如此类。
然而我们得到的却是建立在规范模糊的惯例之上的标准，至今仍需依赖第三方框架才能构建出超越玩具网站的实际应用。
更严格的网页文档虽不能解决所有问题，但必将带来显著的积极影响。
补充：
诚然初期存在可用性缺陷，但这些问题本可随时间推移逐步消除。用严格标记标准的潜力换取如今的现状，实属重大失误。
这种标准根本不可能普及。试想两种浏览器：一种严格遵循规范，另一种遇到无效标记就进入“尽力而为”模式。终端用户才不会关心浏览器A为何不显示学校舞蹈演出日程背后的哲学原理。
想想JSON和CSV。两者都有正式规范。但在实际应用中，大多数解析器都比规范更宽松。
这在很大程度上正是发生的情况：HTML 5在某些方面就是这种“尽力而为”模式，由不同的标准机构标准化，以绕过XHTML的理念。
没错，就是这样。我们可以就理论上的优雅方案争论到天荒地老，但现实世界的博弈论决定了浏览器会竭尽全力解析各种垃圾代码，进而削弱开发者和工具生成字节级完美输出的动力。
> 这将极大简化浏览器代码和HTML规范。
我怀疑这根本无济于事——比如在“跳过
”的场景中，你只是用“显示错误提示”取代了“跳转到下一个插入模式”的错误恢复机制，但a)你仍需保留处理该情况的代码路径，b)现在你还要负责生成优质错误提示，而这向来是难事。真正能大幅简化解析器的做法是移除document.write——自DOM引入后该功能早已过时，现实中主要残留的应用场景似乎只剩广告投放。(若不明白此举为何有效，请考虑document.write可执行调用自身脚本的循环逻辑)
> 我希望HTML5能彻底消除这些容错机制，让浏览器直接报错而非宽容处理。
谁会想要使用一个会阻止大量现有有效页面显示的浏览器？
我的意思是，这显然是个虚构情景——某种更理想的时间线/宇宙。在这种情景下，那些不规范的闭合标签、依赖浏览器解析宽容度、复杂的回退机制等拙劣做法根本不会成为惯例，而当前大量有效的网站也大多不会存在，因为当有人试图创建它们时，浏览器就会直接拒绝。随后开发者会修改代码，最终形成更简洁易解析的代码/文档，我们的标准也不会充斥各种边界情况和特殊案例。
当然现实世界并非如此，但这并不妨碍我憧憬另一种可能。
我完全认同，但这是规范本身的问题，而非网站问题。若存在多种实现方式，选择最简方案即可。解析器终究必须处理所有边界情况，无论如何。
不过出于美观或人性化考量(降低认知负荷、便于扫描)，你或许希望始终规范地闭合所有标签，我对此表示认同。
<html>、<head>和<body>的起始与结束标签均属可选。实际应用中，因需指定语言属性，<html>起始标签不宜省略，但其余标签永远无需附加属性。(若需在body元素添加属性或类名，请考虑html元素是否更合适。)我已很久没写过<head>、</head>、<body>、</body>或</html>了。
> 注意和
会自动闭合，无需显式结束。你这个怪物。
不仅html和body标签自动闭合，其所有标签(包括起始元素标签)均可完全省略：
(详见[1]中的说明幻灯片，了解SGML/HTML如何通过标签推断生成完整标记文档)
[1]: https://sgmljs.sgml.net/docs/html5-dtd-slides-wrapper.html (链接自https://sgmljs.sgml.net/blog/blog1701.html)
我不确定是否该把保持
标签未闭合称为 令人满意，但确实是个有趣的知识点。如果没把打开的东西闭合，我会觉得别扭。
不知道原来可以省略
.. ，但我更倾向于保留它们以保持清晰。你是否也会为所有表格显式写出隐含的
标签以增强清晰度？有时会…尤其当单条记录跨多行显示时。
我几乎总是使用 thead。
是的。根据我的经验，显式标记几乎总是优于隐式处理。
若你的IDE支持Emmet(VS Code默认支持)，可通过“!”+Tab获取相同标签。
感谢这篇帖子！我期待你能添加内联CSS样式表来修复默认样式缺陷。目前只记得一个例外——等宽字体大小规则。需要类似以下代码：
但隐约记得链接、img标签等其他元素也存在CSS默认样式问题。HTML5模板指南本应涵盖这些内容，可惜我尚未见过包含此项的指南。
搭配H5BP时可使用Normalize.css(作为http://meyerweb.com/eric/tools/css/reset/这类重置样式的替代方案)，详见https://github.com/necolas/normalize.css/blob/master/normali…
另有简短重置方案：https://www.joshwcomeau.com/css/custom-css-reset/
我以为会自动默认utf-8编码，还是说自从html5成为新宠后规则变了？
真希望有天还能用这个让HTML按预期运行。
抛开怪异模式不谈，驯服旧标记还有其他方法…
若网站拒绝更新，你可以…通过用户样式表或扩展程序调整字体大小和颜色，无需等待维护者…
但对于依赖CSS行为的脚本，有个简单检测法：检查document.compatMode属性，若结果不符预期则退出执行…有时添加包裹元素并用Range提取内容能保持页面完整…
此外添加语义元素和ARIA角色对无障碍访问大有裨益…成本低廉却能帮助屏幕阅读器导航…
期待看到更多社区技巧——无需重写代码就能提升可用性…
让样式如预期生效的CSS规则：
> <!doctype html> 可确保渲染一致性。若偏好1998年风格的标记语法，可用<!DOCTYPE HTML>。甚至可采用<!doCTypE HTml>这种打破社会规范的写法。因大小写不敏感，三者均有效。
若需多语言(X)HTML支持，请使用<!DOCTYPE html>。
我倾向于将所有HTML代码小写化，因为这样熵值更低，压缩效率更高。
但需注意现代压缩算法中，部分会预置网站专用词典。这些词典通常包含最常用形式的等常见内容。因此遵循通用规范反而可能提升压缩效果。
我们需要高级HTML——<!Dr. Type, HtML, PhD>
我厌恶因iPhone及后续手机导致网页默认设置糟糕，致使我们永远被困在那个视口元标签里。
要是HTML5规范也能将UTF-8设为默认编码就好了。
我来这里也是想谈谈UTF-8。这简直是重大疏漏，早就该解决了。
我个人20年来始终将默认编码设为UTF-8，因此常忽略某些编码问题，却又会遭遇其他问题。
width=device-width 实际上是冗余且盲目模仿的行为。只需设置 initial-scale 即可。我在这里详细解释过：https://news.ycombinator.com/item?id=36112889
我已阅读你的帖子。本周我将用几台低端设备测试验证，随后更新我的模板代码。
outerHTML是Element的属性，而DocumentFragment并非Element。
标准规范中何处规定它应该生效？
当然，“不带meta utf-8”的部分取决于浏览器的默认编码设置。
2025年还有哪些主流浏览器不默认使用utf-8编码？
我花了半小时排查浏览器中某些JSON文件的è字符显示异常问题，尽管输出代码和下载文件看似完美无缺。最终发现Safari和Chrome并未将UTF-8设为所有内容的默认渲染编码，于是放弃了排查。
不过这个问题应该会修复。
若本地文件URI加载的页面仍存在此问题，我不会感到意外。
HTML5甚至不允许在中使用其他值。要实现截图效果，你需要采用不同的文档类型声明。
虽然如此，规范同时要求用户代理必须支持通过此方式指定的其他编码：https://html.spec.whatwg.org/multipage/parsing.html#characte…
另一个有趣之处在于，他们先声明“不限于”(所列编码)，却又要求“不得支持其他编码”(除所列编码外)。
原文写道：
> 编码规范中定义的编码方案，包括但不限于
此处“编码规范”指代https://encoding.spec.whatwg.org(此处应为链接)。因此实际含义是“其他规范至少定义了这些编码，也可能包含其他编码”(例如EUC-JP在编码规范中定义但未在HTML中列出)。
啊，我理解这是指前文所述的 编码。
基本上都包含。
我仍不明白人们认为lang属性能实现什么。确定语言本是小事，而当无法确定时，对读者而言同样不是小事。
文章里不是写明了吗？
> 浏览器、搜索引擎、辅助技术等可利用该属性实现：
> – 为屏幕阅读器提供准确发音与语音支持
> – 提升索引与翻译精度
> – 应用区域化工具(如拼写检查)
它列举的是伪科学理由，而非真实价值。
发音问题要么通过a)自动语言检测解决，要么b)根本无关紧要。当我阅读书籍时，若遇到可识别的语言文本，我会正确发音——屏幕阅读器亦然。若遇到陌生语言文本，我无法正确发音，屏幕阅读器同样如此。对我这个不懂匈牙利语的人而言，屏幕阅读器正确发音毫无意义。即便万一读错——即使我懂匈牙利语——也能听出那是英语化的发音。但屏幕阅读器根本不可能读错，因为“Mit csináljunk, hogy boldogok legyünk?”这个短语毫无歧义。这纯粹是匈牙利语，若我安装了匈牙利语屏幕阅读器，识别起来轻而易举。
同样道理，若能翻译，说明你已知晓原文语言。若连语言都无法辨识，那从书本上阅读同样无从谈起。
参见上文。区域设置略有帮助，但文章链接的示例纯粹涉及语言问题，而拼写检查要么a)在en-US/en-UK等场景下失效，要么b)如上文1)所述情况般显而易见。
lang属性对整个流程毫无增益。
你的整个论点都基于语言识别既简单又万无一失的假设。事实并非如此，若考虑页面中存在多语言元素或相似语言的场景，情况会更复杂。
即便语言识别非常简单，你仍将识别负担转嫁给用户工具——而作者本应事先知晓语言信息。
语言检测(此处“语言”特指全球200种实际使用语言)在处理完整段落文本时确实简单。
但现实是：当网页包含用户贡献内容时，作者根本无法知晓内容语言。难道要强制要求用户将每个HN评论标记为“英语”？这将给所有互联网用户带来巨大负担。其他书面语言从未强制标注语言属性。强迫人类为满足计算机需求而进行数据录入，绝非理想解决方案。
> 实际使用的200种语言
你是否有相关依据？莫非你暗示我们不该支持其他数千种[0]语言，仅仅因为它们用户基数不足？
> 关键在于网页作者根本无法识别用户贡献内容的语言。难道每个HN评论都该标注“英语”？这简直给每个互联网用户都带来了巨大负担。
对于Hacker News或其他包含用户提交的多语言内容的页面，只需将评论的lang属性标记为空字符串，表示未知语言并回退至自动检测。另一种方案是允许用户选择语言(默认采用其上次使用或自动检测的语言)，Mastodon和BlueSky即采用此方案。对于单一语言论坛及无用户生成内容的网站，统一采用站点语言即可。
> 其他书面语言从未明确规定其语言属性。强迫人类输入数据以满足计算机需求绝非理想方案。
其他书写语言中既无“屏幕阅读器”也无“自动翻译”。设置内容语言有助于提升依赖计算机才能实现的无障碍功能。
[0] https://www.ethnologue.com/insights/how-many-languages/
但愿此言属实，可惜人类曾愚蠢地试图将所有汉字压缩为2字节UCS编码(最终失败并演变为丑陋的UTF-16乱码)，由此引发的“汉字统一”灾难席卷全球。如今页面渲染正确汉字时，必须借助带外通信机制才能避免冒犯用户。
使用lang属性的另一大优势在于它能启用自动分词功能。
不错，基础知识重温，值得肯定。不过：
我知道你在想什么，我忘了写HTML最重要的代码片段：
哈哈。
-> 好吧，谢谢，现在我确实感觉错过了某个内部梗。
这在React等框架中很常见：HTML只提供基础骨架，由前端框架构建UI。
和https://j4e.name/articles/a-minimal-valid-html5-document/有异曲同工之妙
都2025年了，这种东西还有必要分享吗？
是的。知识并非平等分布。
吉姆在社交媒体分享此文时，在链接前标注：“有时单纯记录基础(或许？)显而易见的内容，反而能带来宣泄效果”
此刻更需要坦诚分享。这些未经审视的陈词滥调早已成为固定模板。
每天都有万人在学习你以为人尽皆知的事：https://xkcd.com/1053/
引用替代文本：“说'连黄石超级火山都不知道算什么蠢货'，远不如第一次向人介绍黄石超级火山来得有趣。”
谢谢！这个我不知道。
我曾有位老师，当学生问及他认为理应掌握的知识时会勃然大怒：“你们都上x年级了居然还不知道这个？！(故意用大写字母强调)”。你昨天刚学到的知识，并不代表全世界的人昨天都学到了。永远要勇于提问，永远要耐心解释。
不过这类问题确实会让人措手不及。记得大学上《Unix系统编程》课时——这是大三课程。老师正在讲解进程内存布局：“这里是文本段，数据段等等”，突然有学生问：“注释该放哪儿？”
我还以为大家都知道XKCD 1053呢…
XKCD 1053是种生活方式。我时刻铭记于心，它让我成为更好的人。