Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
zcorpan opened this issue Mar 10, 2023 · 3 comments
Open

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

zcorpan opened this issue Mar 10, 2023 · 3 comments

Comments

@zcorpan
Copy link
Member

zcorpan commented Mar 10, 2023

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
Copy link
Member Author

zcorpan commented Jun 22, 2023

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
Copy link
Collaborator

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
Copy link

kojiishi commented Jun 23, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants