行高不影响 contenteditable 中的第一行

Question

考虑以下 HTML：

<div class="content" contenteditable="true">
rrr<br>
ttt
</div>

&CSS:

.content {
line-height: 35px;
}

你得到的是仅影响第二行及以下行的行高。令我困扰的是，插入符号的高度受行高的影响，因此第一行明显比第二行短。

使用这个 Fiddle 来查看它的实际效果。将插入符号放在第一行和第二行中，并观察每一行中的插入符号。注意它的高度因行高而不同。

我不能在主要的 contenteditable 元素中允许每一行都有内部包装。

当尝试使用 div::first-line 并在该 css 规则中使用 line-height 时，它不会影响它，尽管 background-color 等其他属性会影响它。

有没有办法也影响第一行？我更喜欢 css-only 解决方案，但如果别无选择，Js 也可以。

Answer 1

解决方法（这不会破坏下面评论中提到的预期行为）：

br {
  content: " ";
  visibility: hidden;
  display: block;
}

Answer 2

尽管其他答案中提到了什么，但 <br> 并不是真正的问题。实际问题在于 Chrome - 特别是它如何处理行高大于自身高度的文本。这个 Chrome 行高问题实际上是我们许多 CSS 的长期困扰。插入符号始终跨越整个行高，并且文本不在行高的垂直中间。更糟糕的是，他们对待第一行与其他行不同:(

<br> 上的建议是一种掩盖问题的技巧，但它仅在您要在文本区域中手动输入换行符时才有效。只是为了证明 br hack 方法不适用于具有自然出现的环绕文本的常规文本区域/可内容编辑区域：http://jsfiddle.net/8ao367gz/1/

坏消息：目前还没有真正的解决方案。普遍的共识是找到一种绕过您的设计的方法，不要将 line-height 设置为 normal 或 1 以外的任何值。如果你必须在设计中使用行高，要么接受在 Chrome 上跨越整个行高的奇怪的底部对齐插入符，要么告诉你的用户使用没有这个问题的其他浏览器（比如 Firefox） .或者我们都可以不断抱怨并向 Chrome 提交错误报告，并祈祷他们 "fix" 这样做。我非常怀疑，因为我认为他们不认为这是一个错误；即使他们这样做了，也可能是一个非常低的优先级。

行高不影响 contenteditable 中的第一行

Line height doesn't affect first line in contenteditable

css

contenteditable