Clarify whether `dataTransfer` may have `text/html` when pasting rich text into `contenteditable=plaintext-only`

[masayuki-nakano]

According to Input Events Level 2, beforeinput of insertFromPaste should have data as null and dataTransfer when contenteditable. However, it's unclear that whether the dataTransfer should or should not have text/html when the user pasts into contenteditable=plaintext-only.

From point of view of web apps, if dataTransfer has text/html as same as contenteditable=true, they can serialize the HTML to plaintext by themselves to avoid dependency of browser/OS.

On the other hand, inputType does not have insertFromPaste for "Paste without format" (Ctrl + V on Firefox/Chrome for Windows). Therefore, web apps cannot distinguish whether the user pasting with or without format.

Perhaps, there should be new inputType value and dataTransfer may have text/html data even when pasting without format.

[masayuki-nakano]

On the other hand, inputType does not have insertFromPaste for "Paste without format" (Ctrl + V on Firefox/Chrome for Windows). Therefore, web apps cannot distinguish whether the user pasting with or without format.

I meant in the case of contenteditable=true. E.g., Ctrl-V vs. Ctrl-Shift-V.

[smaug----]

On linux/Firefox when pasting with ctrl+shift+v I seem to get only plain/text, not text/html
https://mozilla.pettay.fi/moztests/paste_contenteditable.html

And Chrome doesn't seem to get access to .dataTransfer ever when inputType is insertFromPaste.

[johanneswilm]

From TPAC 2024 minutes:

w3c/input-events#162

Sanket: Sounds fine to give access to HTMl when pasting even in plaintext.

Dan: How about input?

Johannes: We prefixed all the types of inputTypes to make it possible for an old editor to handle new input types with the same prefix.

Sanket/Ryosuke: We could add another attribute that would not cause the same web compat issues.
https://w3c.github.io/uievents/#idl-inputeventinit

Dan: Another option is to only deliver plaintext.

Dan: If we can do whatever, we can add new input type. But webcompat is an issue.

Johannes: second best is attribute. Where could that live.

Sanket: we could put it into the init where isComposing lives.

Olli: Maybe put it in the data transfer?

(Olli: what is the order in DataTransferItemList? Could ctrl+shift+v put text/plain first?
https://mozilla.pettay.fi/moztests/paste_contenteditable.html Firefox gives only text/plain when doing ctrl+shift+v. text/html is there without ‘shift’. Chrome doesn’t have .dataTransfer with insertFromPaste ? Tested on linux. The test is about normal contenteditable, not plaintext-only)

[zcorpan]

This was discussed in the December meeting. @smaug---- asked what the behavior is in Blink

https://lists.w3.org/Archives/Public/public-editing-tf/2024Dec/0000.html

[dandclark]

Notes from January meeting:

08:19 next issue: https://github.com/w3c/input-events/issues/162
08:21 johanneswilm: any updates?
08:22 johanneswilm: let's put an action item to move this forward
08:23 zcorpan: context — cE plaintext-only, paste/drop some rich text. what gets exposed on the DT?
08:24 johanneswilm: question for Blink is — is Blink following the spec? if not, why not?
08:24 dandclark: this is for drag/drop not plaintext paste?
08:25 johanneswilm: this is for paste and drop into plain text areas
08:25 dandclark: I'll see if I can figure out our current behavior and untangle the history