w3c / editing

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

Behavior of insert* commands for contenteditable=plaintext-only #419

Open zcorpan opened 1 year ago

zcorpan commented 1 year ago

See https://bugzilla.mozilla.org/show_bug.cgi?id=1291467#c17 by @masayuki-nakano

I checked the behavior in Chrome roughly now, then, I see only the following commands work, so their definitions are required:

  • Handling steps of Document.execCommand("insertParagraph") (Chrome/Safari handle this command differently from pressing Enter)
  • Handling steps of Document.execCommand("insertLineBreak") (LF vs <br> (Chrome vs. Safari)
  • Handling steps of the commands when caret is in special elements such as <li>
  • Handling steps of Document.execCommand("insertText") (including line breaks causes insertParagraph in both, but I'm not sure it's intended since the behavior looks odd)
  • Handling steps of Document.execCommand("insertHTML") (especially which elements need to be handled as line breaks)

And the other commands (except undo, redo and clipboard commands) should be defined as NOOP (including not deleting Selection).

cc @howard-e

zcorpan commented 1 year ago

Handling steps of Document.execCommand("insertParagraph") (Chrome/Safari handle this command differently from pressing Enter)

https://software.hixie.ch/utilities/js/live-dom-viewer/saved/11814 (compare with contenteditable=true). Chrome and Safari insert a div and insert following sibling text to it (for both plaintext-only and true). Gecko (for contenteditable=true) results in two divs, one for x and one for z.

Handling steps of Document.execCommand("insertLineBreak") (LF vs <br> (Chrome vs. Safari)

LF seems more useful for plaintext-only.

masayuki-nakano commented 1 year ago

Handling steps of Document.execCommand("insertLineBreak") (LF vs <br> (Chrome vs. Safari)

LF seems more useful for plaintext-only.

Yeah, if linebreaks are not preserved like white-space: normal, should be <br>? (I guess yes.)

And I wonder, if contenteditable value is changed from ""/"plaintext-only" to the other value in a beforeinput event handler, how do Chrome/Safari handle it...? Especially when it's switched from "" to "plaintext-only" and the command is not acceptable for the plaintext-only, e.g., bold command which is available with Accel+B except in Firefox.

kojiishi commented 1 year ago

Blink uses ShouldUseBreakElement to determine whether to insert <br> or LF; so it checks both plaintextonly and white-space-collapse.