Behavior of insert* commands for contenteditable=plaintext-only

[zcorpan]

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]

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]

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]

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

[yisibl]

I've noticed that Chrome and Firefox behave differently with carriage returns(Enter key); Firefox inserts <br>, while Chrome does not.

Imagine if this feature is used in code highlighting scenarios, where users usually don't want the extra <br>.

This would seriously affect interoperability, and I think it's something that needs to be standardized in the specification as soon as possible.

[zcorpan]

@yisibl that seems to be because Chromium forces white-space: pre-wrap computed value for some specified values of white-space. WebKit and Gecko don't.

https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13730

@kojiishi do you know why this happens in Chromium?

[kojiishi]

I've noticed that Chrome and Firefox behave differently with carriage returns(Enter key); Firefox inserts
, while Chrome does not.

I haven't looked into the code, but at a glance, the Chrome behavior looks more natural to me because <br> isn't plaintext, no? Is the more detail of plaintext-only than the contenteditable content attribute defined somewhere?

/cc @tkent-google

[tkent-google]

Yeah, we assumed web developers didn't want <br>s in plaintext editing, and disallowed white-space: normal and white-space: nowrap. If many web developers want <br>, it would be acceptable to change Chrome's behavior.

[zcorpan]

OK, though forcing computed style is "magic". Maybe it's enough to have a normal UA style rule?

[contenteditable="plaintext-only" i] { white-space: pre-wrap; }

If developers set it back to normal then they get <br>s.

@rniwa any opinions?