制作网站的妙处在于：只要编写HTML而无需其他代码，你就能获得响应式网站。
当然，若包含图片可能会引发内容溢出问题。
因此我们可以从修复这个问题开始：
img {
max-width: 100%;
display: block;
}
copy视频或SVG元素也可能引发问题(SVG的概率较低)，如有需要可在此基础上稍作扩展。
img,
svg,
video {
max-width: 100%;
display: block;
}
copy
优化排版#
首要任务是更换字体家族，因为默认字体往往缺乏美感。
本例采用基础的system-ui字体。该字体当前兼容性良好，可在所有系统中呈现优质效果，且无需额外加载字体。
整体字号略显偏小，可适当放大；默认行高通常偏紧，调整至1.5至1.7倍间距即可：
body {
font-family: System UI;
font-size: 1.25rem;
line-height: 1.5;
}
copy虽然并非完美，但相较常规默认样式已是巨大改进。
添加深色模式支持#
鉴于众多用户偏爱深色模式，我们将根据系统偏好启用该功能。
可通过color-scheme属性实现：
html {
color-scheme: light dark;
}
copy该属性将根据用户系统偏好，将用户代理样式设置为浅色或深色主题。
若需替代方案，也可采用非CSS实现方式！
<html lang="en" color-scheme="light dark"></html>
copy关于遵循系统偏好的补充说明#
虽然此方案非常便捷，但最佳实践是同时允许用户手动切换配色方案。
部分用户偏好深色系统主题搭配浅色网站主题，反之亦然。
限制内容宽度#
行长是影响文本可读性的关键因素之一。
通常建议将正文文本(非标题)控制在每行45-90个字符的范围内参考。
为提升网站可读性，我们将通过main元素配合CSS技巧限制内容宽度：
main {
max-width: min(70ch, 100% - 4rem);
margin-inline: auto;
}
copy此处的min()函数将取70ch与100% - 4rem中的较小值。由于在min()函数内部，无需使用calc()。
无论min()函数输出何值，其宽度均小于100%，因此页面将紧贴视口左侧。
接着使用 margin-inline: auto 实现居中效果——该属性作用于行内轴方向的边距，因此在任何水平书写模式下，都意味着 margin-left 和 margin-right 同时设置为 auto。
建议将主选择器替换为 .container 或 .wrapper，以便更灵活地控制应用场景。
最终生成的CSS文件如下：
html {
color-scheme: light dark;
}
body {
font-family: system-ui;
font-size: 1.25rem;
line-height: 1.5;
}
img,
svg,
video {
max-width: 100%;
display: block;
}
main {
max-width: min(70ch, 100% - 4rem);
margin-inline: auto;
}
copy基于此构建#
这只是快速入门的起点，但也可用于构建极简页面。
多数情况下，您可能需要在此基础上进行扩展，不过它确实能成为绝佳的起点！
本文文字及图片出自 The least amount of CSS for a decent looking site
凯文·鲍威尔创作的内容精彩绝伦。看到这里充斥着负面评价，我深感遗憾。这篇文章对完全零基础的新手来说，是踏入CSS领域的绝佳入门指南。
我写CSS已有25年，仍将此文加入书签。除非你是自虐狂且紧跟前端开发潮流，否则总有新知识值得学习。我此前完全不知道
color-scheme属性——这能省去我大量工作！margin-inline同样闻所未闻。属性数量之多简直令人发狂…我长期从事CSS工作，同样从未听闻“margin-inline”。
依我之见，除非你哪天要用传统蒙古文或奇幻日语建站，否则完全不必理会那些-inline/-block“逻辑”属性。为此做准备实在不明智。
虽然用一行代码实现居中比两行更省事，但代价是别人读你代码/博客时，多少得 了解这些该死的逻辑属性。
有道理，但忽视逻辑属性终将埋下隐患。它们能让跨语言跨书写模式的布局更可预测，且一旦掌握，单行居中这类基础操作几乎不增加成本。这是面向未来的保障，而非过度设计。
数十年后当传统蒙古语成为通用语时，我的CSS需稍作修改——届时我必将深感羞愧难当
鉴于许多人即使不合逻辑也偏爱四属性快捷写法，教授双属性快捷写法仍是明智之举，即便你并不打算支持最关键的本地化场景。
此外根据我的经验，它们与Flexbox和CSS网格的交互方式颇具实用价值——有时“逻辑属性”比四属性版本或单属性版本更易于理解。
CSS正以惊人速度迭代升级。若你具备编写经验，此刻正是施展技能的黄金时代。
我喜欢新特性快速迭代的速度。这终于弥补了多年停滞不前的遗憾，让我不再感叹“要是CSS能…”
嘿，这真是建设性的观点。兄弟，我欣赏你。
新CSS特性未来25年都将保持实用价值——我认为绝对值得投入精力学习。
我不理解这些批评。我正在搭建个人作品集网站，追求极简风格。这种样式设计完全符合我的需求——毕竟我并非应聘前端开发岗位，只需确保移动端和桌面端显示合理即可。
这位大师堪称传奇。记得刚入行时就常看他的教学视频。
> 虽然这功能很实用，但最佳实践是同时提供手动切换配色的选项。有人偏好深色系统主题搭配浅色网站，反之亦然。
若采用服务器端主题选择器尚可理解，因其可在页面构建时提供特定HTML。但若使用基于JavaScript的方案从localStorage获取主题偏好，我发现这几乎总会在深色模式下引发“闪光干扰”——因为检索速度慢于浏览器的首次渲染。
为规避此问题，我一直在实践(并推荐)纯CSS主题方案。用户对此反馈积极，且未有人要求主题切换器——我们仅尊重其现有偏好。但若提供多色方案(超出明暗两色)，此方案可能失效。
我很想知道是否有人找到避免JS切换器产生此问题的方案——理想情况下无需延迟初始渲染。
我认为一个有趣的方案是开发浏览器扩展，允许用户按域名覆盖prefers-color-scheme属性，类似开发者工具中的切换功能。
> 若采用基于JavaScript的方案从localStorage获取主题偏好，我发现这几乎总会在深色模式下引发“闪光干扰”，因为检索速度慢于浏览器的首次渲染。
若将三行JavaScript代码用经典script标签直接嵌入HTML并阻塞执行，则不会出现此问题。
可始终默认使用用户模式，并通过切换器加载另一份CSS文件。
这样虽会出现闪烁，但若用户在浏览器/DE中设置了深色模式，闪烁效果将呈现为深色而非浅色。
或者，也可始终让闪烁效果呈现为深色。我从未听说有人会因深色闪烁感到困扰。
深色闪屏绝对令人烦躁；感觉就像在用第一代电子阅读器。
这就是我把网站做得像素化、点阵化的原因。性能不足本身就是一种 美学。要是心情特别调皮，说不定还会加个假加载条。
好吧，这比较太荒谬了。双屏设备首次加载后闪烁两帧，根本不像第一代电子书阅读器。
我采用的是本地存储而非Cookie来保存用户设置：https://hypertexthero.com/dark-mode-website-theme-switcher-l…
> 您的设置偏好通过浏览器本地存储而非Cookie保存，可避免出现“接受Cookie”提示。
虽不了解其他地区法规细节，但此区别对欧盟《电子隐私指令》无关紧要：a) 该指令从未仅针对Cookie，b) 记录用户偏好的纯功能性Cookie无需明确同意。
引自[0]：
> 34,35 《电子隐私指令》第5条第3款所指的信息存储，意为将信息置于用户或订户终端设备中的物理电子存储介质[..]，此定义涵盖浏览器Cookie存储等既定协议及定制软件的应用，无论该协议或软件由谁创建或安装于终端设备。
> 43 处理设备内存储或生成的信息[原文如此](如Cookie、本地存储、WebSQL，甚至用户自提供信息)的网页浏览器亦属此类情形。只要信息未离开设备，应用程序使用此类信息不受《电子隐私指令》第5条第3款约束
https://www.edpb.europa.eu/our-work-tools/documents/public-c…
很遗憾，贵站暗黑模式下切换页面时存在闪屏现象。若能继承用户偏好初始状态而非强制手动调整会更理想。
虽未实际测试，但首选方案是采用服务工作者。服务端工作者可在初始请求中附加参数，标识本地存储中的主题设置。初始响应即可据此采用默认主题。
哪里能深入了解基于CSS的主题化方案？
相关知识其实比想象中简单。基本有三种策略：1. 在
:root中设置浅色主题颜色变量，在@media (prefers-color-scheme: dark) { :root { ... }中设置深色主题颜色；2. 使用新语法--var: light-dark(light-value, dark-value)配合:root { color-scheme: light dark; }； 3. 在 body 添加类名来决定应用浅色或深色变量(可与上述方法结合使用：默认采用用户当前主题，同时允许通过切换类名实现 JavaScript 主题切换)若仅需实现浅色/深色切换，这篇(发布于HN的)文章展示了无需JavaScript的自动/浅色/深色切换按钮，并演示了使用CSS变量控制颜色： https://lyra.horse/blog/2025/08/you-dont-need-js/
个人认为不采用明暗主题才是最佳实践。网站呈现效果本就该符合我的预期——这终究是我的网站，而非你的。
既然是我的网站，我希望给用户提供两种样式选择。
记得Firefox以前菜单里有个选项能切换多种样式表，不只是浅色和深色。我记得这是CSS的标准功能，但只有Firefox支持通过界面切换，其他浏览器必须用JavaScript实现选择器。
依我之见，避免使用明暗主题才是最佳实践。网站呈现效果本就符合我的预期。这并非你的网站，而是我的网站。
感谢你证明了“最佳实践”这个词毫无意义，不过是“我听别人这么说”的同义词罢了。
> 我认为一个有趣的方案是开发浏览器扩展，允许按域名覆盖prefers-color-scheme属性，类似开发者工具中的切换功能。
想必多数追求无干扰浏览体验的用户，早已采用Dark Reader等极端解决方案。
令人遗憾的事实是，这类用户偏好和站点级持久设置本就该由浏览器负责：就像字号/页面缩放功能本就该如此，某些(明显受限的)安全设置亦是如此。(令人唏嘘地)有趣的是，CSS诞生之初就存在(至今仍存在)“替代样式表”的概念(仍是规范[0]的一部分，但Gecko引擎之外无支持)，它同样因缺乏持久性而逐渐被淘汰。因此时至今日，以Firefox为例，其“查看→页面样式”菜单虽允许用户选择替代样式表，但该选择无法在导航间保持，因而本身毫无用处。
用户样式同样如此：规范规定了CSS源级别的概念及其行为方式，要求所有“用户代理”提供进入层叠样式表的途径，却未提供将单个样式规则限定在具体源的官方方法。这正是非官方
@-moz-document扩展的初衷，该方案曾短暂获得规范化的机会[1]。不过我扯远了。(所有“欧洲式”Cookie横幅同样如此：这是法规应用层级错误的悲剧范例。本应借助用户代理赋予用户控制权——通过默认拦截几乎所有内容，并采用真正有效的权限系统，而非依赖“若您不点击横幅内的开关，我们保证不追踪您”这种虚假承诺。不过我又跑题了，抱歉。)
> 我很好奇是否有人找到解决JS切换器问题的办法——最好能避免延迟初始渲染。
当前浏览器尚未原生支持站点级用户偏好设置，最稳妥的实践方案是直接返回正确设置的HTML内容。为此甚至已有专属HTTP头规范，一旦浏览器采纳该方案，我们甚至能舍弃HTTP Cookie[2]实现持久化存储——但据我理解，协商这些“客户端提示”需要额外的初始请求往返，对服务器要求颇高。
实际操作中，我认为在HEAD部分放置早期运行的JS代码，确保根节点设置正确配色方案且仅加载正确样式表，基本能避免大多数闪屏问题——前提是服务器能及时返回相关代码片段。遗憾的是，目前尚无支持导航功能的无JS无Cookie(或任何无JS持久化)的优质解决方案。
[0] https://html.spec.whatwg.org/multipage/links.html#rel-altern…
[1] https://www.w3.org/TR/2012/WD-css3-conditional-20121213/#cha…
[2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/…
Firefox确实提供全局设置来覆盖系统设置，例如当你希望系统采用深色模式而网页保持浅色时。
多数浏览器也支持按页面覆盖设置，但唯一能找到该功能的地方是开发者工具，这实在令人遗憾。
我认为浏览器厂商选择投入“阅读模式”作为用户体验方案，而非直接控制用户样式和页面样式，虽然不确定这是否正确，但能理解这种看似更简便的“一键式”选择逻辑。
可悲的是，当前“提供浅色/深色模式”竟被视为网页样式用户选择的最佳实践。哦，感谢网页开发者“允许我”在两种配色方案间“选择”！要知道，早在90年代起，我就能自由设置桌面窗口颜色、文字颜色、字体、文字大小，甚至逐个元素调整。若想在紫色窗口背景上使用黄色Comic Sans字体，我完全可以实现。但网页上却不行！在尊重用户偏好方面，我们竟倒退至此。
奇怪，我反而对这种做法感到反感。为什么我要给网站“换主题”？这难道是MySpace时代？我希望专业付费/受训的开发者来设计网站。若采用浅色系，我期待有充分理由支撑；反之亦然。
餐厅沙拉也是同样道理——我不愿在餐桌上自己切菜、加酱汁、搅拌沙拉，更别提没有碗和专用餐具。我付钱请专业人士准备餐食，就该由他们来处理这些事。若对食材有异议，或想加大量酱汁，我自会提出要求。但端来一盘分隔整齐的食材简直荒谬至极……除非是搭配火锅，或是我报名了什么铁板烧闹剧来增添“互动感”。
我完全跑题了，抱歉，请继续。
楼主的想法是正确的，远比我在此看到的那些自私冷漠的回复要好——正是你们这类人，才迫使我们不得不采取诸如繁琐的《美国残疾人法案》合规措施等用户权益保障行动。
理想的网络应尽可能提供更优的表象与功能分离方案。我深知这是过时的理念，但如今它们比以往任何时候都更重要——不仅关乎美学，更涉及能力、权力乃至自由。
你似乎对阅读他人设计的文本感到不满。那你如何应对书籍、杂志、演示文稿、标识牌、餐厅菜单等视觉内容？
称这种现象为“可悲现状”未免夸张。你不得不面对不符合个人偏好的色彩搭配——天哪！
可悲在于这是种退化。
十五年前网站实现这点轻而易举，但随着复杂度攀升，如今已不可行。我们把越来越多的样式化功能塞进JS，这严重削弱了网络平台的本质。
这正是CSS存在的意义。这并非什么怪异用例，而是核心用例。我们都偏离了正轨。
诚然，这是CSS的特性，但认为网页必须使用该特性否则就该被嘲笑的想法很荒谬。这完全取决于呈现者多大程度想迎合受众偏好。有时答案就是“完全不需要。信息已以合理方式呈现，额外耗费在格式选项上的精力纯属浪费。”这正是书籍通常不提供大字版的原因——除非存在充分理由，比如目标读者中有大量需求群体。
我并非认为存在义务，只是觉得现有软件设计欠佳。
这很正常。多数软件都是垃圾，他们应该会如鱼得水。我只是不愿假装当前网页应用的现状完全可以接受。
它糟糕透顶，糟糕透顶，糟糕透顶。
太夸张了。难道只提供单一配色的书就很糟糕吗？
这对我来说太老派了(我从1997年就开始用JS/CSS开发，HTML更是更早之前的事)。我的网站直接采用prefers-color-scheme，并提供明暗模式切换按钮，用户选择会本地保存。遇到Dark Reader时，我会尊重用户偏好。
若能自由选择字体，你会怎么做？标题用什么颜色？按钮背景色？是否该允许定义边框圆角？CSS过渡效果？甚至整个CSS样式？
这些功能已有扩展实现。
我认为绝大多数用户并不关心这些。
你提到的这些属于 主题 范畴。而浅色/深色设置控制的是视觉 方案，两者截然不同。
指望每个网页都让用户单独控制主题元素简直荒谬。若需要这种级别的控制权，你可以通过自定义样式表自行覆盖。
这可是你正在浏览的个人网站。该感谢站长考虑了你和其他用户的偏好方案，毕竟有些人根本不在乎。
你可以修改网站的CSS样式表，这方面有专门的扩展工具。
可能只是你没认真找方法而已。
当然，所有浏览器都把这个功能藏在设置里。我的意思是，这并非多数网页开发者关注的路径，而且很多网站在关闭样式或替换自定义样式时并不稳定。
使用扩展程序(Stylus？)注入CSS。
一篇旧文，在某些地区仍具参考价值，阐述为何不应使用系统UI字体家族。
https://infinnie.github.io/blog/2017/systemui.html
有趣的是Bootstrap在2017年移除了“system-ui”
https://github.com/twbs/bootstrap/pull/22377/files
但在当前版本中又重新加入：
https://github.com/twbs/bootstrap/blob/main/scss/_variables….
该功能于2020年由https://github.com/twbs/bootstrap/pull/30561重新添加
此前未曾注意到此现象。经查证，该问题在CJK版本的Windows系统中确实依然存在。
Bluesky平台的此PR包含最新讨论及解决方法：
https://github.com/bluesky-social/social-app/pull/6139
真遗憾，我喜欢网站使用我自定义的字体
“sans-serif”、“serif”和“monospace”仍会解析为用户选择/偏好的字体。
所以这个激烈争论的根源，仅仅是因为某个不受支持的专有系统在某个区域设置下，用糟糕透顶的字体渲染整个桌面和应用程序，就可能导致你的网站也被渲染成糟糕透顶的字体？
若标准的
font-family: sans-serif导致字体选择糟糕呢？难道所有访客都该为微软的无能下载100KB外部字体？唉，我的个人网站还是继续用system-ui吧。
问题远不止于此。文章附录指出Bootstrap和GitHub都已从字体堆栈中移除了system-ui，本讨论串另一条评论提到Bluesky也做了同样操作。每条记录都附有评论链接和/或PR说明原因。
Bootstrap后来虽重新添加了该字体，但在PR讨论中有人指出：至少在中文和韩文版Windows系统上，这个问题依然存在。
> 哎，反正个人网站我照用system-ui。
当然可以，不过既然如此，你也可以用自己发明没人懂的语言。
有意思，不过我可不想听一个连字母组合都这么糟糕的网站给字体建议！
若追求极致风格：
无CSS版：https://nocss.club/
无HTML版：https://no-html.club
若需为页面添加元数据，可通过HTML的
请务必按50-70字符的行间距设置换行，以提升阅读体验。否则我将强制为你的body标签添加style=“width:70ch”样式。
https://meyerweb.com/eric/tools/css/reset/
现金
埃里克·迈耶——史上最伟大的CSS大师
若非他在2002年指点，我至今仍无法理解CSS盒模型原理。
https://meyerweb.com/eric/books/
讽刺的是，该页面在Chrome/Windows系统下(约1920×2160分辨率，相当于27英寸3840×2160显示器的一半)渲染效果不佳：左侧过大的空白边距将书单推向右侧，导致出现水平滚动条。当滚动至最右端时，网站右侧区域会跟随滚动，留下尴尬的空白区域。
这或许说明了网页标准演进的某些问题。
CSS重置样式表只是迈向难以维护的“叠加式”样式表的第一步，这类样式表充斥着随处可见的“important”声明。
我认为最佳方案是采用文中提到的凯文·鲍威尔方法，即充分利用浏览器默认样式。当然仍需进行跨浏览器和跨平台测试，但经历近二十年——每份样式表都暗藏CSS重置，又堆砌着海量冗余代码(框架就是典型)——如今彻底摆脱这些束缚，转而运用CSS网格、CSS变量等现代工具，实在令人如释重负。
如今CSS已成为我最爱的“乐高积木”，其创造力令人着迷。这与过去我厌恶CSS中层层嵌套的权宜之计形成鲜明对比——从穿着救生圈仍险些溺水，到如今能自如游弋于水面。CSS重置正是那类“救生圈”，舍弃它们需要勇气。那些糟糕的CSS预处理器亦是如此。
依稀记得某篇博客曾详尽分析各类CSS重置方案，最终得出结论：浏览器间的差异有90%以上源于边距和内边距的差异。显然仅需“* { margin: 0; padding: 0; }”就能解决大部分问题，而那些庞大的CSS重置样式表之所以臃肿，往往是因为包含了冗余内容、罕用元素，甚至掺杂了创作者的个人偏好而非纯粹的重置功能。
最近我在工作中选择纯CSS方案。目前主要在做后端工作，进展有限，但现有部分效果不错。只是有点担心不同浏览器显示效果不一致，不过遇到问题再解决吧。幸运的是，我认为不会有Safari用户。
这个设计我见过好几次，总觉得哪里不太顺眼。它处于一种微妙的尴尬地带——不够经典无法真正体现简约实用，又不够新颖无法呈现现代极简风格。或许是字体的问题，反正我读起来不太顺眼。当然也可能只是我个人偏好。
我的意思是，这只是重置样式而非完整样式。你需要在此基础上叠加自己的样式(准确说是层叠应用，但希望你明白我的意思)。
这样写不对。正确写法应为：
作者在某些CSS示例中写对了，但第一个示例有误。
另外，如果名称由两个单词组成，就需要加引号对吧？
例如这样也不行？
编辑：不过这个和仅写“times”都能正常工作，这让我怀疑是否因为它是老字体而被特殊处理，或者匹配规则本身就很宽松。
匹配规则确实很宽松，这个示例就能正常工作：https://codepen.io/leo848blume/pen/RNrppdj
我的浏览器在无法识别字体时会默认使用Times New Roman，因此为验证其有效性，我不得不手动更改浏览器默认字体
https://drafts.csswg.org/css-fonts/#family-name-syntax
你知道还有个很酷的功能吗？就是指定你想要的字体，这样你的网站就能呈现你想要的效果。这通常被称为“设计”，虽然在完全排斥美学的人眼中属于反模式，但它拥有约3000年的历史，能让人们更愿意接触你的内容——前提是你确实有内容可展示。
或者保留默认字体，让读者获得他们想要的字体——毕竟阅读者才是主体，除非字体与文本内容相关，否则作者自认为美观的字体其实无关紧要。
读者想要的字体，与操作系统默认字体相比，究竟有多少概率是相同的？
两者本质相同。你随时可进入设置更改字体。
况且若真要论设计——你选的字体几乎肯定比系统默认字体更差。
操作系统通常由市值数万亿美元的巨头公司开发，其字体必然经过优化，能在各种场景下保持高度可读性与简洁性。
你的字体或许更酷炫，但真的更好吗？可能性微乎其微。
反驳观点：除非有人换成丑字体，否则我从不关注阅读时使用的字体。
这通常被称为“其他人对你蠢字体的真实想法”。
反驳：你当然注意到了，只是大多是潜意识的。
人们——尤其是“左脑型”人士——严重低估了美学对心理状态的影响。你并非在纯粹抽象的以太中操纵数学符号的理性生物。你不过是只灵长类动物，仅凭六种粗糙感官生存——这些感官最初进化是为了避免被剑齿虎吞噬或误食腐果，而我们那套湿件(生物硬件)直到最近才被临时拼凑出抽象推理能力，靠着一堆混乱的类比和可视化来理解抽象概念。
反驳之反驳(来自辅修排版学者的观点)：字体的使命是如玻璃般透明地传递信息至你的双眼。因此若你注意到字体并觉得它愚蠢，说明设计师犯了错误。同样，若你注意到字体是因为设计师保留了默认的Times New Roman，那也是错误。优秀的版式设计师应让你在阅读正文时完全忽略字体存在。唯有当标题等元素需要突出时，字体才应偶尔成为焦点。字体是信息的载体——如同舞台灯光而非主角。除非设计师刻意为之，它绝不应扮演主角角色。
若你是程序员，对此必然心领神会：你设置IDE字体与配色时，正是为了透过代码看本质。当你试图理解代码时，绝不愿盯着字母形态发呆。
设计师的工作本质亦是如此：创造字体与版式，让人能透过文字直抵其意。
若让网站默认使用系统标准字体，无异于呐喊“我对这里写的内容毫不在意”，甚至可能暗示 “这是个荒诞的阴谋论网站”——我和大多数人都会尽快滑过你的文字。
但世上不存在毫无内涵的字体。每种字体都会在读者潜意识中引发特定联想。理解这些联想至关重要。Times New Roman在呐喊“我还在用Windows 98”，而Comic Sans则在宣告“我在破房地产公司上班”。以上只是简单示例。但字体艺术远比这深奥得多——Optima Sans与Univers给大众带来的视觉感受截然不同，这种差异足以让我再写几页篇幅来阐释。你对字体的每一次选择，都会在文字表层叠加一层隐含的暗示。但若功力深厚，便能让匠心隐而不显，让内容本身绽放光芒。
这就是为什么排版设计堪称一门玄学，也是它如此强大的原因。当人们吸收书面信息时，它会以他们未察觉、不理解的方式微妙地影响着他们。深入了解：
https://en.wikipedia.org/wiki/Antiqua%E2%80%93Fraktur_disput…
我完全赞同你“我才不在乎”的观点
还有哪种字体比系统默认字体更经得起快速信息传递的考验？对我而言，这简直在宣告“此处是正文主体，信息尽在此间”
不。系统字体的存在意义与面向公众沟通的字体截然不同。系统字体最初为特定屏幕分辨率下的可读性而设计，也适用于点阵打印机等场景。
但问题远不止于此。我想阐明的是：每种字体，哪怕最无害的字体，都会向读者传递微妙的潜意识暗示。所有字体皆然。这些联想可能来自童年看的迪士尼电影，也可能是你在医院遭遇严重病症时看到的字体。然而经过三十年全球用户对系统字体的视觉渍印，当读者看到系统字体时，大脑会自动解读为：这不过是老板随手钉在软木板上的劣质Word文档。抑或认定作者既懒得精心排版，也缺乏美化文稿的技能。
身为作家，我创作过六部长篇小说。我热爱不受视觉干扰的纯粹文字与思想。我一生至少写过50万字，或许更多，具体数字已记不清。那全是纯粹的思想与逻辑。因此我深感焦躁：我只想向你——我的读者、我的雇主——传递信息，传递我提炼出的思想。这才是最重要的。读不读无所谓，内容本身优秀且逻辑严密。
我同样受过设计师训练。十四岁起在广告公司实习，最初几份工作都在广告界。人们会如何潜意识解读这些视觉元素 是我很早就领悟的课题：他们会作何解读？ 因为拙劣的设计可能让读者对杰作产生偏见，反之亦然。
任何视觉创作都无法脱离文化参照；凡是他人可见的作品，必然牵扯着既定的文化意象包袱。你无法脱离自身受过的文化浸染进行创作。设计师的职责——区别于仅凭审美眼光评判网页美丑之人的核心价值，即所谓设计黑魔法的精髓——在于 洞悉每个呈现在目标受众眼前的文化隐喻，理解这些隐喻如何在受众阅读内容时影响其心理状态， 从而在传递客户信息时，精准触发受众特定的情感共鸣。
这才是视觉传达中“认真对待”的真谛。
Facebook会认真对待吧？以他们的影响力、资源和目标来看，所有公司中他们最该“认真对待”。对吧？
那么，用户墙上Facebook帖子的字体列表如下：
> Helvetica, Arial, sans-serif
> system-ui, -apple-system, BlinkMacSystemFont, Segoe UI Historic, Segoe UI, Helvetica, Arial, sans-serif
请注意，在这个每日被20多亿用户浏览使用的页面上，找不到任何定制字体、怪异字体，更没有“童年迪士尼电影的联想元素”。
你提这个真有意思，因为FB正是2000年代末视觉设计遗留物的典型代表——它经不起时间考验。互联网泡沫破灭后，网页与早期移动端的设计理念，很大程度上是对90年代网络设计中那些过度夸张、狂野荒诞、不敬且往往混乱的排版与设计的否定。于是诞生了极简字体、纯白背景，以及他们自以为的“极简主义”。然而由于他们依赖现成工具而非创造独特体验(加上界面演变成庞大的垃圾噩梦)，如今Facebook在多数人眼中显得极其过时。它活像个二十年前的网站…而且还算不上优秀。
我作为局外人的观点是：Meta此刻根本不在乎Facebook的界面设计。我并非主张革新设计就能提升用户注册率之类。我想强调的是：若你只是个毫无网络效应、身无亿万资产的无名之辈，花时间做到以下两点反而更容易吸引读者——(a) 摆脱系统默认字体，(b) 做出其他能触发受众愉悦感的美学决策。
Facebook历经多次现代化改造，如今面貌已与二十年前截然不同。
难以判断具体细节，不过我得承认自己并非用户。但关于2000年代初网页设计转变的观点依然成立。
> 系统字体最初是为了在特定屏幕分辨率下提升可读性而设计的，也适用于点阵打印机等设备。
我觉得你混淆了 系统界面字体 和 浏览器默认字体 的概念。
系统界面字体属于现代设计，约十年前才被纳入CSS规范。它并非Times New Roman字体，也非为点阵打印机设计。
这里其他讨论者谈论的都是与系统整体风格协调的字体，而你似乎在谈论90年代初的产物。
当前主流操作系统中的系统屏幕字体——作为字形集合的整体——从未作为印刷字体存在。它们源于90年代受限条件下设计的位图字体，保留了部分时代美学特征，通常并非最佳选择。
依赖用户系统字体同样是值得商榷的劣选方案。
这种观点大错特错。自90年代以来技术已取得长足进步。
苹果、谷歌、微软均聘请专业字体设计师开发新字体。苹果在印刷材料中始终使用San Francisco字体。
在苹果设备上，系统界面字体正是旧金山字体——这款TrueType可变字体拥有2937个字形、4个轴向参数和369个实例。轴向参数包括字宽、光学尺寸、字号和字重。该字体还包含排版爱好者梦寐以求的所有特性：连字、小型大写字母、语境替代字形、真实分数等。
我认为这足以证明苹果“认真对待”排版。;-)
顺便一提，在macOS的Firefox和Chrome开发者工具中可查看每个命名实例。
实例由4个轴组合构成；例如CSS中可将San Francisco压缩细体实例指定为：
苹果公司几年前曾详细阐述过旧金山字体的创建过程[1][2]。
因此开发者/设计师无需额外下载即可获取可变字体提供的全部特性。
谷歌在Noto字体上也采取了类似策略。
[1]: “WWDC推出全新系统字体San Francisco” — https://www.youtube.com/watch?v=OpveNRh-jXU
[2]: “扩展版旧金山字体家族亮相” — https://developer.apple.com/videos/play/wwdc2022/110381
能否推荐一些优质书籍、视频系列、博客或其他培训资源，帮助需要达到您专业水平的人士理解字体？或者您考虑亲自撰写相关资料？
我认识一位想进入这个领域却缺乏经验的人，几乎无法追赶进度。希望能为他提供学习资源。
为Comic Sans辩护：它并非仅适用于房产中介网页。它能通过营造亲切随和的氛围，在本地休闲交流中发挥效用。若在海滨小镇的软木板上看到用Comic Sans字体张贴的炸鱼薯条特惠传单，我定会垂涎三尺——因为这昭示着这是家专注美食与待客之道的小店，而非营销噱头。
> 能推荐几本好书吗
罗伯特·布林赫斯特的《排版风格要素》
属于“五分钟学会，终生精进”的典范。
>> 若在海滨小镇的软木板上，看见用Comic Sans字体宣传炸鱼薯条特惠的传单，我定会垂涎三尺
嘿，你完全抓住了精髓。这点说得太对了。Comic Sans字体本身糟糕透顶，但若想传递这种调调——它简直绝妙！这正是深思熟虑的设计之道。第一层是掌握文化参照系，第二层是：适时运用俗气元素，使用粗俗字体，采纳街头艺术。当需要向“高雅”客户展示时，再切换到“精致”或“昂贵”风格。第三层及以上境界在于：懂得驾驭高低文化元素，让俗气客户保持俗气感的同时潜移默化地暗示鱼的品质更优；或是让“高雅”房产经纪人维持优雅形象，却又展现其并非刻板古板的形象。关键在于操作时不让任何客户产生明确的反感。
说到书籍，我得补充说明：我从小就在工作中学习设计技艺，并得到杰出艺术指导的指导——他们允许我尝试各种创意，并向我阐释这些原理：为何特定背景或字体传达的信息会以我未曾预料的方式对消费者产生负面影响。大学时遇过几位杰出教授(不过我中途辍学了)。关于如何运用这些技巧影响大众的高阶理论，核心精髓尽在马歇尔·麦克卢汉的《理解媒介》——这部经典著作阐明了设计师如何通过视觉呈现方式的心理社会学选择，改变受众对作品内容的感知。纵观历史，关于宣传概念的杰作不胜枚举，但麦克卢汉为设计师提供了关键启示：呈现形式往往比内容本身更重要。这意味着设计师的核心职责，恰似音响工程师对乐队专辑的精雕细琢——这种后期处理对最终效果的影响，常与原始录音品质同等关键。若同时身兼内容创作者，这种分离尤为艰难，因其要求对作品保持客观审视。总之，麦克卢汉的理论具有永恒价值，堪称洞悉万物本质的钥匙：品牌运作机制、微小设计决策的效用等等。
能够 阐释 视觉效果的差异，并能说明 选择背后的原因(包括所有旨在触发受众联想的文化参照——无论积极或消极)，这正是时薪40美元的设计工作与时薪150美元的艺术指导工作的分水岭。因此掌握“推销技巧”的技巧本身也具有价值。但你必须带着案例向客户展示。最佳学习方式是审视身边所有事物，质疑每项设计决策：为何选用这些色彩、字体等元素，同时洞察新兴趋势。回溯1950至90年代的设计语言，探究当时的流行元素。现在，你的目标受众是谁？你想传递怎样的情感？
[编辑] 补充说明：我曾是个纯技术控，在真正接触设计前就学会编程并运营BBS。12岁时我沉迷于创作自以为酷炫的ANSI艺术，还用Photoshop 3.0“设计”作品给别人用——当时完全不懂设计本质。技术人员往往倾向于把设计视为可通过程序和代码解决的问题。你不会意识到——设计其实是种在人类大脑中运行的编程语言。15岁时这个认知对我而言犹如醍醐灌顶，此后所有设计决策都受此启迪。所以字体确实至关重要。
反驳/疑问：那些至今仍存的Web1.0网站呢？人们潜意识里觉得它们过时，是否也带着某种睿智感？还是说使用者根本不在意？就我个人而言，我属于前者，同时还带着对青春岁月的一丝怀念。
以下列举若干案例(无特定顺序)：
美国国家标准与技术研究院关于TIME协议的页面[0](RFC868[0.a])——顺带一提，TIME协议堪称获取当前时间最简洁(就基础实用性而言；显然存在更简易的计时方式)且最妙趣横生的方案。详见[4]。
英国国家电网状态[1]——警告：移动端显示效果欠佳。
《创世记无解》[2]——进化论入门指南/某人对创世论的私人复仇。幸好这是Web1.0时代，否则澳大利亚用户的延迟体验会糟糕透顶。
弗兰克强迫症式邮政地址指南[3]——全球任何国家的地址体系疑问，此处皆有解答。堪称信息宝库。
0: https://tf.nist.gov/tf-cgi/servers.cgi
0.a: https://www.rfc-editor.org/rfc/rfc868
1: https://gridwatch.templar.co.uk/
2: https://www.noanswersingenesis.org.au/
3: https://www.columbia.edu/~fdc/postal/
4: 需安装 GNU coreutils 以使用 `od` 和 `date` 命令 – 若被轮询分配至不支持 TIME 格式的服务器，请重试。
我想你应该能猜到这里设计答案的边界。
当你尝试新技术时，一切都显得截然不同且充满新意。但当你回望三十年后人们的实践成果，会发现他们都受制于相同的局限性——尽管存在诸多差异，所有作品最终都呈现出可辨识的美学特征，这种特征源于当时的技术限制、艺术类型等种种制约。
这些网站风格迥异且极具创意，却都清晰地属于同一个十年左右的年代。
好。现在退一步看。人类——你、我、所有人——从出生起就习得了极其复杂的视觉语言，其中特定线索代表特定事物并触发特定记忆。若你给我看一张穿着喇叭裤的男子照片，我们大概率会联想到70年代；若是鼻环女孩露脐装造型，则多半指向2005年——当然其中还存在更细微的线索。99%的人在看到图像、网站等事物时不会有意识地思考这些，他们只是将其与某个时代或类型产生联想。
在网页设计领域，数十年来各种限制层出不穷又逐渐消退——我们经历过带有怪异美学的Flash时代，经历过Java嵌入时代等等。人们会记住某个特定时代，并将某种设计风格与之关联，却未必清楚原因。因此关键在于从历史库中挑选元素，构建出能引导人们看到你想要呈现的内容。若想唤起人们对90年代初的联想，那就让作品完全复刻当时网页的样貌。
设计学院教导我追求永恒的设计。这始终是种不可能的任务——因为技术限制往往超出当时认知，更因我们始终受环境所限。但请努力创造能在二十年后仍显新颖的作品。这极其困难。为何要尝试？因为二十年后，你总能用复古拼贴手法戏谑地致敬二十年前的作品。但要打造永不过时的设计，实属不易。
感谢您真诚而深入的回应。我本无意发表挑衅言论，但确实能理解为何会引发误解。
我最喜欢的同源网站对比是HAProxy：haproxy.com旨在取悦高管层，而haproxy.org则面向实际运维者。这也解释了我为何怀疑自己将文字密集型网站视为权威的根源并非单纯怀旧(除非这是千禧一代共同的错觉)。当用户访问这类网站时，他们通常想在技术文档中寻找具体解答，而非销售话术。
放眼其他行业，以汽车为例：只要稍有兴趣，通常很容易猜出某款车的生产年代。但某些设计者偶尔能将不同时代元素熔于一炉，我认为这种设计已接近永恒境界。在我看来，保时捷911堪称典范。在996车型问世前，它始终保持着一种既焕新又恒久的设计美学。996虽因“煎蛋大灯”饱受嘲讽(加之水冷系统激怒了纯粹主义者)，但除此之外，它开启了外观设计的渐进式变革。若不加尾翼，997、991和992从多角度看都惊人相似——这跨越了21年的车型更迭。此外，992将后部通风口由横向改为纵向布局——这种设计自911前身356车型(1966年停产)后便未再采用。这一细微变化配合徽标字体调整，使其外观显得比实际年份更古老，却别具韵味。
每当想到古怪的阴谋论网站，我脑海里就会浮现蓝底黄字的背景，闪烁元素里跳动的鲜红文字，以及底部链接着Lycos和Altavista的页面。
这简直是刻意追求“视觉冲击”的反面教材。普通的新罗马体或系统字体传递的，不过是另一种形式的文盲感…
你竟把“可读字体”当作文盲标志，这点深得我心。
纵使你是世间最博学之人，若你的形象是柠檬绿背景上闪烁的粉紫色Times New Roman字体，我仍会认定你毫无价值可言。其实有超多可读性强的字体可选，它们能让你看起来对他人印象稍有顾忌。
仅58字节CSS即可实现跨平台完美显示 https://gist.github.com/JoeyBurzynski/617fb6201335779f8424ad…
100字节：https://www.swyx.io/css-100-bytes
(我收集了大量这类设计建议。更多内容请见：https://github.com/swyxio/spark-joy/)
这确实是个巧妙的方法：在主流浏览器间取个折中值，生成基本可读的方案。“看起来很棒”有点夸张，毕竟效果永远像垃圾——不过是可读的垃圾罢了。
有什么优秀的静态网站生成器(SSG)能创建简约的学术风格网站？
Astro或Hugo(搭配Tailwind定制CSS)似乎是不错的选择。但Astro感觉过于复杂，而手动编写html/css又不够高效(需要预定义布局和便捷的样式定制功能)。我也找不到合适的Astro主题(多数主题似乎为企业设计，或过度花哨，仅有少数适用于个人博客)。
在探索过程中，我惊讶于网站设计竟变得如此复杂。海量的框架、组件、集成方案和依赖关系，不禁让人好奇网页开发者如何在这个生态中保持竞争力。
Quarto(https://quarto.org/)在学术出版领域广受好评，其网站项目支持：https://quarto.org/docs/websites/。
感谢提及，它确实提供相关模板，其中包含一个有趣的课程模板。
让大型语言模型编写一个50行代码的程序，使用pandoc将markdown文件目录转换为html文件目录。
这或许正是当今的“正确”解决方案。在LLM出现前，我曾编写过Python脚本实现带自定义页眉页脚等功能的Markdown转HTML，但如今我肯定会先让LLM尝试，看看它能产出什么。
我做过不少LLM网页生成项目，效果尚可，但它总在重复几年前就过时的“最佳实践”。尤其在元标签方面。
若由我来设计，我会要求它进行深度研究，找出2025年末在
head标签中包含的最精简高效标签集。虽然仅靠大量.md文件或许可行，但仍需一个文件存储全站元数据，并/或在MD文件中添加YAML“前置信息”来定义页面特定变量。
> 网站设计竟变得如此复杂，着实令我惊讶。
听起来你会喜欢https://mastrojs.github.io——一个极简的Astro替代方案。
这是网络系统的自然熵增。
我们不能指望一切永远保持简单。感谢所有无需授权的开放标准和框架。
没错，这确实是选择性瘫痪。
我用Jekyll搭建GitHub Pages。虽然自定义主题和域名配置耗费些时间，但现在只需添加Markdown文件推送至GitHub就行，非常简单。
https://github.com/loldot/loldot.github.io
若你真觉得过去更简单，那就照旧操作吧。一切照旧管用。
不妨研究Eleventy[0]或Zola[1]。两者都是近期发展起来的项目，拥有技术精湛且富有前瞻性的用户群体。
[0] https://11ty.dev/
[1] https://getzola.org/
你可以寻找仅CSS主题或Tailwind主题搭配Astro或Hugo使用。
我个人偏爱Astro的“组件”设计理念——减少粘合逻辑，更接近“纯粹书写html/md”的体验。当然这本身也需要学习曲线。
虽非必须增加选择，但franklin.jl完美契合我的需求——“能流畅处理内联数学与代码，其余部分简洁不干扰”
无需静态站点生成器。直接复制类似https://thebestmotherfucking.website的代码，像八旬老者般手动创建每页内容即可。
对于静态网站生成器最常见的用途(博客写作)，采用“原始”HTML其实并非糟糕选择。Markdown的多数用途只是为了省去写标签的麻烦。手写
<em>foo</em>和_foo_其实差别不大。HTML本就该手动编写，而非编译目标。就像人们忘了没有电饭煲照样能煮饭。
没错，我受够了各种依赖项、流程、工作流和配置，干脆像2004年那样纯手工制作网站——纯手写HTML+CSS+JS。只要是小型个人网站，这种方式非常稳健，既没有持续更新的压力，也不必面对为改而改的淘汰机制。
我还有几个完全手写的网站。问题在于当页面超过十几页时，操作就变得棘手了。如果需要跨页面修改某些内容(比如添加元标签)，而不能用查找替换功能处理，就会变得很麻烦。我很快会把其中一个网站迁移到Swift Publish框架，因为这个低依赖框架已经多年未更新了。
当然，但许多人只想搭建极简的学术网站(正如楼上所述的“简约学术风网站”)，仅需一两页内容。结果他们开始折腾各种框架，几个月后想更新论文时发现编译链已崩溃，不得不翻查版本、依赖项、环境配置、CI/CD流程等繁琐环节。其实你完全可以在一个下午手动编写好网站，它就能永久稳定运行。
我尝试过通过手写HTML和CSS(借助LLM辅助)定制扁平页面，这种方法确实能实现类似你链接的网站效果。
成果尚可，但长页面的布局组织仍有优化空间。我认为优质个人网站应包含照片、姓名、所属机构展示区，辅以简洁的导航菜单(如个人简介、发表作品、项目展示)，采用专业风格(字体与配色)但避免过度复杂。发表作品页可设计成整洁规范的论文列表展示形式，这可能需要预设布局且具备一定定制化与创新性的主题模板。
我考察过的许多主题都略显业余。
若你已被AI洗脑，直接让Claude根据手写.MD文件自动生成即可
这番讨论正转移人们对万维网窘境的注意力。
若说Facebook等巨头之外尚存可取之处，那也寥寥无几，实在令人难堪。
这里也有许多相关讨论帖。但本帖主题是CSS样式设计。
注意：本文推荐的CSS方案远不及本站实际使用量，我统计至少有300行代码。不过仍是不错的基准参考。
感谢你为移动端用户做了侦探工作。这个事实严重削弱了该媒介的传播效果。我稍后会亲自验证；在此之前，我仍希望它能践行文中描述的技术理念。
文章多次强调这是可扩展的基础范例
我自己已逐步将CSS精简至零，因为几乎每次调整都会破坏无障碍体验而非改善它。通常应由客户控制样式，用户根据自身需求自行配置。关于文章的建议：
> 确实，图片可能引发溢出问题。
所谓的“修复方案”破坏了缩放功能。
> 总体而言字号也略显偏小
网站擅自更改用户偏好的字体、字号、样式等设置令人恼火，常导致文本难以辨认。此处虽将字号放得过大，但更常见的是故意缩小至无法阅读的程度——显然也是为“修正”默认设置。
> 鉴于众多用户偏爱深色模式，建议根据系统偏好启用该功能。
“color-scheme”就像“viewport”：向浏览器宣告网站并非完全失效，应更合理地运行。这些方案虽实用却仍显笨拙，并非理想状态——我更希望浏览器默认采用合理行为。因此我将其视为两种选择：顺应现状或推动变革。
> 通常我们希望正文文本(非标题)的每行字符数控制在45-90个之间。
在彻底移除CSS之前，我也曾用ch单位设置最大宽度，但桌面浏览器窗口通常可自由调整大小，留白空间本该被有效利用，而非填充背景色。在epub文件中也常见到类似情况：强制设置巨大边距，若不需要这些边距则相当烦人；而需要时只需调整窗口大小即可(或设置默认样式作为另一种选择)。
所以你直接用了https://motherfuckingwebsite.com/？
仍需大量重置样式——至少要确保基础一致性。
若仅针对现代浏览器(五年更新周期)，可精简那个流行的重置样式库。
重置功能被高估了。像楼主这样搭建个人博客这类极简配置时，其实根本不需要跨平台保持高度一致性。所谓为一致性而重置，大多只是设计师思维无法接受不同场景下界面略有差异却完全正常的事实。
说得太对了！这正是“入乡随俗”的精髓，可惜我从未让公司团队接受过这种理念。
iPhone SE上的下拉菜单本就该与台式机超宽屏显示器呈现不同效果！
这无关一致性，而是基本可读性问题。不同平台/浏览器下呈现形式可有差异，但必须保持可读性。不必追求审美完美，但至少要比1994年的默认样式更实用。
> img { max-width: 100%; }
这 必须 配合
height: auto使用，否则当宽度受限时图片的宽高比会被破坏。> img, svg, video { max-width: 100%; }
…但需注意，Chrome 141版本对嵌套SVG元素的CSS宽高计算存在问题，auto值会被错误计算。解决方法是将
svg替换为svg:where(:not(svg svg))。> 本示例仅使用基础系统字体。当前系统支持良好，且无需加载额外字体即可在所有系统中呈现良好效果。
请勿使用system-ui字体。该字体专为匹配系统UI设计，通常不适合长文本内容，在某些非主流操作系统/语言组合中几乎无法使用。若需无衬线字体，请直接选用sans-serif。有人将其作为替代性无衬线字体的选择，但这并非其设计初衷，此类用法实属不当。
> 总体而言字号也略小，可适当放大
大屏幕环境下此方案可行。建议目标值设为18–20px，即1.25rem即可。但小屏幕设备请勿超过1rem——这是平台默认尺寸，空间本就有限。
> 默认行高总是略显紧凑，1.5至1.7的范围都适用
哎呀。1.7在小屏幕上简直 巨大。若需固定值，建议1.4–1.5。若按宽度调整，小屏1.4至大屏1.6较为合理。
> font-family: System UI;
这是第二个显而易见的错误，使用样式表时应立即察觉。其质量令人担忧。
> 有人偏好深色系统主题搭配浅色网站主题，反之亦然.
合理的 浏览器允许分离两者。Firefox默认让内容遵循系统主题，但可切换为纯浅色或纯深色模式。
> main { max-width: min(70ch, 100% – 4rem); margin-inline: auto; }
这实际上设置了2rem的最小内边距。准确来说是2rem + 8px(包含默认body边距)。这种设置不仅过大，应用方式也完全错误。
若需应用于主元素，使用内边距会更简洁合理：
但我怀疑你真正想应用的是body：若网站头尾部独立于main，你可能仍需保持侧边填充一致。因此使用body margin更合理：
…同时我将原本过高的
40px间距调整为合理的16px。实际操作中，多数布局差异和精细调整可通过媒体查询实现。此时代码量相较于采用“常规”CSS量、编写规范的网站仍相当精简。
在我为孩子搭建的网站中，侧边栏添加了可拖拽的字体切换滑块。此功能仅为个人需求开发，不确定是否对他人有用。
https://kids-math.xhtml.jp/worksheets/TMMNHTRFEPNA
必须提及
https://motherfuckingwebsite.com/
以及
http://bettermotherfuckingwebsite.com/
升级版在超宽屏上简直像垃圾
没错，这就是我的标准。
我觉得第一个更好。把所有文字挤在页面中间的窄栏里到底有什么意义？用宽屏看网页时，他妈的就该让我用满整个屏幕啊。
我在其他评论里贴过研究论文链接，不过普遍认为50-70个字符/行(CPL)最适合阅读。阅读速度快的人更喜欢短行。
从版式设计角度看，这就是报纸采用分栏排版的原因，书籍也普遍遵循这一限制。
即便上述说法成立，超宽屏幕仍是首选。我确实更喜欢在超宽屏幕上查看代码和文本。
在这方面，HN表现卓越。
这确实是个人偏好，且可能因人而异。
我同意“HN设计出色”，只需将主表格的“85%”调整为个人偏好值——我的设置是“70ch”，你的情况则改为“100%”即可。
我好奇编程时究竟需要多宽的屏幕——根据经验，去除IDE边框装饰后，代码通常只占据屏幕一半左右。
日常使用超宽屏时，我习惯并排停靠两个窗口，并未感到局促。不过偶尔也会怀念4:3比例的时代。
眼球肌肉速度限制了阅读速度(至少对我如此)。我的眼睛根本跟不上阅读速度左右移动，还要额外消耗精力追踪行号。因人而异。
>> …在iMac上操作，或者他妈的电子宠物…
笑死。
这个对比出现在关于设置宽度的热门讨论中很有意思。我赞同@kmoser的观点。原版设计在我看来更美观，而且我喜欢能自由调整的灵活性。
我钟爱这类网站，它们不仅凸显现代网页设计的复杂性，更证明网络天生为内容创作而生。这个“他妈的网站”概念衍生出无数变体与观点，建议所有网页设计爱好者去谷歌搜索这个词汇，好好研读其中内容。
https://evenbettermotherfucking.website/
https://thebestmotherfucking.website
我喜欢这个。但每步操作后附截图会更理想。
几十年前排版文本需使用troff等工具，用户必须记忆并嵌入代码才能实现格式化。后来PageMaker这类所见即所得工具终于普及，只需在屏幕上拖拽元素即可完成设计。HTML和CSS反而像是倒退。我认为没人能记住所有CSS代码及其副作用，新特性又层出不穷。我自己就无法从零“编程”出复杂布局，总得找现成模板照搬。
设计个人网站时我也陷入过同样的困境，最终觉得CSS整体存在冗余。我同样反对禁用默认字体家族(除了审美考量外，实在看不出它们有何弊端——而我浏览过的所有网站从未因字体问题产生过困扰)，也不赞成限制内容宽度(有时用户可能需要更长的行距来适应窗口尺寸)。另建议确保手机纵横屏模式下字号一致(据我记忆横屏文本比竖屏更大)。
人类对文本行长的感知存在生理极限——超过特定长度后，视线跳转至下一行的难度会显著增加。若测量报纸、杂志或小说中单行的字符数，你会发现其上限约为100字符，下限则在30字符左右。超出任一范围都会降低阅读理解效率，显得业余。利用样式强制实现良好可读性正是CSS的绝佳应用场景。
技巧详见：https://practicaltypography.com/
有趣的是，技术纯粹主义者有时会忘记：在网络诞生前，排版学已被研究了上百年。维基百科因采用被认为更易读、更利于理解的设计而遭抵制，就是个有趣的案例。
我能接受用类名而非媒体查询实现暗黑模式的js方案。这样用户可通过切换按钮灵活控制部分网站明暗模式。编辑：其实文章里已经提到了。
顺便说一句，无需任何javascript就能添加明暗切换按钮。只有当你想将偏好设置持久化到localStorage时才需要javascript。
这里有篇Reddit热门帖，仅用HTML和CSS实现了三态切换(自动/浅色/深色)：https://lyra.horse/blog/2025/08/you-dont-need-js/
哇这篇文章太棒了
> …同时允许用户手动切换配色方案是最佳实践。
> 部分用户偏好深色系统主题搭配浅色网站主题，反之亦然。
这种情况常见吗？为什么这些人不去配置浏览器使用浅色主题？或者如果他们希望不同网站采用不同主题，为什么不使用浏览器插件？
…更普遍的问题在于每个网站都不得不重复实现许多功能。这虽是小问题，却会阻碍新用户入门，而每个网站的冗余功能累积起来影响巨大。理想状态下，网站在 无CSS 时也应保持基本美观。但为兼容旧版网站(本是好事)，默认样式却沿用了过时规范(实为弊端)；甚至保留了当年就该被视为“漏洞”的缺陷(如同犯罪行为合法化般，这些问题因发现太晚反而成了“特性”)，例如大图导致的横向溢出。说真的，将默认字体设为16px的Times New Roman，难道真有正当理由吗？
浏览器本应支持按站点切换深色模式CSS偏好，就像支持按站点调整缩放比例那样。
将整个浏览器强制设置为浅色主题是错误方案——某些网站在深色模式下更美观，某些则适合浅色模式。此外，浏览器设置还会影响浏览器本身的界面，而不仅限于网站内容。
这些问题当然可解，但最显而易见且简单的处理方式，就是在缩放偏好设置的同一位置为每个网站额外存储一个标记。
老生常谈的“技术可行，只是浏览器拒绝实现”。
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/…
这种设置会持久保存吗？比如我为某个网站选定样式表后，后续刷新页面或再次访问时是否仍会沿用该样式表？浏览器对缩放比例的记忆功能很常见，但这种功能的应用场景远不止于此。
遗憾的是Firefox不会记住设置。
能实现这种功能的浏览器扩展需要完全访问网站内容的权限。正因如此，有些人选择不使用这类扩展。
若要在敏感网站使用需要完全权限的扩展，我通常会先查看源代码，再手动下载安装。这类扩展很少需要更新，且安装后无需担心后续注入风险。
虽然我已很久没折腾浏览器扩展，但默认情况下它们应该没有网络访问权限。肯定存在仅具备页面读取权限而无网络访问权限的扩展吧？
编辑：这个看起来相当安全https://github.com/the-code-rider/dark-theme-extension/blob/…
修改网页的浏览器扩展本质上就是注入到页面中的JavaScript代码；它们绝对能访问互联网。
我认为这并非对浏览器扩展的准确描述。内容脚本确实如此运作，且许多浏览器扩展包含内容脚本…但并非所有扩展都使用内容脚本。
无论如何，快速浏览我链接的扩展代码可见其确实使用内容脚本，但并未进行任何网络访问。
听这家伙为垃圾网页浏览器辩护以支持谷歌！多说说传统论坛如何不堪入目，以及你那位为股东而非用户赚取数十亿的爸爸有多么正确吧。
我偏好白天亮屏/夜晚暗屏。我的调度程序会按此模式开启系统，其他设备随之同步(如支持自动设置的应用和启用暗读模式的浏览器)。
这在移动设备上尤为重要——白天亮屏反光严重，夜晚亮屏则刺眼。
我认为默认样式尚可，没某些人说的那么糟。不过针对含图片的网页，我会添加以下样式：
(这正是该文章提及的内容之一；正如文中所述，此举对视频和SVG同样合理。)但若用户不喜欢这些样式，应允许其进行自定义。若此机制与采用冲突样式的网页产生问题，可考虑添加属性指定优先使用用户自定义CSS(当网页未声明该属性时，浏览器可自动判断——例如样式仅关联媒体查询和HTML元素名称而非ID/类名等情况)。用户仍可选择完全禁用网页CSS，但此机制将允许针对特定网页或应用中的样式类及复杂元素明确排除网页CSS的覆盖。(若用户未定义自定义CSS，则采用网页内置样式(若网页无CSS则使用默认值；不过默认值应调整为支持无CSS网页的明暗模式切换)，此时前述假设属性将被忽略。)
我实在无法欣赏一篇CSS教程，作者第三步就直接覆盖用户的字号偏好。
傲慢至极。
不过倒不如那些混蛋恶劣——他们越是强调重要内容，字号就越小，对比度越低。醒目的标题用巨型可读字体反复堆砌，真正关键的内容却用灰底灰字的缩微胶片效果呈现。
至少他们把字号调大了，不是缩小。用户偏好设置还能自行调整大小。
见鬼，Hacker News的评论字号居然比默认还小。
这让我想起我那篇关于使用Markdown时通过CSS样式化所有相关组件的指南：https://webdev.bryanhogan.com/miscellaneous/styling-markdown…
我也用过一段简易CSS，虽不完美但能满足以文本为主的网站需求：https://cass.run/basecss
令人想起《4分钟网页设计》：https://jgthms.com/web-design-in-4-minutes/
好吧，但后来发生了什么？多年杳无音讯。
max-width: min(70ch, 100% – 4rem); 导致桌面端仅显示一列微小文本，两侧留白。这是专为手机设计的界面。
100% - 4rem适用于移动端。`70ch`适用于桌面端。窄列设计是刻意为之，相较于宽屏显示器上密密麻麻的文字，这种布局能提供更佳的默认阅读体验。这是对旧版建议的实现——每行不超过80个字符，表面上是为限制水平视线移动，但主要源于早期80字符终端和穿孔卡片的技术限制。
考虑到当今高分辨率显示器支持更小字号，该建议的价值颇值得商榷。768p分辨率下可读的80个字符与4K分辨率下的80个字符体验截然不同。
50-70个字符的行长通常最适宜阅读。相关研究已证实此结论，快速检索即可找到这篇排版精美的论文：https://journals.uc.edu/index.php/vl/article/view/5765
令人惊讶的是，该论文得出的结论是：阅读速度快的人更偏好较短的行长。
编辑补充：书籍和报纸通常也或多或少遵循这一规范，而这些媒介在计算机普及之前就已存在。
作为经常使用屏幕缩放工具的人，我支持80字符列宽的建议。若需支持超宽显示器，建议采用多栏布局而非单宽栏。
多栏布局在网站上难以实现，因网页内容几乎都需垂直滚动。
侧边导航栏或图片网格等场景适用多栏，但长篇博客内容则难以兼容。
有道理，但过长的行距同样不可取。
这其实可追溯至机械打字机时代，其每行限制在70至90个字符。常用的穿孔卡片同样采用80列规格。这两者共同促成了计算机终端80字符行的设计。
呃，其实！…这可追溯至印刷术早期，此后便成为普遍惯例。
规则可以打破，但打破必有代价。
我讨厌这样。给我们一点点内边距和自动换行吧。让大屏幕用户自由调整浏览器宽度。现在不是1985年了，我们用的又不是每行只能显示80个字符的终端机。
> 让大屏幕用户自由调整浏览器宽度。
真有人这么做吗？我最大化的浏览器窗口里开了十几个标签页。难道要我反复取消最大化调整宽度？还是干脆拆分标签页，忍受多个浏览器窗口的混乱？
你用大尺寸高分辨率屏幕还把浏览器最大化？
我用4K屏幕时，浏览器基本都保持半宽状态。对多数网站而言，这似乎是最佳的屏幕空间利用方式。即便缩小到半宽，某些网站的CSS仍过度限制内容宽度，导致两侧出现大量浪费的填充区域。
我个人非常推崇https://every-layout.dev的设计理念。
你的评论里就提到了。根据可用性研究，更多用户偏好另一种方案。你应该将默认样式调整为更具普适性的设计。
而且，不，我绝不希望在32英寸显示器上阅读全宽文本。我频繁切换的其他网站需要占据整个屏幕空间。
报纸的版式比任何网站都更窄，却已传承数代。
更多网站应该效仿这种设计
为什么？JavaScript膨胀问题严重，但我从未在任何网站遇到CSS相关困扰。如果真要说的话，我更希望更多网站支持深色模式。
CSS膨胀确实存在，但或许没那么严重。我认为复杂性才是主要敌人(无论是JS、CSS、React还是npm…)或者WordPress插件的泥潭。我欣赏楼主追求简洁世界的理念，类似我目前偏好的HTMX和Pico CSS理念。
> 或许问题不大
此刻加载CNN.com并滚动到底部，我接收到的数据包达26.9MB。
其中CSS占52.2KB，
JS占5,547KB。
CSS膨胀根本不算什么大问题。
52KB的CSS本可优化，但你说得对——我们对JavaScript的依赖已根深蒂固，当前更应解决大问题而非小细节。
好奇其中多少JS是功能性代码，多少是广告软件。
广告软件通常由第三方注入页面，网页开发者对此无能为力。
> 其中多少JS是真正有用的
很多网站在禁用JS后反而功能更完善。
我更想知道其中有多少JS是专门用于加载其他已被拦截的脚本(被浏览器、广告拦截器、主机文件/DNS等阻断)。
虽然我很少访问CNN，但多数新闻网站都会加载大量第三方内容(移动端难以验证)
拒绝垃圾代码本是网页开发者的责任。然而鲜少有人践行，甚至有人将代码膨胀视为工作保障。
这根本不符合网络运作逻辑。
这好比要求其他软件开发者“拒绝”让其他程序与自身并行运行。这根本不在其职责范围内，任何试图让程序实现这种行为的尝试都将难以维护。
若企业想不受阻碍地注入广告，只需将页面托管在开发者无法触及的地方。出于诸多合理考量，这通常会采用CDN等方案。因此内容安全策略如今只能由根本不在乎且不知晓托管内容的管理员配置。
改用lite.cnn.com即可。
Tailwind v4也支持树摇动，所以严格来说它也不再臃肿了
树摇动和代码膨胀是两个不同问题。而且Tailwind真的算树摇动吗？我以为它只是构建编译器能检测到使用的样式，而非移除编译器无法检测到的样式。
据我理解，Tailwind v4会在导入时自动进行树摇动。
虽然机制未必完全等同于包级别的树摇动，但最终效果相同。
我认为v4之前并未实现此功能，即便有也效率不高。
树摇动本质是代码膨胀的标志。它只是在臃肿混乱的代码之上，用来修复混乱的工具。与其事后修复，不如从源头避免混乱。
树摇动真正有效的语言是那些被设计成可树摇动的语言，而网络语言中并不存在这样的设计。
若采用ESM规范，TypeScript/JavaScript完全具备树摇动特性…你凭什么否定？
仅限最基础层面。听说过“虚函数”吗？
运行时多态性固然出色，但我不会将其视为树摇动优化。
即便少量CSS也会拖慢页面渲染速度。https://www.granola.ai/blog/dont-animate-height
该文章仅提及一行CSS代码。削减CSS体积毫无价值，削减动画等高成本指令才真正有效。
若少量CSS能造成影响，那么同样少量的JS也可能产生影响，毕竟JS同样能设置样式。
我认为这毫无意义。大家都认同JS存在相当严重的臃肿问题，主要并非源于单个耗费资源的代码行(虽然确实存在)，而是整个依赖生态系统造成的。
为什么不行？代码是负担。减少维护代码量能增强工程师理解代码的能力，从而实现更优质的网站。
代码作为负债容易形成技术债务，耗费时间重构CSS以缩减几十KB的体积，在多数情况下根本不值得投入。
这是必须的
* { box-sizing: border-box }
为确保外部库的兼容性，我更倾向以下方案：
`body, html { box-sizing: border-box } * { box-sizing: inherit }`
先提升可读性与清晰度，再追求现代化。
我依然认为文档中应设置`清除用户代理样式`选项。既然开发者最终都要推翻那些花哨的默认样式，何必让他们额外部署重置CSS？以下是我预见到的反对意见及反驳：
> 浏览器必须保留最小限度的默认样式！
历来如此。我的建议并不影响这一点。
> 网站不该能关闭默认样式！
许多网站实际上早已通过CSS重置或直接使用h1 { color: red }实现。
> 这有什么意义！？
现存十余种流行的CSS重置方案，本质上就是覆盖所有浏览器默认样式。不再重复传输相同样式，既能节省时间又能节约数据流量。
> 这根本不可能实现！
并非如此。只需告知浏览器完全不应用任何样式即可。这对浏览器开发者而言是项简单直接的功能。
那这样呢
确实有效。
这是新版reset.css吗？
最小值确实可以是零。
超级实用！
我都没看文章，答案显然是零。
默认样式在移动端几乎无法使用，尤其涉及图片时。毕竟他们说的是“看起来还行”。
浏览器默认字体是衬线体。
这真会让你放弃阅读？大学课本和讲义你到底是怎么熬过来的？
衬线体本就该印在纸上，配合打印机那离谱的DPI。
这些字体根本没为像素化显示器设计。没错，在视网膜/高DPI屏幕上效果确实更好(我甚至喜欢某些衬线字体在这些屏幕上的表现)，但这类字体必须以像素为设计考量。而在“经典”像素密度下，它们通常惨不忍睹。
顺带一提：印刷行业可选字体远不止“普通”的Times New Roman，而根据我个人经验(样本量为一)，这种情况其实相当罕见。
当然会。人们阅读大学教材别无选择，但面对你网站的可用性时他们有选择权。你或许不在乎，但你并非用户。
请记住评判标准是“体面”而非“可辨识”。
既然大家如此反感，或许该考虑修改默认设置？
“我们”指的是苹果谷歌巨头们的代言人…
这本就是浏览器提供的选项。
赞同。
reset.css
可惜高效CSS已成泡影。我热爱这类工作，打造高效的单页产品。可惜没人关心你如何节省字节——这不过是反社会者与厌倦他们垃圾的群体之间的战争。
我本可以为那些抢劫周围人的失败者制作炫酷网站，但那些靠网络行为牟利的人，本质上就是贪婪的恶棍。
兄弟，你简直说出了我的心声。
你不想在HTML里加个尾风段落类？/s
让网站看起来像样的最小CSS配置就是：prefers-color-scheme: dark。
听见没，HN？
拜托别这么做。该由我决定用深色还是浅色模式阅读。想要深色模式就改浏览器默认设置，别管我们正常人。
当然，但现在我们无法选择对吧？而且不，我不想为这么简单的功能安装任何扩展。
如果网站强制我使用深色主题，我就直接关闭。我讨厌深色主题，因为它们让所有文字对我来说都变成模糊不清的乱码。
直接用Dark Reader吧，你不可能教育全世界。
> 为提升网站可读性，我们将限制内容宽度
请别这么做。尽管可用性研究怎么说，我宁愿看宽屏内容也不愿每隔几秒就滚动屏幕，让眼睛追着移动的文字跑。作为用户，我完全可以通过调整浏览器窗口来控制内容宽度，谢谢。
调整浏览器窗口大小只会改变浏览器本身。页面其他内容、当前标签页(所有主流浏览器均如此)以及包含这些标签的窗口都会同步调整。这种做法如此荒谬，我不得不认为这不过是披着伪装的外衣，试图让所有用户都陷入更糟糕的体验，只为迎合你所谓的偏好。
我深有体会，因为这正是我临时“修复”那些垃圾过时网站的方法——当它们把80列文本全部堆在屏幕左侧时，我只能缩放浏览器窗口让文本居中显示。这简直令人抓狂。这种烦扰有时甚至逼得我耗费(虽短暂却充满怒火的)时间直接覆盖网站样式表。既然如此，还不如直接给我纯文本内容。说到这，我确实有时也会直接切换阅读模式。
若个人不喜欢文本宽度，当然可通过多种方式调整偏好：(1)响应式模式 (2)用户样式表 (3)阅读模式。或许还有其他方法。但请别试图将个人偏好强加于人。
> 你当然可以采用多种方式实现个人偏好
见上文…
> 但请别试图将个人偏好强加于人
限制列宽本就是主流既定模式，甚至可追溯至印刷时代，此言实属无稽。除非我将其解读为廉价幼稚的反击——不得不说，这番论调倒与之相得益彰。
所以任何与现状不符的提议都自动成为无稽之谈？这真是…极具“进步”思想的思维方式。而任何违背当前潮流的观点都是…幼稚的反击？哇哦。先生您真是位觉醒者。感谢今日与我们分享智慧。
> 所以任何与现状不符的观点，都自动成为无稽之谈？
不。声称我试图强行推动既定之事发生，这才是荒谬的。因为你看，它早已发生。我至多能强化它，使其持续存在——这与你所遵循的模式截然不同。
> 这似乎是种非常…进步的思想。
我甚至要说这根本是自相矛盾的循环论证！
> 那其他人所有违背当前趋势的言论都是…幼稚的反驳？
不。利用我的话语含糊其辞地表达观点，而非直接陈述，以此激怒对方——这才是幼稚的反驳。就像你现在又在做的事。
> 哇。先生您真是位开悟者。
可惜我远未达此境界。若真开悟，我根本不会浪费时间应付这种对话——它们本就是刻意设计的蠢话，只为消耗他人时间与精力。难道这不正是你的初衷？
必须说，你差点就骗过我了！当我明确列出三分之二的解决方案后，你竟还重复强调“模拟设备”‘注入样式’“阅读模式”这些权宜之计，明目张胆地忽略它们的局限性——这种表现不仅令人不快，更透着虚伪。同样令人费解的是，你刻意回避了样式表注入或浏览器扩展这类双向操作的双重性——毕竟对方同样能使用这些手段。那么现状是否完美无缺？还是说需要改变？请你下定决心吧？
> 感谢今日与我们分享智慧。
敬礼！随时欢迎，但愿不必再等太久。
> 作为用户，我完全可以通过调整浏览器窗口来控制内容宽度，谢绝多余建议。
我认识的几乎所有技术人员和非技术人员，都习惯同时打开海量全屏标签页。前十个标签页全是单栏文本的概率为零。与其像吸毒成瘾的鸡一样不停调整窗口大小，我宁愿读点阵打印机刚吐出来的网页。
注：为强调效果可能略有夸张。
开启窗口而非标签页的艺术似乎已随时间流逝而失传。
讽刺的是，许多人抱怨主流操作系统的窗口管理器如此糟糕，而人们似乎只会把所有窗口全屏化，然后在标签页间切换。
与此同时，macOS放弃了那个绝对出色却被误解的Mac OS X绿色窗口(又名“缩放”)，它能神奇地将窗口调整到内容最大显示尺寸，却不会超出内容范围。
> macOS 放弃了那个绝妙却被误解的 Mac OS X 绿色按钮(又名“缩放”)
它依然存在。从菜单栏选择窗口 > 缩放，或按住⌥键点击绿色窗口按钮即可。
我认为它被时代淘汰的主要原因在于规范设计不完善，导致无法跨平台移植。
例如：你根本无法轻松地将你设想的桌面窗口尺寸状态发送给我。即便如此，我还得自己动手修改窗口装饰和字体。这又让我陷入了像吸毒后神志不清的鸡啄食般混乱的状态！
真希望移动浏览器能拥有真正的窗口(可轻松切换的窗口，而非那种需要进入子菜单查找窗口列表、费劲辨认哪个标签页的怪异设计——Firefox甚至连这点都不具备)。我渴望在平板上将浏览任务拆分到多个工作区，结果只能安装四个浏览器。
简直像窗口管理主要用于促进跨应用交互，而非应用内部交互… 就像标签页的发明初衷本该如此…
是人们遗失了旧技艺，还是你们从未掌握“新”技艺？
若非我们从4:3比例显示器迁移到这些荒谬的宽屏设备，这根本不会成为问题。;)
或许该有人为网页浏览器发明一个平铺式标签管理器。
在Quantum版本大肆砍掉扩展之前，Firefox曾有过这样的插件。
https://betanews.com/2014/07/12/view-all-your-firefox-tabs-a…
我其实更倾向于限制正文内容的宽度。宽屏上全宽内容会迫使眼睛每行都要从一侧移动到另一侧。
真正的问题在于浏览器不允许在不调整窗口大小的情况下控制标签页宽度，这操作起来很麻烦，会暴露窗口后方的内容，而且在标签页间切换时需要反复调整窗口大小。
若能轻松缩小标签页，我更希望网站不限制文本宽度。既然无法实现，我倒宁愿它们限制宽度——尽管这远不如用户通过标签页灵活控制理想。
(1) 阅读模式(专为此设计)
(2) 用户样式表(永久解决方案，可创建多个样式表并通过扩展程序切换不同宽度)
(3) 响应式模式(开发者工具内置，最灵活但操作最繁琐)
(4) 其他扩展程序
调整视口尺寸本就有便捷方案，因此该前提并不成立。
可将单个标签页“弹出”至新窗口。
可通过浏览器开发工具模拟窄视口。
若尚未存在相关扩展，开发此类浏览器扩展也应轻而易举。
我使用火狐的侧边栏(垂直标签页)，个人认为这样调整大小很自然
我用开发者工具的右侧面板实现这个功能。
没错，宽列布局需要视线同时进行左右移动：既要横向扫视，行尾时还需回溯左移并下移至下一行。而窄列设计若能避免水平视线移动，则仅需逐行下移视线即可。
没错，印刷杂志即使刊登长篇跨页文章也采用分栏排版是有道理的。过长的行距会让读者在行尾与行首之间切换时容易迷失方向，影响阅读体验。虽然增加行间距能缓解问题，但普遍建议每行控制在45-75个字符。
这个缩减宽度的书签工具早已成为我的常用工具：javascript:(function(){%20var%20myBody%20=%20document.getElementsByTagName(‘body’)[0];%20var%20myBodyWidth%20=%20myBody.style.width;% 20if(!myBodyWidth || myBodyWidth === ‘auto’ || myBodyWidth === ‘inherit’) { myBody.style.width = ‘1200px’; 20myBody.style.marginLeft = ‘auto’; myBody.style.marginRight = ‘auto’; myBody.style.position = ‘relative’; 20myBody.style.cssFloat%20=%20’none’;%20}%20else%20{%20myBody.style.width%20=%20’auto’;%20myBody.style.position%20=%20’static’;%20}%20})();
谢谢，这招挺有意思。
若有人想了解具体做法，这段内容经过美化处理。
这段话相当精辟地概括了网络贫民窟的现状。
> 作为用户，我完全可以通过调整浏览器窗口来控制内容宽度，谢谢。
但作为用户，我不会这么做。因为有无数网站需要在最大化浏览器窗口中浏览。限制内容宽度反而能帮助像我这样无法/不愿调整浏览器窗口的人。
这条评论能排在顶部，恰恰说明你不能把HN的建议当真。
这简直违背了网站的精神。“无视实际研究，只顾我个人的N=1偏好，还以为用户会不惜跳过各种不明显的UX障碍，去实现本该默认的行为。”
看到这种评论高居榜首，倒觉得挺符合HN风格。不得不承认你下面那条评论也相当应景。最讽刺的是这竟成了讨论最热烈的论点。评论区这十年来简直像个旋转木马。
实际上，你正在做你所批评的事情。你建议将个人偏好强加给用户，而他们主张不应如此，应让用户自行选择——却未明确说明用户该如何选择视口/内容宽度。
老实说我更同情后者。让浏览器厂商去研究如何为用户提供便捷的控制选项吧。让他们添加列数、列宽上限、间距等参数的覆盖设置，或者交由扩展程序处理。总之别指望每个网站都来规定我的阅读方式。
我的核心观点是：应重视用户体验研究而非轶事偏好，并认识到极少有人会手动调整视口大小来浏览网站。
若网站需要浏览器扩展才能舒适阅读，说明设计本身存在缺陷
请别听信这种观点。持有这种偏好的人属于极少数群体。多数读者偏好50-75字符的行长，类似小说排版。报纸版面甚至更窄以利于快速浏览。若阅读内容需要我转动头部或调整浏览器大小，说明格式设计存在缺陷。
你也可以采用多栏排版显示文本。
既解决了段落宽度“可用性”问题，又能充分利用屏幕空间
不明白为何从未流行…我同样厌恶当下流行的巨型白色侧边栏
因为会增加滚动频率？要减少滚动，多栏文本的列高必须与可用视口高度匹配。若文本超出单屏多栏显示范围，滚动操作同样会变得笨拙——必须精确滚动到下一屏才能保持内容连续性。多栏文本仅适用于极端受限的布局场景，或文本内容完全独立而非连续流式呈现的情况，又或是存在直接水平关联的场景(如正文旁的注释或译文)。
> 若文本超出单屏多栏显示范围，滚动操作将变得笨拙——必须精确滚动至下一完整屏幕才能保持视觉连续性。
这个问题本已解决，直到所有网站都开始在实际内容上方悬浮多个超大“广告横幅”，占据15%以上的垂直空间。过去按下键盘的“Page Down”键能精确滚动一个屏幕高度。大多数操作系统的滚动条也支持单击精确滚动一个屏幕高度。
>必须精确滚动到下一屏内容才能保持一致性。
或者向右滚动。(不过这可能更糟，我不确定。)
有趣的想法。或许可以设计“向右移动一列”的标准操作。
哦好问题
我从未遇到过这个问题，因为需要海量文本才能填满整个屏幕。我的内容有自然分段和子标题，每个部分都独立包裹在专属列中
我想要实现这个效果，最终也会加倍努力去实现它，但根本原因在于CSS无法做到。当内容超出屏幕显示范围时该怎么办？若仅遵循默认CSS行为让列高度超过屏幕，用户就会陷入无休止的滚动困扰，体验糟糕透顶。若向右增加更多列，很可能需要借助JS布局，但桌面端体验依然不佳——每块内容都需要更多滚动操作，而大多数桌面设备缺乏直观的横向滚动控制。理想方案是创建视口尺寸的“页面”，每页动态调整列数，但这本质上需要用JS实现全新的布局模式。曾有个项目致力于让JS更好地对接布局引擎，但现在似乎停滞了，不清楚进展如何。还有个奇怪的操作：从右下角滚动到左上角时会突然跳转，你可能需要在此处添加提示或UI，甚至考虑实现列间跳转——毕竟我们正在打破常规。值得庆幸的是滚动吸附功能现已纳入CSS规范，无需再精确滚动至下一屏内容。但这意味着用户将失去在视口内自由布局元素的能力。你需要重新实现锚点链接功能，用户无法再直接定位页面顶部。当用户调整窗口大小时，界面将彻底混乱，而浏览器试图保持内容“原位显示”的机制可能加剧混乱，你需要确保界面至少维持基本可读性。一旦出现非文本内容，列宽就会显得过窄，因此你必须从一开始就实现复杂的跨列布局方案。所幸CSS提供“禁止跨列分割”等控制手段，但深入实践后必将发现其局限性。线性关系也遭到破坏——内容的上下层级关系不再绝对对应。
我依然对这种布局感兴趣，但正因如此才无人采用：从网页开发者角度看复杂度大幅提升，执行稍有不慎便会出错，即便完美实现仍存在缺陷。
我认为它在视口尺寸和内容均在设计时确定的场景中仍具吸引力。
记得有人力推CSS特性(应该是Adobe)，试图实现溢出内容自动流向其他容器的效果，就像Publisher软件里(曾经？)能做到的那样。我一直渴望这种功能，多次尝试过，可惜最终被放弃了…
此前并不知晓。若结合CSS网格自动填充功能，或许能解决大量分页列排版难题。
我认为Shift+滚动操作相当直观，几乎适用于所有带水平滚动条的场景。
不过当用户调整窗口大小时，从三栏切换到双栏再到单栏确实有点烦人。我博客里干脆让用户直接调整窗口大小来压缩文本。
真好奇为何浅色/深色主题几年就成了标配，而我们仍在乞求宽/窄主题或不同字号的双/三主题方案。这些功能同样实用。当然，我和其他开发者一样难辞其咎。
虽然现有窗口缩放功能确实存在，但往往会破坏设计布局。
科技领域向来如此，总要等到某项功能成为潮流才会普及，我们只能静观其变。
我并不介意限制内容宽度。但我反对“请滚动阅读两个词”的三重组合：内容宽度限制+大字体+大行距。
多数网站滥用后两项，害得我的鼠标滚轮像没药吃的瘾君子般疯狂转动。
请保留默认字号。它与系统字号一致，正是浏览器缩放功能应适配的标准。
关键在于你的评论本身。可用性研究表明多数人更倾向另一种设计。你理应将默认样式调整为更广泛适用的方案。
而且不，我绝对不希望阅读内容在32英寸显示器上占据全屏。我频繁切换的其他网站才需要占满整个屏幕空间。
报纸的版面比任何网站都窄，但它们已经存在几个世纪了。
作为移动设备用户，我无法调整浏览器大小。这个功能曾经短暂支持过 (我记得？或许是Firefox和Chrome曾作为Windows 8 Metro全屏应用的短暂时期)，如今已不复存在。
恕我直言，当“请勿做X”中的X既是绝大多数用户偏好的功能，又具备广泛科学依据时，这种要求听起来有些…理所当然？
这与特权无关。如果你根据可用性研究选择一个任意宽度，可能会让大部分用户满意，但如果允许用户通过调整浏览器大小来设置宽度，就能让100%的用户满意。为什么不选择后者呢？
你无法让100%的用户满意。事实上，我认为这会让多数用户感到不满。我不愿为每个网站调整浏览器设置，更希望网站本身具备良好的可读性。相信大多数人也是如此。
我的窗口始终保持最大化状态，绝不会浪费时间调整尺寸。遇到超宽网页时，我通常直接按F键打开开发者工具进行压缩。
若用户需要通过调整窗口大小来设定宽度，他们也可以右键点击 -> 检查元素 -> 禁用div元素上限制宽度的CSS样式。这比调整窗口宽度多几下点击，却能避免影响更多用户。
如今设计臃肿且充斥着居高临下的前端开发者，实现起来往往没那么简单。你可能得删除十个样式才能摆脱那些装点花哨文本的冗余容器。不如不做任何偏好设定，直接通过标准浏览器工具赋能用户——若用户对此表现出显著兴趣，这类工具必然会应运而生。
调整浏览器大小既麻烦又令人不快。尤其当我采用桌面平铺模式时更是如此，即便不用平铺模式也一样。
若真想满足所有用户，不妨引入通过Cookie保存的偏好选项(读取偏好设置，实现起来很简单)。毕竟没有放之四海而皆准的解决方案。
> 但若允许用户通过调整浏览器窗口宽度来设置，就能让100%的用户满意
认为100%用户会乐于为获得舒适的页面显示效果而反复调整浏览器窗口，这种想法极其无知。
我不会每次点击链接或切换标签页时都调整浏览器窗口大小。
胡说八道。用户几乎总是最大化浏览器窗口。许多人使用2.5K或4K显示器。即便在1080p屏幕上，全宽文本也难以阅读。
我严重怀疑真有人每次切换标签页都调整浏览器窗口大小。
没错，报纸行业早就意识到多栏排版优于全宽文本是有道理的。试想《纽约时报》若只用单栏全宽排版，读者早就取消订阅了。
看来我不算“普通人”——我不最大化浏览器窗口。我喜欢同时看到浏览器窗口、Emacs和终端界面。
更荒谬的是将浏览器窗口宽度与标签内容宽度强行绑定。用户本可独立控制这两者。或许应优化操作便捷性或舒适度。但我们终需退一步思考：如何在不大幅降低界面复杂度的前提下解决问题，避免让资深用户受困。
不。绝对不行。我每天浏览数百甚至上千个网页，遇到宽度恶心的站点要么直接关闭，要么费心为其编写自定义CSS。
既然说到“用户必须成为程序员才能获得良好体验”(指需要添加自定义CSS才能正常使用的网站)，我最讨厌的是滚动条明明存在却故意偏离屏幕右边缘一像素的设计。
于是你紧贴屏幕右侧寻找滚动条——它本该出现在那里，计算机历史长河中它始终驻守的位置——点击后却发现空无一物。
这正是菲茨定律的特殊案例：当按钮位于屏幕边缘时，其点击难度会因视觉宽度无限延伸而急剧增加。
这种设计在90年代和21世纪初曾被刻意运用，显著提升了可用性(滚动条、开始菜单、显示桌面等功能)。
然而近十年趋势似乎逆转：如今流行让滚动条尽可能难以点击——通过偏移位置、缩窄宽度甚至完全隐藏。
某浏览器对所有网站都采用了类似设计：标签页区域独立于窗口主体，这本无可厚非。但该区域四周设有边距，导致每个页面的滚动条都无法延伸至屏幕边缘，彻底破坏了点击便利性。欢迎体验禅意浏览器的“天才”设计。
https://github.com/zen-browser/desktop/issues/1126是相关问题报告，因开发者拒绝修复已被关闭(故有此讽刺)。
然而在过去十年间，这种趋势似乎发生了逆转：如今的潮流是让滚动条尽可能难以点击——通过偏移位置、缩窄宽度甚至直接隐藏来实现。
据我所知，Ubuntu率先通过其精简版GTK滚动条开启了这一潮流，该设计应用于其Unity桌面环境。但这个设计其实很聪明：它在视觉上精简了滚动条，但当鼠标进入其区域时，滚动条手柄会立即出现在鼠标指针位置。因此在某些使用场景下，操作起来甚至比标准尺寸的滚动条更便捷，同时外观更美观。当然，这种可用性优势被CSS重制版和其他改造方案迅速且彻底地遗忘了。
我从90年代就开始上网，这可能是我遇见过最糟糕的观点。
只考虑自身视角真是体贴啊。
若文字密集型网站未限制内容宽度，你会如何调整浏览器尺寸？取决于字号大小？还是其他因素？
除开发/测试网站时确保不同屏幕尺寸正常显示外，我基本不调整浏览器尺寸。使用27英寸显示器时，我习惯全宽阅读。正如我最初评论所述，我发现眼睛追随滚动文本的行为极易分散注意力，而阅读超宽文本栏则轻松许多。根据网站默认字体和字号，我可能会使用浏览器缩放功能放大字体，但依然偏好全宽阅读。
有意思。我认为你绝对属于少数派，且仍坚持认为限制内容宽度对多数人更有效。
你说有时会放大字体，那么每行文字大致会控制或呈现多少个单词？你描述的行为本质上是为提升可读性，显然并非单纯追求“文字内容尽可能宽”。
我确信自己是少数派。我的偏好本质上是“每行文字越多越好”，这样能最大限度减少：a) 视线跳转到下一行开头的情况，以及 b) 频繁滚动页面导致视线与滚动同步的问题。我放大字体唯一的原因是确保阅读舒适度。不过字号也不会调太大，否则行距变短反而会重蹈覆辙：既要频繁跳行又要不断滚动(这才是我最抗拒的——比起跳行，滚动更容易分散注意力)。
你读过报纸吗？就算不读也行，看看版面设计就知道了
我不明白。我的意思是，我理解想要制作极简网页以适配所有屏幕的初衷。但若这是目标，解决方案早已成熟。这篇文章的目标受众是谁？即那些试图制作精简网页却苦于掌握
max-width的人群？为什么它能登上HN热搜？我。作为后端开发者，偶尔想为副业项目做网页前端，但几乎不懂CSS。这些解决方案对我来说“并不成熟”，因为我根本不懂CSS。
>偶尔想做网页前端
这种情况问题恰恰如你所言
> 几乎不懂CSS
解决方案也很明显：学点CSS。这并不难。掌握基础只需一个下午，深入学习常用特性(如响应式布局或弹性盒模型)再花一天即可。对构建后端的软件开发者/工程师而言，CSS真的不算难。
这并非否定TLA这类基础CSS教程的价值。
我始终坚持一个理念：软件开发者应当理解自己所用的技术。无需精通所有细节，但至少要掌握信息检索路径。从系统管理到密码学原理，从无障碍设计到操作系统磁盘写入机制——即便这意味着要持续学习。
> 解决方案其实显而易见：学点基础知识。
这正是本文的核心要义。CSS体系庞大如海，该从何入手？本文恰恰为这个自然而然的问题提供了完美解答。
它根本算不上庞大的语言体系，甚至不能称之为“语言”。虽然存在基本原则，但本质上就是为HTML属性提供可自由组合的“类”标签。我深耕CSS领域25年，至今仍主要靠反复调试直到效果满意。
这篇文章毫无意义。输入“最小化CSS”就能找到这类垃圾教程——这连垃圾都算不上。拜托，工作要讲究专业性，好好学学正经方法。
CSS是声明式语言，而非命令式/函数式语言。你只需描述期望的最终效果，浏览器会自动计算布局方案以满足所有约束条件。
而这段话：
> 但它本质上就是一堆可自由组合的HTML属性，能被封装成“类”。
表明你使用了25年却从未认真学习过它。这种说法在CSS初创时期或许尚有几分道理——那时人们只懂“font”和“[text-]align”这类基础属性，但几十年来这始终是对CSS的严重误解。
得了吧。我虽是全栈开发者，但这好比我声称想用C++快速编写代码却对它一无所知。或许我分不清指针和shared ptr的区别，也不懂析构函数是什么。但即便不会操作，我也清楚这些概念已被庞大的开发者社区 深入理解并完善文档化_，甚至不会依赖那些几乎毫无价值的AI生成文章来实现我的需求… 我真正想了解的是底层机制的运作原理…倘若真有哪篇用最空洞的方式解释指针的文章恰好适用于我的场景，我绝不会把它发到HN。若真发了还意外登上热榜，我只会觉得宇宙彻底失序了。
> 被庞大社区充分理解并完善文档
难道这篇文章不是社区成员在记录已知知识吗？若它未达你的期望我深表歉意，但对我而言完全合格。
这客观上是篇糟糕透顶的文章。它罗列一堆需要照搬的随意内容却毫无解释，对构建任何实际项目毫无价值。很可能是AI生成的垃圾。你凭什么认为它比其他百万篇同类废文更值得关注？
> 那些试图搭建最简网页却苦于搞定
max-width的人在做个人网站吗？
若想搭建个人网站，有两条路径：使用WordPress这类带图形界面的模板工具，或至少掌握基础HTML、CSS及部分JavaScript知识，同时学会服务器配置。本文提供的内容对个人建站帮助甚微…好比你想烤蛋糕，却读到“糖霜由糖和黄油制成”的教程。这既不是什么新鲜事，对制作你的蛋糕也没什么帮助。
顺便说一句：创建个人网站99%的意义在于让它真正具有个人特色——也就是说，你要投入时间精力去学习新技能。从网上复制粘贴随机CSS代码不算学习。况且，直接复制粘贴这段特定CSS代码，连最起码的兴趣都谈不上。
试想：如果你连学习如何让网站真正“个性化”的兴趣都没有——哪怕只是稍微了解你试图实践的艺术——谁还会在乎你的个人网站呢？
更别说解释这种垃圾为何在此流行。世间存在值得关注的 精妙 CSS技巧，但这连教人实用技能的儿童游戏都不如。它连教程都算不上，只是些你不懂却可能复制粘贴的垃圾，几乎毫无解释。