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的解决方案，但如果没有选择，Js也会这样做。

Answer 1

尽管其他答案中提到了什么，但<br>并不是真正的问题。实际问题在于Chrome - 特别是它如何处理行高的文本大于其自身的高度。这个Chrome线高问题实际上是我们许多人做CSS的长期刺激源。插入符号总是跨越整个行高，文本不是行高的垂直中间。更糟糕的是，他们将第一行视为与其他其他行不同：（

<br>上的建议是掩盖问题的黑客攻击，但只有在文本区域中手动输入换行符时才有效。只是为了证明br hack方法不适用于具有自然发生的包装文本的常规textareas / contenteditable区域：http://jsfiddle.net/8ao367gz/1/

坏消息：目前还没有真正的解决方案。一般的共识是找到解决方案的方法，不要将line-height设置为normal或1以外的任何其他内容。如果你必须在设计中使用行高，要么使用奇怪的底部对齐的插入符号覆盖Chrome上的整个行高，要么告诉用户使用另一个没有此问题的浏览器（如Firefox）。或者我们都可以不断抱怨并向Chrome提交错误报告，并祈祷他们能够修复＆＃34;这个。我非常怀疑，因为我不认为他们认为这是一个错误;即使他们这样做，也可能是一个非常低优先级的人。

Answer 2

Walkaround（这不会打破下面评论中提到的预期行为）：

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

行高不会影响可疑的第一行

2 个答案: