此更改还中断了使用Unicode框画字符的帖子，如该答案所指出的。 ：
我们的行距是〜1.6。
W3C写道：“许多认知障碍者在一块文本被单行隔开时难以跟踪文本行。在1.5之间提供间距到2可使他们在完成上一行内容后更轻松地开始新的一行。”
我们希望行之间的间距更大，以提高可读性。我认为尽管在块级元素之间可以进行细化，但由于已投入生产，因此计划进一步细化页眉间距。通过评论
#1 楼
新的行高使得很难在精神上分隔段落。一眼就很难分辨出哪几行属于哪一段，而旧的行高却使这很容易区分。无论如何，让我们做我们程序员最擅长的事情;）
⭐Revert Stack Exchange格式⭐
Google Chrome扩展程序（可自定义）
Greasemonkey / Tampermonkey脚本| （仅行高）
时尚主题（+手写笔）-| [深色模式]
请更新脚本！：已更新，以修复对代码块的新更改（2020年9月24日）
移动设备：
有限的解决方案：每页单击激活的JavaScript（iOS，Android）
Kiwi浏览器（Android）-安装上述Chrome扩展程序（未经测试）
贡献：
GitHub回购-帮助我忠实地还原它！
评论
将接受标记切换为该标记以使其更具可见性。我个人不使用Chrome，但是对于大多数人来说，它可能是更易于访问的解决方案，并且它还提供了许多其他功能。
–MaxD
20-08-29在0:19
那个Chrome扩展程序非常方便，谢谢！
– Clonkex
20年8月29日在6:05
我个人不信任扩展程序，因为我无法轻松地查看其源代码，就像我可以查看用户脚本的javascript代码一样，因此感谢非Chrome用户同时包含用户脚本和手写笔用户样式
–user1306322
20年8月29日在8:20
移动设备（iOS中特别是Chrome）是否可以替代？我找不到
– hkotsubo
20年8月29日在12:48
即使使用以前的格式，旧社区成员也大量离开该平台。这个新的cr脚的家伙，很可能恰好是SO棺材的最后钉子
– mangusta
20年8月30日在3:08
@mangusta你可以去哪儿？我唯一能想到的其他网站是quora，我一点都不喜欢它。
–MaxD
20年8月30日在12:14
@hkotsubo：经过广泛研究，iOS中最接近的替代方法是使用按页面运行的一键式Javascript书签－不幸的是，您必须在每次页面加载时手动激活它。我在帖子中包含了完整的移动说明：)对于懒惰的人：github.com/Prid13/Revert-StackExchange-Formatting/blob/master / ...
–́Prid
20年8月31日在4:18
好的。至少可以将其还原回来是一件好事。不过，最好不要一开始就将其破坏。
–埃里克·杜米尼尔（Eric Duminil）
20年8月31日在7:38
@Prid非常感谢，它就像一个魅力！如果可以的话，我会投票两次
– hkotsubo
20年8月31日在10:33
您可以在此处和GitHub上修复拼写错误吗？它是“ Stack Exchange”（最后一部分-向下滚动到“正确使用Stack Exchange名称”），Stack Overflow，Greasemonkey，JavaScript和GitHub（不是StackExchange，StackOverflow，GreaseMonkey，Javascript和Github）。
–P.Mort。 -忘记了粘土Shirky_q
20年8月31日在15:52
@hkotsubo：太棒了！我曾考虑将黄色的blockquotes添加为移动脚本之一，但还是决定反对。很高兴知道您自己解决了问题：)
–́Prid
20年8月31日在20:57
@ P.Mort.-forgotClayShirky_q：在所有应有的尊重下，StackExchange在精神上比Stack Exchange更少，并且更好地表示一个主意。具有讽刺意味的是，介于两者之间的不必要的“水平线高”正是此帖子试图解决的问题。 StackExchange应该是一个误用，因为大多数访问者经常看到徽标和URL，这在传达空间方面做得很差。我会接受本网站的指南，但不会在Github上进行更改。
–́Prid
20年9月1日，1：18
@普里德：老实说，我认为空格/大写“错误”没有太大关系。每个名字的两个版本对我来说都不比另一个更容易解析。只是每个站点/插件/实体的正式名称都使用某种样式，因此只要可以合理地接近某个样式即可。
– V2Blast
20/09/11在0:38
@Prid我认为他们只是做了另一个更改以覆盖代码块中的背景色:-(
–特德·林格莫（Ted Lyngmo）
20/09/24 '16：31
@TedLyngmo：固定！只是更新脚本。 Chrome扩展程序也已更新，但需要几天的时间才能获得批准。上线后将报告：)
–́Prid
20 Sep 24 '20：34
#2 楼
这可能不应该是一个答案，但我想不出它应该去哪里。亚伦在链接的问题上评论说行高是〜1.6。
我坚持认为行高需要适合所使用的字体和普通文本中该字体的大小。覆盖率还不够；需要更多技巧。
我想大多数用户都会使用Arial。 Arial是一个不错的主力，x高度很大，但字母通常很窄。是狭窄的，相当大的字母，因此行距太宽。为了后代，这是当前排列的屏幕截图：
行高比1.6确实适用于其他字体和其他源材料。这是我维护的博客，该博客使用Calluna Sans。那是一个更宽的字体。字体大小设置为“ 1em”，由浏览器决定，在默认浏览器设置下，您可以看到字母高度（和x高度）与Arial非常相似。但它的宽度要宽得多，并且行程重。原始资料也不同。这是一个天主教徒的经文。稍稍密集的文本可能会受益于更大的行距；这样的网站看起来也很合理。但是，我认为对于SE中的绝大多数帖子来说，都是不需要的。 />大多数情况下，Stack Exchange帖子不是艺术品。它们是真实的帖子，需要轻松阅读内容，而不必担心每一行与下一行之间的关系。完全有可能看到这篇文章中段落中断的位置，但是间距（结合字体选择和可能的行长）使阅读时很难将各行关联在一起，这必须是主要目标。 >行距甚至不必是原来的值。我现在实际上找不到，但是我怀疑仍然是样式表中的1.30769231。可以扩大范围（尽管在SE要做的重要事情很多时，它的优先级很低）；我建议1.45对Arial是足够的。其他字体，例如英语上的格鲁吉亚和基督教上的Palatino，可能需要使用不同的值。
评论
具有讽刺意味的是，即使从中获得1.6的网页也完全可读，只是我们亲爱的SE显然也必须有所不同... w3.org/TR/WCAG20-TECHS/C21.html
–MaxD
20/08/27在16:36
@MaxD是的，该页面的行高设置为1.5；这是他们自己的指导原则。我想我想看看W3C是如何得出这些数字的。他们建议的范围很可能取决于我在此给出的字体考虑。
–安德鲁·利奇（Andrew Leach）
20年8月27日在16:39
同样有趣的是，它们如何位于自己范围的底部，而不是您所期望的中间位置。 Maaaaybe，因为这么大的行高实际上并不是那么好。
–MaxD
20/08/27在16:49
如果我正确解释CSS规则，则行高原为1.3。
–user289905
20年8月27日在16:54
w3.org/WAI/WCAG21/Understanding/text-spacing.html>在“相关资源”下有某些内容可以链接到整个研究吗？也许那是他们从那里得到数据的地方？
–小叮当♦
20年8月27日在16:54
@AndrewLeach在该页面上，身体的行高为1.5，而p和td的行高为1.4。
– ChristW
20/08/27在18:43
#3 楼
我希望可以恢复原状，但与此同时，我们可以使用我编写的这个迷你用户脚本以1.3的旧行高浏览。屏幕截图：
您需要一个像Tampermonkey这样的用户脚本管理器。
评论
@MaxD安装Tampermonkey（或另一个用户脚本管理器）后，单击指向用户脚本的链接，然后单击GitHub上的“原始”按钮（在右侧代码上方）。然后，Tampermonkey应该提示您安装脚本。
– NobodyNada
20 Aug 27 '17：13
用于Firefox的Greasemonkey。
–user289905
20/08/27在17:21
另外，如果您有一个用户样式扩展名（例如Stylus），则它等效于.s-prose {line-height：1.3; }（当然，可以有或没有换行符）。我最终减少了行高和段落的页边距。
– El'endia Starman
20/08/27在17:39
对于没有用户密码但正在使用uBlock-Origin的用户，可以使用element：style（details）语法设置元素的样式。因此，您所需要做的就是添加自定义过滤器，例如stackoverflow.com ##。s-prose：style（line-height：1.3！important;）。可以通过选择stackoverflow.com滴管图标（uBlock中的选择器工具），选择任何内容并将替换文本替换为##。s-prose：style（line-height：1.3！important;）来完成。
– Pshemo
20年8月27日在20:35
您应该将样式作为Stylus用户的代码块直接添加到帖子中-如果您具有样式的专用扩展名，则无需额外的用户脚本样板。 （我也意识到用户风格是将所有SE / SO / SU等网站添加为匹配规则的便捷方法，但仍然如此）
–user1306322
20/08/27在23:45
@CertainPerformance您不会碰巧知道旧的背景颜色是什么？新颜色伤害了我的眼睛。
–特德·林格莫（Ted Lyngmo）
20年8月28日在7:29
@TedLyngmo旧版：＃EFF0F1新版：＃F6F6F6参见meta.stackexchange.com/a/353550
–某些性能
20年8月28日在7:32
@CaptainPerformance您是救生员
–motosubatsu
20年8月28日在9:40
@CertainPerformance现在他们也更改了段落间距，请您也可以还原它吗？旧的“正常”线高看起来很可怕。
–val说恢复莫妮卡
20年8月28日在11:51
@valsaysReinstateMonica似乎已经在20分钟前更新了它，没有提及。
–MaxD
20年8月28日在14:31
我做了一个Chrome扩展程序，以更加简化：chrome.google.com/webstore/detail/revert-stackexchange-form / ...
–́Prid
20年8月28日在23:33
@ user289905 Tampermonkey在Firefox上也可以正常工作。这是我目前的设定。
–RobertS-恢复莫妮卡
20-08-29在13:42
#4 楼
编辑2020-09-09：状态已完成在插图中使用线条画等功能非常普遍。有了代码块上的新行高，这看起来比以前更糟。 >从此处：
┌───┬───┬───┐
│1 1│1 2│1 3│
├───┼───┼───┤
│2 1│2 2│2 3│
├───┼───┼───┤
│3 1│3 2│3 3│
└───┴───┴───┘
从此处：
┌→────────────────────────────────────────┐
│ ┌→┐ ┌→┐ ┌→┐ ┌→┐ ┌→┐ ┌→┐ ┌→┐ ┌→┐ ┌→┐ ┌→┐ │
│ │0│ │1│ │2│ │3│ │4│ │5│ │6│ │7│ │8│ │9│ │
│ └─┘ └─┘ └─┘ └─┘ └─┘ └─┘ └─┘ └─┘ └─┘ └─┘ │
└∊────────────────────────────────────────┘
评论
我确实相信真正的表确实在路线图上吗？ （您的观点仍然存在，尽管有大量旧帖子已经使用了半图形表格）
– John Dvorak
20年8月27日在16:50
@JohnDvorak-即使是这样，以上已经有数十万个答案？
– T.J.拥挤者
20年8月28日在9:09
@ThomasMarkov您不能在大多数站点中使用mathjax。
–脑袋
20年8月28日在13:58
在我看来，这似乎还没有完成。
–Luuklag
20 Sep 9 '20在16:57
@Luuklag怎么样？我更喜欢1.15，但是有了新值，它至少是可读的。
–Adám
20年9月9日在16:58
水平对齐方式是faaaaaaar的。
–Luuklag
20 Sep 9 '20在16:59
@Luuklag这是由于字体堆栈。 SE不在乎。
–Adám
20 Sep 13 '14：33
#5 楼
以前的UI可能没有问题。如果有的话请原谅我。但是，如果有的话，请将其保留为可供选择的选项。更好的是，保留两个标签，一个用于上一个标签，一个用于实验。人们可能想就实验用户界面提供反馈。通过experimental tab，我的意思是一个Theme标签。用户可以选择已经制作或自己定制的产品。默认情况下，我希望使用以前的UI。今天看起来很奇怪！
编辑：现在在移动设备中显示的文本类似于台式机中的文本。我的意思是，在移动设备中，颜色有点偏黄。我最讨厌这种变化。
评论
虽然这很好，但这是一项天文数字的工作。最好不要一时兴起就对基础基础架构进行样式更改。
– TylerH
20年8月27日在17:50
我认为，如果每次UI更改都必须有多个版本，那么现在情况将一团糟。
–帽子
20年8月28日在11:40
好吧，这个主意是关于主题的。我们中有些人会更喜欢上一个。谁不喜欢它，可以转到建议的实验标签，选择他/她最喜欢的标签。没有其他的。它只会改变外观。
–西弗勒斯·斯内普（Severus Snape）
20年8月28日在11:49
例如，维基百科就是这样做的。如果需要，您仍然可以使用原始主题。
–橙色狗
20年8月31日在16:43
#6 楼
引用@hkotsubo：很多人都说很难读。在您说完它之前，至少应该考虑一下
。
我完全同意。它不仅在笔记本电脑上，而且在移动设备上也更糟。尽管我不经常使用手机，但我使用它的次数足以使它成为问题。来自这个评论：
这不仅是针对认知障碍者的，他们比平时挣扎得多。每个人都是如此。在展示自己的内容时，不要攻击研究角度。我们已经讨论完了。
并非每个人都如此，反正也不适合我。
您得到的反馈似乎是负面的。请恢复为
1.3，如果它没有损坏，请不要修复它。如果可以说这两个职位，那么旧的方法会更好。我不会否认有例外，但是我们绝大多数人都说这不是一个好的改变。如果无法还原，或者根本无法还原，那么在用户首选项中添加选项似乎还是个好主意，不管是否辛苦。
UPDATE：
十六天自从Aaron Shekey发布此答案以来，现在已经过去了，并更新说
1.6的拟议行高已调整为1.5，此后我们一直未收到对我们许多问题的答复。 Stack Exchange是否会考虑恢复更改，或在用户首选项中添加选项？还是这种变化会持久，就像关于块引用的变化一样？足智多谋的@Prid进行了另一个扩展来还原所做的更改。扩展，用户脚本和其他各种“创可贴”都很好，但是使大量的人使用多个第三方资源来还原这些内容。 Stack Exchange做出的各种糟糕的设计选择都不是很好。
我还想知道为什么较大的行高被认为是有利的，为什么没有执行用户测试（如果有，我们还没有听说过）？行高
1.5可能对某些人有用，但对所有人而言并非如此。引用@ResistanceIsFutile，“为可访问性提供服务是指为所有人提供服务，而不仅仅是为某些人提供服务。” 我不认为让我们控制行间距或引用背景颜色之类的简单操作很重要问。
评论
不回应或不响应所说的反馈就等于不听。他们是否会在帖子中声明他们听到了我们的反馈，但相信他们的决定会更好地为社区做出任何改变？他们已经说明了做出更改的理由，但我看不出他们在不进行进一步更改的情况下如何做出回应将对任何人都富有成效。
–user400654
20-09-22在19:26
我的意思是，您再次假设他们不知道他们的社区中有一部分人不喜欢这种变化。将其作为一种选择有其自身的问题，例如有效地增加所需的测试量以确保更改不会破坏事情。
–user400654
20-09-23在14:42
从“他们不知道”，“他们不听”或“他们无视我们”的立场开始，几乎没有任何反应。您不是来自愿意听的人，那么他们为什么要回应？他们已经清楚地提出了自己的推理，他们对最初的变更进行了修改，以使其至少比开始时更好，为什么不直接解决其推理，而不仅仅是声称自己的社区失败了？
–user400654
20/09/23在14:46
#7 楼
是的我同意。请把线高恢复到1.3！仅将1.5调整为不够。仍然很难阅读这些行，恕我直言。
#8 楼
Prid说新的行高使其很难在精神上分隔段落。
我想补充一点，新的间距使连接起来非常困难甚至是同一句话，当我尝试从一行移到下一行时。
这是如此令人不安，这是我以前从未经历过的事情，但是由于失去了主题，我不得不放弃一半的段落说的话。我回去几次尝试重新阅读，但似乎要付出更多的努力。
作为一个自55年前从婴儿学校就读以来从未遇到过阅读困难的人，我觉得这特别奇怪。
如果是某种医疗状况，这是我从未见过的。
这是指向BBC新闻网站页面的链接，该页面具有相似的宽间距，但使用更大，稍微更粗体的字体。我对此没有同样的困难。我不知道在技术上有什么区别，也没有任何线索如何查找其使用的行距或字体。精通或至少熟悉这种类型的工作，我们在Stack Exchange上的其余人员只是“用户”。]
这里的mod /开发人员似乎坚称“研究显示出更大的思路”更好”。
从经验上讲，这似乎并不适用于所有人。
似乎有人读了一篇研究论文，而我们其他人必须承受后果。
另一个因素我想到的是Windows和Mac用户看到的东西截然不同。 Ask Different以前使用的是Mac专用的字体，读起来很漂亮-不幸的是，它几年前就被删除了，这给了我们SE现在在全球范围内使用的较差的选择。
我上一段的屏幕快照首先是Mac Safari
，然后在Windows Microsoft Edge上
单击以达到“实际大小”以更好地进行比较。
因此，以我个人的观点，Windows在Mac上看起来并不那么糟糕。字体大小和间距之间的平衡要好一些。
这使我认为它只在一个平台上进行过检查。
#9 楼
我想引起读者注意，W3C实际上并不建议将行高设置为1.5或更高。相关的建议似乎是WCAG标准1.4.12（文本间距）和1.4.8（可视化）。演示文稿）。
关于文本间距读取的准则1.4.12（强调我的观点）：
在使用支持以下文本样式属性的标记语言实现的内容中，不会因内容丢失或功能丢失设置以下所有内容，并且不更改其他样式属性：
行高（行距）至少为字体大小的1.5倍；
（等）
因此，这不是行高设置的要求或建议-这是一项要求，如果将行设置为更宽的间隔，则网站/网页不会变得无法使用或无法正常运行，
W3C文档“理解成功标准1.4.12：文本间距”重申了这一点（强调分钟e）：
此成功标准（SC）的目的是确保人们可以覆盖作者指定的文本间距以改善他们的阅读体验。
建议是为了支持覆盖设置以满足某些读者的需要-请勿更改默认设置。
关于可视表示的WCAG标准1.4.8如下：
对于文本块的可视表示，可以使用一种机制来实现以下目的：（AAA级）
... snip ...
段落中的行距（行距）至少为半个空格，并且段落间距为至少比行距大1.5倍。
因此，不是默认值，而是通过某种机制的可实现性。
@MaxD链接到有关标准1.4.8的“技术”文档提供1.5到2之间的行距很重要，但是：
该文档不是官方的WCAG。
“提供”并不意味着“将其设置为默认值”。实际的WCAG澄清了此意图是提供进行该设置的机制。例如，为此目的在站点级别的每用户设置。
标准1.4.8考虑AAA级别的一致性。该级别并非旨在（根据WCAG文件本身）用于一般用途，而是用于更多可访问性专门的站点。
由于披露：我也将此内容发布为对此相关讨论的答复。
评论
另一方面，在这里：“许多认知障碍者在一块文本被等距排列时，很难跟踪文本行。提供1.5到2之间的间距可以使他们在完成前一行后更容易地开始新的一行。”
–MaxD
20年9月4日在21:01
@MaxD：请参见编辑。
– einpoklum
20/09/04在21:28
我在解释所有这些复杂的措词时遇到了一些麻烦。也许是因为我既不是母语人士，也没有太多的网页设计背景。因此，您是说1.5-2建议仅针对明确针对特殊需求用户的网站？ SE员工只是在没有正确理解其预期含义的情况下复制了该号码？
–MaxD
20 Sep 5'0:41
@MaxD：这实际上有点令人困惑，因为1.4.8是AAA级，而1.4.12（具有大致相同的建议）是AA级。但是他们都没有说默认情况下每个站点的间距应该为1.5-2倍。假设存在某种机制以实现更大的间距。
– einpoklum
20年9月5日在16:34
嗯如果W3C的建议是基于研究结果（？）而得出的结果低于1.5，那么我很好奇为什么我们先达到1.6，然后又回到1.5。
–奥利
20年9月7日在20:59
@Ollie：但是SE上发生的事情无论如何都不是W3C的推荐，因此，特别地，它也不是基础研究的推荐。
– einpoklum
20 Sep 7 '21：27
#10 楼
我将原来的1.3线高和建议的1.6线高之间的差异进行了划分。我们现在位于1.5，对元素之间的间距进行了进一步的改进。我还将代码块内的行高降低到原始值附近。更新
我花了比我想要的更长的时间，但是我对我们的
s-prose组件进行了一些更新。您可以在我们的设计系统的存储库中通过我的思考看到拉动请求。它执行以下操作：将
s-prose标头从段落中展开以更好地分组。收紧
s-prose段落之间的间距，并确保标题下的间距更一致。用CSS变量
s-prose替换组件内部的所有var(--s-prose-spacing)边距，以便我们的用户可以更轻松地在浏览器和用户脚本中对其进行修改。您可以在我们的Stacks文档中看到一些内容示例。评论
为什么不简单地回滚到原始位置（或将其作为用户首选项的一个选项，以便每个人都选择他们想要的东西）？我认为1.5仍然太多了，特别是-但不仅限于-移动版
– hkotsubo
20年8月27日在21:03
@Aaron，最好现在将其更改回1.3甚至1.2。
–user1271772
20年8月27日在21:11
数十年来，心理学家一直在研究文本表示方法对理解和速度的影响，W3C所提供的信息就是基于该研究。大量研究反复得出结论，来自周围文本行的信息可能会干扰阅读速度和效率，这表明文本行之间的额外间距非常有价值。这甚至不仅仅适用于认知障碍者，他们比平时挣扎得多。每个人都是如此。在展示自己的内容时，不要攻击研究角度。我们已经讨论完了。
– animuson♦
20/08/27在21:42
许多人说这很难读。在说完它之前，您至少应该考虑到这一点。
– hkotsubo
20年8月27日在22:39
@hkotsubo我们正在听取有关此问题的反馈。我们不是在听那些只是在说“研究是胡说八道”的人，因为这对这里的任何讨论都没有建设性。 （这样做的评论已在此处删除，但我的评论仍然是为了阻止人们继续抨击研究，而不是提出建设性意见。）
– animuson♦
20年8月27日在22:56
您可以将@animuson链接到支持研究吗？我想阅读什么样的阅读材料，什么字体大小，段落尺寸范围，阅读持续时间以及中间插入的内容（例如代码，引号，插图），这些都是他们的推荐依据。如果是w3.org/TR/WCAG20-TECHS/C21.html，那么我发现很有趣的是，当初始使用的值较大时，在页面上说1.5，但这可能是一个不同的“ w3c”。
–user1306322
20/08/27在23:53
无论有什么研究说什么或没有说什么，最终都是用户在阅读此网站。如果150多个用户说某项更改使阅读更难，而0则说它使阅读更容易，那么他们可能有一点意思吗？而且这种改变可能不是一个好习惯吗？并且应该恢复原状吗？
–MaxD
20年8月28日在1:20
@MaxD就像你知道的那样，我见过很多人说他们更喜欢这种改变（即使不喜欢这种改变的人在这里似乎居多），所以0绝对是个夸张。
–胭脂红
20-8-28 at 3:31
@animuson我不想反对研究。但是，如果有很多人告诉您此更改对他们不利，那么它肯定会带来一定的影响。读取旧设置没有问题，但是读取新设置确实有问题。这对代码尤其有害。一小部分文字在新旧设置下都可以阅读，但快速阅读大文章确实给我带来麻烦。这对于浏览审阅队列以及快速浏览答案并找到问题的解决方案都是有害的。现在，所有这些将需要比以前更多的时间。
–抵抗是徒劳的
20年8月28日在8:22
@MaxD感到不开心的人更有可能（大声地）发表意见，然后是对某事感到满意的人。因此，我认为这在某种程度上是有缺陷的论点。我个人认为注释部分更容易阅读，然后是文章正文，并猜测注释部分设置的行高;）。而且，旧习惯很难改掉。
–Luuklag
20年8月28日在10:15
令我惊讶的是，还没有人指出“分裂差异”将是1.45，而不是1.5。
–史蒂夫·贝内特（Steve Bennett）
20-08-29在10:39
@animuson看，这种变化显然是基于W3C的建议，而不是基于数十年的研究。 W3C试图提供一种适合所有人的建议，这可能不是Stack Exchange的正确解决方案。研究比这更细微。我很想看看研究特别是在技术写作的背景下对可读性的看法。说到研究，在整个站点范围内部署此更改之前是否进行了任何用户测试？
–伊利亚·莫斯科维（Illya Moskvin）
20年8月30日在3:29
@animuson现在SE的论点仅仅是“因为W3C这么说”。只要SE并未真正引用特定的研究，我就不会感到惊讶的是，人们并不对“研究”深信不疑。您无法对从未见过的研究提出建设性的论据。
–疯狂科学家
20年8月30日在7:50
如果它能解释为什么更大的线高被认为是有利的，则可能会更好地得到该答案。似乎很多人都喜欢较小的价值更好，因此很好地解释为什么较大的价值实际上会更好的做法可能会大大有助于人们接受。
– Trilarion
20年9月1日上午10:50
@ user1306322我发现有趣的是，即使您链接到的W3C页面主张1.5到2.0行距，也使用1.4行距。
–杰夫
20年9月1日16:16
评论
在此也报告：新帖子格式。不幸地被标记为按设计状态。这是我的看法：要求为视力不好的人调整线间距。它可能会作为重复项关闭，但不仅仅是我不喜欢新格式。我再也看不懂代码了...
我撤消对它的手写笔@ChristianRau的评论。在代码块中确实存在更大的差距！不得不使用我的手机获取旧的缓存版本，但是您可以在旧版本中看到它。
@Larnu桌面上的另一个比较：meta.stackexchange.com/q/353536/289905#comment1181514_353536
更改为较大的行距间隔实际上使我的阅读速度降低了大约两倍。令人难以置信的设计选择。
不只是行高。其他情况也发生了变化。我总是格式化我的代码，以避免在代码块中出现水平滚动条。我注意到，如果一行上的字符数接近右边缘但仍然完全可见，它们现在就会出现。
@ user289905 status-bydesign与否，这是第一次。这可能是第一次更改（还原）。纠正我，如果我错了：D
@Ollie他们显然不在乎社区的意见，因此我怀疑它会改变任何事情。如果不添加任何新方面，也可能会被关闭。但是，如果您仍然坚持下去，我肯定会投票赞成;）
@Ollie我明白他们需要做出一些不适合所有人的决定，但是这种特殊的改变似乎让很多人感到不安。他们确实将代码框中的行高设置回了原来的水平，所以至少他们确实听了一会儿。能够在几种预设模式之间进行选择的功能请求可能会在欺骗投票中幸免。这不是要求完全颠倒，也不是我在功能请求中所要求的那种自由度，所以它介于两者之间。
这个问题是一个多月前提出的，但仍未得到解决...现在怎么办？
@Ollie安装脚本/附件，我认为SE设计师应该随自己的生活而前进。
@MaxD是的...我不认为SE的设计师很烂，只是决定在做...但他们是他们的决定。
@Ollie不是我们的底线，而是我们的行为定义了我们... :)
我以为我们已经确定，没有任何相关准则可以增加行距。为什么还没有恢复？
@einpoklum原因SE设计师。我会全力以赴再次提出这个问题，但是他们有机会，所以我高度怀疑它会改变任何事情，而且我也有我的用户脚本，因此我没有真正的动力去做。 >