RFC: Contenteditable "indent"/"outdent" implementations are not aligned with popular editors

[joanmarie]

Summary: When a line break is inserted within a block, popular editors treat the text after the line break as part of the same block for the purposes of indentation/quoting. No user agent implementation of the "indent" command is doing this. Should they be?

Web App Editors

Test Case

N.B. This is for editors that support Shift+Enter as a way to create a newline without creating a new block, and have an indent or quote feature.

1. Type "New block 1"
2. Press Shift+Enter
3. Type "New line in block 1"
4. Press Enter
5. Type "New block 2"
6. Move the caret in front of the "N" in "New block 1" (i.e. no text is selected)
7. Use the editor's indent or quote function

Results

• Google Docs indents "New block 1" and "New line in block 1"
• Microsoft 365 Word indents "New block 1" and "New line in block 1"
• Zoho Writer indents "New block 1" and "New line in block 1"
• iCloud Pages indents "New block 1" and "New line in block 1"
• Confluence Pages indents "New block 1" and "New line in block 1"
• Nuclino indents "New block 1" and "New line in block 1"
• Coda indents "New block 1" and "New line in block 1"
• Notion indents "New block 1" and "New line in block 1"
• WordPress indents "New block 1" and "New line in block 1"
• Medium indents "New block 1" and "New line in block 1" (Note: Medium's editor won't let you indent without selecting something, so select just the "N" of "New block 1" first.)

Content Editable In User Agents

Test Case

1. Load data:text/html,<div contenteditable="true"></div><button onclick="document.execCommand('indent', false);">indent</button>
2. Give the div focus and type "New block 1"
3. Press Shift+Enter
4. Type "New line in block 1"
5. Press Enter
6. Type "New block 2"
7. Move the caret in front of the "N" in "New block 1" (i.e. no text is selected)
8. Click the "indent" button

Results

• Chromium:
  • Prior to indent: <div contenteditable="true">New block 1<br>New line in block 1<div>New block 2</div></div>
  • Indent only indents "New block 1"
  • Note: I'm locally experimenting with Chromium's indent/outdent feature as part of some bug fixing. It should not be difficult to bring Chromium into alignment with the popular editors IF consensus is that it should be done.
• WebKit:
  • Prior to indent: <div contenteditable="true">New block 1<br>New line in block 1<div>New block 2</div></div>
  • Indent only indents "New block 1"
• Gecko:
  • Prior to indent: <div contenteditable="true">New block 1<br><div>New line in block 1</div><div>New block 2<br></div></div>
  • Indent only indents "New block 1"

Questions

• Would it be a good idea to bring the user agents into alignment with the popular editors?
• If so, should that be stated in a spec somewhere for interoperability?

[johanneswilm]

Would it be a good idea to bring the user agents into alignment with the popular editors?

I would be cautious.

Contenteditable/execCommand is seldom a good replacement for JS editors that may use contenteditable to move the selection and receive events, but don't depend on the default browser behavior for content changes. There are other and better technologies already shipping in browsers for this. Making small patches here and there to modernize the behavior of contenteditable will have the effect of luring some JavaScript developers into thinking they can create a working editor based on contenteditable and "just a few lines of code to work around bugs in implementations". A year or two working on their editor, they will realize that it takes a major team and many years effort to build an editor that is really water-tight. Better advice for them would be to try to do what some of the existing editor libraries are doing (have a separate model for the content, diffing dom nodes, etc. to match that behavior) - or to use one of those libraries and just configure them to behave in their custom way.

It sounds like browsers are already in alignment with oneanother. So time spent on this may just be time wasted on the part of browser makers. That being said, if browser developers have the time and can agree on implementing this, I don't see anything wrong with doing it either. It sounds though as if browsers currently behave similarly. It would not be an advantage if a change in just one of the browsers changes this to where there is no alignment any longer.

