search

w3c / editing

Specs and explainers maintained by the editing task force
http://w3c.github.io/editing/
Other
193 stars 40 forks source link

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

Open masayuki-nakano opened 2 months ago

masayuki-nakano commented 2 months ago

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 commented 2 months ago

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

johanneswilm commented 1 month ago

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).