我非常赞同这种观点。
我们将默认字体大小从 15 像素增加到 16 像素。将代码块字体大小更改为 13 像素是一个很大的变化。每行多几个字符是否值得为了提高可读性而牺牲？
行内代码样式会更新吗？目前它们具有不同的背景颜色、字体颜色和字体系列。在大量混合了普通文本、行内代码元素和代码块的帖子中，这一点非常明显。这使得交叉引用行内代码和代码块片段更加困难。
与更改无关（但与代码块有关）——对于改进悬停时的按钮图标有什么想法吗？ 12 像素和 0.7 的不透明度几乎看不见（尤其是在与代码重叠时）
4 个赞
很棒的观察。这是因为按钮过于显眼而进行的更改。它们已更改为 btn-flat，但我明白这可能有些过于激进。也许这需要为代码块应用自定义样式？
1 个赞
是否应该调大字体大小？我昨天在本地尝试了 14px，与默认字体相比，它稍微不那么刺眼。
3 个赞
// 这是一个注释掉的代码
import Component from "@glimmer/component";
import { action } from "@ember/object";
import didInsert from "@ember/render-modifiers/modifiers/did-insert";
import willDestroy from "@ember/render-modifiers/modifiers/will-destroy";
import { service } from "@ember/service";
import DButton from "discourse/components/d-button";
import bodyClass from "discourse/helpers/body-class";
import concatClass from "discourse/helpers/concat-class";
import ReaderModeOptions from "./reader-mode-options";
export default class ReaderModeToggle extends Component {
@service readerMode;
get bodyClassText() {
if (this.readerMode.isTransitioning) {
return "reader-mode-transitioning reader-mode";
} else if (this.readerMode.readerModeActive) {
return "reader-mode";
} else {
return "";
}
}
handleDocumentKeydown(e) {
if (e.ctrlKey && e.altKey && (e.key === "r" || e.key === "®")) {
this.readerMode.toggleReaderMode();
}
}
@action
addEventListener() {
document.addEventListener("keydown", this.handleDocumentKeydown.bind(this));
}
@action
cleanUpEventListener() {
document.removeEventListener("keydown", this.handleDocumentKeydown);
}
<template>
{{bodyClass this.bodyClassText}}
<DButton
{{didInsert this.addEventListener}}
{{didInsert this.readerMode.setupWidth}}
{{willDestroy this.cleanUpEventListener}}
@action={{this.readerMode.toggleReaderMode}}
@icon="book-reader"
@preventFocus={{true}}
title="Toggle Reader Mode (ctrl + alt + r)"
class={{concatClass
"icon"
"btn-default"
"reader-mode-toggle"
(if this.readerMode.readerModeActive "active")
}}
/>
{{#if this.readerMode.readerModeActive}}
<ReaderModeOptions />
{{/if}}
</template>
}
这是最新的更新 
8 个赞
我真的很喜欢这个最新版本，@jordan.vidrine！
2 个赞
对我来说，最新的更新感觉好多了，我喜欢这些颜色，尺寸也没有与我们用于文本的 16 像素字体冲突。
def hello
puts "hello world"
end
唯一的小问题是，对我来说，灰色背景仍然感觉有点沉闷，我更喜欢稍微亮一点的。但总的来说，我对这个感觉相当不错。
@cvx 你目前的看法是什么？
1 个赞
我确实考虑过使用主题配色板中的颜色，但我们无法预测它会是什么。可能会非常糟糕 
不过我喜欢蓝色
1 个赞
您是在使用深色模式还是浅色模式？
我选择的灰色比我们之前的（我 认为）要亮。使用 var(--primary-50)
1 个赞
依我看，我们应该把这个合并到核心，它现在看起来好多了。
旧的配色方案让我在旧网站上看了眼睛疼 
3 个赞
我绝对赞成我们现在所处的位置，而不是核心中的内容。
但是，我们在提交 98b2763 中丢失了对 max-height 的更改。这是故意的吗？我看到它被注释掉了，然后在后续的提交中被删除了。
如果是这样，我仍然可以接受本地覆盖。
1 个赞
是的，它被删除了，以尽可能保持与我们当前的 codeblock 大小一致。
1 个赞
合并将在本次 PR 中完成 → UX: Codeblocks experiment merge by jordanvidrine · Pull Request #29870 · discourse/discourse · GitHub
1 个赞
好的，没关系。
1 个赞
看起来新的内边距只应用于 .hljs 元素，这意味着简单的代码块（无高亮显示）不会应用内边距：
hello
console.log("test")
这也导致帖子在初始加载时高度跳动，因为高亮显示（因此 .hljs 类）是异步应用的。
我们能否修复它，以便内边距更改应用于代码块，即使没有 .hljs 类？
6 个赞
为了保持一致性，也可以应用更深色的背景吗？
5 个赞
感谢您的关注！我已将这些样式更新为应用于 code 而非仅 hljs 代码块。
4 个赞
我需要在此处添加另一个修复程序。我添加的修复程序现在还会导致内联代码块错误地显示在单独的行上。
这是一个 内联代码块错误渲染 的示例。
2 个赞
链接现在返回 404。也许指向 PR 有意义？
UX: jordanvidrine 合并的代码块实验 · discourse/discourse 的 Pull Request #29870 · GitHub
另外，我和我的团队非常喜欢这个改动。它看起来太棒了！
3 个赞