A spec where such behavior could be added would be the execCommand spec that @zcorpan is working on as the browser native behavior normally matches that of execCommand commands.

[johanneswilm]

TPAC 2023
RESOLUTION: Simon will conduct compat research and report back findings and we figure out next steps from there.

[joanmarie]

Sounds great. Thanks!!

As long as Simon is conducting research.... I just discovered something weird (IMHO) about user agent implementations of outdent with respect to list items:

If you create an (un)ordered list in editors (I tried Google Docs and Microsoft 365 Word), indent nests the list item(s) and outdent reverses that, as expected. BUT at no point does outdent cause a list item to stop being a list item.

In contrast, if you load: data:text/html,<div contenteditable="true"><ul><li>foo</li><li>bar</li><li>baz</li></ul></div><button onclick="document.execCommand('outdent', false);">outdent</button>, click on "bar", and then click on the "outdent" button, you wind up with two unordered lists separated by "bar."

I personally think this is another instance where making the implementations match popular editors makes sense.

EDIT/UPDATE: Issue #442 created for this aspect of the problem.

[joanmarie]

(Another thing for Simon's research that falls under this umbrella)

In popular editors, if you indent something and then immediately outdent it, the result is as if you made no changes. IMHO, that is the expected result, both for the popular editors and for native contenteditable elements.

If you try anything but the simplest of cases, especially in Chromium and WebKit, the result is ... Well, try it out yourself. 😀 You can make it more visually obvious by using multiple levels of divs with colored borders and some brs sprinkled throughout.

EDIT/UPDATE: Issue #443 created for this aspect of the problem.

[johanneswilm]

Hey, could you make separate issues for each of those points? @zcorpan What will the research exactly entail? Will you check whether changing the browser engine will break popular JavaScript editors? That would be the main problem if any of this code is changed.

[joanmarie]

Hey, could you make separate issues for each of those points?

Done. I was erring on the side of caution (Does this working group really want a bunch of issues all for a feature that authors seem to be discouraged from using?). But now that I know this is your preference, I will do so going forward. I'll try not to file too many more. 😉

[johanneswilm]

Hey, yes so to be clear: Simon will investigate some.And then that might end up in sone spec text and a bug report for various browsers. But then there is no guarantee that the bug report will be acted upon. Contenteditable bug reports can at times sit around for 15+ years without anything happening as it's mostly a legacy feature.

…

On Thu, Sep 21, 2023, 14:40 joanmarie ***@***.***> wrote: Hey, could you make separate issues for each of those points? Done. I was erring on the side of caution (Does this working group really want a bunch of issues all for a feature that authors seem to be discouraged from using?). But now that I know this is your preference, I will do so going forward. I'll try not to file too many more. 😉 — Reply to this email directly, view it on GitHub <#437 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAERMOC6FLRN2LS4XSYX53LX3QYVJANCNFSM6AAAAAA4HOREMU> . You are receiving this because you commented.Message ID: ***@***.***>

[zcorpan]

@johanneswilm

What will thr research exactly entail? Will you check whether changing the browser engine will break popular JavaScript editors? That would be the main problem if any of this code is changed.

Yes.

Is there a good list of editors I should check? I've found https://github.com/JefMari/awesome-wysiwyg-editors but maybe it's missing some important editors.

(BTW, my alias is @zcorpan, @simon is someone else.)

[johanneswilm]

@zcorpan: Sounds good. Sorry, I answered by email and didn't know the user tag would go through. That list looks relatively complete. Some editors are there multiple times as some are frameworks that other editors are based on (fx Tiptap is using the Prosemirror framework). Missing are editors for specific web systems (fx Gutenberg for Wordpress) and special usage editors like CodeMirror or MathLive that also may contain some contenteditable. I can try to compile a more complete list next week some time.

[johanneswilm]

@zcorpan Sorry, I noticed I never answered here. That list of contenteditable editors looks fine. Some of the editors have not been updated for a long time (fx Substance - 4 years ago).