Clarify the nested case of contenteditable=true and contenteditable=plaintext-only

[masayuki-nakano]

There are 2 simple cases:

<div contenteditable="true">
  <div contenteditable="plaintext-only">plaintext-only</div>
</div>

<div contenteditable="plaintext-only">
  <div contenteditable="true">rich text allowed</div>
</div>

Perhaps, initial shipping of contenteditable=plaintext-only of Firefox may depend on the topmost editing host value (i.e., focused editing host) because there are complicated issues.

For example, in the following cases, it's unclear whether rich text or plaintext should be pasted.

<div contenteditable="true">
  [rich text
  <div contenteditable="plaintext-only">plaintext-only]</div>
</div>

<div contenteditable="true">
  <div contenteditable="plaintext-only">[plaintext-only</div>
  rich text]
</div>

It seems that Chrome considers it from anchor node of selection. So, if you make the above selections with opposite direction, you'll see different result.

[rniwa]

Filed https://bugs.webkit.org/show_bug.cgi?id=280419 to track this issue in WebKit.

[johanneswilm]

From TPAC 2024 Minutes:

#470
Johannes: What happens if contenteditable=true/plaintext are nested?

Dan: The outer one takes precedence. You can reset with contenteditable=false

Ryosuke: Same true for Webkit

Sanket: We should write this down in a spec. Current definition looks incomplete:
https://html.spec.whatwg.org/multipage/interaction.html#editing-host

Resolution: follow model of outermost wins. File issue with HTML spec (Olli takes responsibility).

Dan: In both examples below, they should be richtext.

Resolution: Bug will need to be filed with Chromium (Dan)/Webkit (Ryosuke).