为什么SO的HTML结构会破坏浏览器“阅读模式”？

Question

背景

浏览器的“阅读模式”可以根据用户的需求（间距、对比度、字体等）重新格式化网页，使其更易于访问和阅读。

虽然每个浏览器实现的阅读模式都不同，但通常它们都能很好地处理文章风格的站点，如Medium、纽约时报、Lifehacker等。

问题/疑问

但是在StackOverflow上，阅读模式几乎都以不同的方式出现问题，通常只显示问题或第一个答案；其他内容则被省略了。

具体来说，SO/SE页面的HTML结构有什么问题会导致浏览器阅读模式出错？

换句话说，如何更改页面的HTML结构才能使浏览器阅读模式正确解析和显示所有的问题/答案内容？

进展情况

通过比较各种不同的浏览器（移动和桌面），似乎阅读模式使用了一些简单的启发式方法来确定要显示哪些内容，例如“仅显示具有最多文本的元素，并隐藏所有其他内容。” 或者“仅显示具有最多文本的元素，但会加权考虑靠近页面顶部的元素。”

*_{到目前为止已尝试的浏览器（移动和桌面）：Firefox、Safari和Chrome（请注意，Chrome仅在移动设备上原生支持此功能，并将其称为“简化视图”）。在Firefox和Safari中，可以在URL栏中访问阅读模式；在Chrome中，如果支持，可以在屏幕底部访问。}

但也有可能是扫描元素标签/类/ID以寻找语义上的重要内容。

从浏览器开发工具中探索发现，似乎有两个包装器

包含所有的问题和答案内容，而每个问题和答案也各自有一个单独的

。这让我感到困惑，因为通常只显示第一个问题和第一个答案，而我期望只有其中之一，或者阅读器检测到包装器并显示所有内容。

尽管所有浏览器的实现方法都不同，但由于它们都可以处理文章风格的站点，去除非内容元素，因此我正在寻找一种调整SO/SE页面结构或语义的方法，以便类似地诱导浏览器阅读模式捕获所有内容。

可访问性

SE最近在所有SE/SO网站上扩大了行距，以促进辅助功能（例如，对于患有阅读障碍的读者）。我在这里提出的问题是我的meta帖子的技术姐妹问题，在那里我建议SE网站更好地支持阅读器视图。（请注意，我不是赞成或反对格式更改；我只是有兴趣通过阅读模式探索一种支持用户确定格式的方法。）我希望这个问题能作为那篇文章的技术调查推论，并产生一些可操作的信息，说明可以进行哪些修改来支持浏览器阅读器模式。

- ultraGentle

---

这应该发布在 meta SE 上吗？ - user8866053

我不这么认为：这是“从技术上讲，HTML的哪些方面导致了这种情况”，而我已经在元站点上发布了一个单独的帖子（链接在上面的问题中），它是“SE是否应该尝试支持阅读器视图”。它们是相关的，但这只是一个涉及到HTML / 浏览器的问题。 - ultraGentle

Stack Overflow是一个论坛。阅读模式在论坛中效果不佳。 - desbest

Answer 1

这是FireFox的阅读视图源代码, 我们可以使用它来猜测为什么Stack Overflow不能正常工作。我想其他阅读视图实现可能会使用类似的标准。

与Stack Overflow冲突的阅读视图标准

有一些标准使得Stack Overflow无法在阅读视图中正常工作。

它使用的标准旨在从页面中删除注释。

有一些标准，如文本长度（300+字符为最佳候选项）、逗号和类名，都是为了删除看起来像注释的节点。

由于阅读模式是设计用来阅读博客文章的，因此这显然是有利的，但在Stack Overflow上，这可能会将大量低分节点的页面部分移除作为候选项（我的意思是...谁会在评论中使用逗号呢？它们占用了你的字符计数！ 哈哈）。

阅读视图不使用语义作为指标

这让我感到惊讶，但它在做决策时不会查找语义元素，例如<main>，<article>等。

这对于Stack Overflow来说没有帮助，因为它们也不使用它们，但这是我立即想到的解决方法。

类名对于Stack Overflow没有帮助

然而，它确实查找指示项目可能与主题相关的类名。

负面类（我相信包括部分匹配，例如“评论”的“main-comments”）如下（这些可能会导致从可能的候选项列表中删除一个节点）：

unlikelyCandidates: /-ad-|ai2html|banner|breadcrumbs|combx|comment|community|cover-wrap|disqus|extra|footer|gdpr|header|legends|menu|related|remark|replies|rss|shoutbox|sidebar|skyscraper|social|sponsor|supplemental|ad-break|agegate|pagination|pager|popup|yom-remote/i,

在该列表中，有“comment”和“share”，因此每个评论都有一个类名为“comment”，所以评论部分的得分可能很低，实际答案部分也可能由于“share edit follow close flag”部分包含一个类名为“share”而得分较低。

Stack Overflow可以更改这些类名，这可能会提高完整页面在阅读器视图中呈现的机会，但这是一种hack方法，可能不太健壮！

评论和短回答是问题所在。我提到过，元素中的文本长度和逗号的使用是确定元素是否成为页面上“主要文本”的标准。

在Stack Overflow上，评论、短答案等总是与此评分机制冲突，因此这对于Stack Overflow来说是解决阅读器视图兼容性的一个重大问题。

考虑到这一点......

解决方案是什么？

就使网站与阅读器视图兼容而言，这不是您应该积极追求的事情，这将导致糟糕的决策。

试图调整Stack Overflow以满足阅读器视图的标准最多只会导致hack，并引入可访问性问题！这里的问题是问答网站在阅读器视图下表现不佳。尝试在Reader View上使用Quora，它也无法正常工作。

为了说明我对此的思考方式，原始问题可以更改为“FireFox应该如何使其阅读器视图与问答网站兼容”，然后就会开启关于他们用来确定要显示哪些内容的标准的讨论，因为问题在于他们的实现而不是Stack Overflow/Quora（当然，Stack Overflow/Quora等并不完美！）。

相反，我可以想到几个解决方案，可以实现我认为您正在使用阅读器视图进行的可访问性功能：

自己修复

由于所有这些都似乎源于行高度的更改，因此您可以创建一个插件或bookmarklet，以修复页面上的所有样式。

由于可读性源代码可用，因此您可以轻松调整源代码以考虑Stack Overflow特定的设计（给<div id="mainbar"增加额外的+200分权重，因为那是我们想要显示的容器）。

然后只需调整书签以指向具有修改过的可读性脚本的您自己的服务器，即可获得工作解决方案。

如果您决定这样做，请与社区分享，这可能会为您带来一些好的声誉，并且在简历/社交媒体配置文件等方面看起来很棒。

让Stack Overflow修复它！

更好的选择是要求Stack Overflow实施可访问性设置。Stack Overflow应该努力成为该领域的领导者，我相信对于可访问性功能的请求将得到良好的回应，并最终添加到开发路线图中。

请求添加一个可访问性设置屏幕或下拉菜单。一个很好的起点是像用户界面选项组件这样的东西。点击“+显示首选项”，您将看到可以在网站上调整许多内容。

这样，您可以修复行高（似乎这是最初的起点，因为您使用它来调整设计以适合自己的喜好）。他们还可以实现类似于阅读器视图（“专注模式”）的简化视图。

使用此方法的另一个好处是编辑器仍然可以使用，并且您可以查看易于阅读的格式的输出。

这似乎是最佳解决方案，在像SO这样的网站上，其复杂度位于技术限制/设计考虑的低端。

阅读器视图标准系统的最终反讽

在撰写本文时，如果您在FireFox中的阅读器视图模式下查看此页面，则会看到问题标题，然后将我的答案作为主体文本。您的整个问题正文将从页面中删除。我认为这完美地概括了问题！

- GrahamTheDev