避免在 Chrome 换行之前在尾随空格下划线

Question

以下代码段在 Firefox 59 中正确呈现（假设）而没有尾随空格下划线，但在 Chromium 65 中，在显式换行符之前呈现行尾的虚假空格：

<div style="width:100px">
  <a href="#">This is long link, <br />with a line break</a>
</div>

Chromium 65 的截图：

来自 Firefox 59 的截图：

这种情况的明显解决方法是删除换行符前面的空格，但这是不自然的。

是不是其中之一的渲染错了？是由 HTML 或 CSS 规范指定的行为还是真的未定义？

编辑 1：在 IE 中也可以观察到与 Firefox 中相同的行为，所以看起来 Chromium 是唯一的。

Answer 1

问题不在于 Chrome 在尾随空格下划线，而 Firefox 则没有。问题是 Chrome 在换行时没有删除尾随空格（当换行源自硬<br />换行时）。空格带有下划线是因为它在那里，这与 Chrome 在自动换行文本时处理尾随空格的方式不一致。

处理包装文本状态的尾随空格的 CSS 规范：

4.1.3. 第二阶段：修剪和定位

随着每一行的布局，

1. 行首的一系列可折叠空格被删除。
2. 如果选项卡大小为零，则不呈现选项卡。否则，每个制表符将呈现为水平移位，将下一个字形的起始边缘与下一个制表位对齐。制表位出现在距离块的起始内容边缘是制表符大小倍数的点上。标签大小由 tab-size 属性给出。
3. 行尾的一系列可折叠空格被删除。
4. 如果行尾的空格或制表符不可折叠但将空格设置为预换行，则 UA 必须挂起空格或在视觉上折叠任何溢出空格的字符前进宽度，以便它们不会占用行中的空间。然而，如果overflow-wrap 设置为break-spaces，则不允许折叠它们的前进宽度，因为这会阻止保留的空格换行。

CSS 工作组在他们的 github repo 上讨论了尾随空格的不一致处理，特别提到 Firefox 对尾随空格的处理是最理想的：

最后还有一点，尾随空格看起来很糟糕，并且在内联的结束标记内或 a 之前有一个空格<br>是一种相当常见的无意标记模式，不应该对渲染产生不良影响。保留的尾随空间在设置内联样式时变得明显，如@palemieux 给出的示例，以及当我们选择除 start 之外的文本对齐方式时。这给出了一个真实世界的用例，表明对 Firefox 行为的偏好。

从这个讨论中，前面提到的CSS 规范已经更新（在 github 存储库中，但尚未明显发布）以匹配 Firefox (Gecko) 行为。将上面的第 1 点和第 3 点具体更新为：

一行开头的一系列可折叠空格（忽略任何中间的内联框边界）被删除。

一行末尾的一系列可折叠空格（忽略任何中间的内联框边界）被删除。

强调我添加的更改。