execCommand() is now obsolete, what's the alternative?

Question

I intended to use Document.execCommand() method along with contenteditable attribute to build my custom WYSIWYG editor. But when I checked the documentation for Document.execCommand(), I found that it's now obsolete. What's the modern (or extant) alternative for it?

Answer 1

Year 2022–2024 answer: The execCommand() is officially obsolete/deprecated but there's no alternative. So if you must have rich text support, you have to keep using execCommand() and figure out yourself what actually works with browsers that you want to support.

Note that real world user agents (browsers such as Chrome, Firefox and Safari) cannot drop support for execCommand() because so many services require support for it. The sad state of things is that HTML5 cannot specify any common ground. This is because browser vendors do not agree how execCommand() should work. So nothing can be specified for HTML5, which has the overall objective to specify all stuff – and only stuff – that's needed for full interoperability for any new browser to enter market. However, in my opinion HTML5 fails here because execCommand() compatibility is actually required for any new browser to enter market. So it would make sense to standardize at least one of the browser specific implementations as the official one.

All the current standardization efforts (Input Events 2, Clipboard API) fail to even try to cover the features that execCommand() actually does (for example, undo/redo, actually changing content within the selection range).

The hardest parts to solve are the caret movement, selecting text, different IME (Input Method Editor) behavior and handling native clipboard. These all interact with each other in various ways depending on browser and operating system. For example, the behavior that iOS Safari has on iPad while writing Traditional Chinese is totally different from Firefox on Windows with Thai IME. Which is again totally different from Chrome running on Chromebook while writing Finnish or entering emoji characters with multiple UNICODE point encoding. And as none of the available JS APIs disclose all the details, you MUST use contenteditable and possibly execCommand(), too, for most browsers to get correct input from the IME.

Also note that e.g. Android GBoard needs to also know about the surrounding text within the same editable content because it uses AI logic to correctly figure out which word suggestions to give to the user while inputting text, so you cannot fake this with a single empty invisible textarea under the caret because that would be missing the required context. That hasn't prevented people from trying to do exactly that but it fails in practice in various ways.

This situation has already been going for over five years so don't expect any rapid changes either.

Answer 2

I created the Rich Editor for my platform's XML (HTML5 + XHTML) editing purposes. I would not say that document.execCommand() is completely dead because some parts of it still work fine. Unfortunately the primary issue for me was that browsers use a lot of different code to generate those styles which are not recognized by screen readers used by those who are blind or nearly so.

Additionally the most expensive time bug I ever had to conquer was a Gecko/Presto bug where the visual and technical selections (why they aren't the same thing, don't ask me) would result in part of the DOM being changed that the user did not intend and this would come down to the fact that the pixel count per character is low so if the Rich Editor did not honor visual selections a user would very quickly walk away. That required four months to conquer and there are other bugs too.

Ultimately it's a harsh though achievable endeavor though if you intend to build an HTML/XML editor like I did you should plan for at least six months if you plan to not only do it properly though test it to the point of hating cake to then only have someone come along and point out yet another bug.

Your primary focus JavaScript wise should be on the following:

• document.createRange()
• document.createRange().surroundContents()
• Node.cloneNode()
• window.getSelection()
• window.getSelection().getRangeAt(0).commonAncestorContainer
• appendChild
• insertBefore
• insertBefore + nextSibling
• replaceChild

In place of inconsistent code generated by using execCommand() from different browsers (often setting inline styling which would complicate your site's CSS if not outright negating it) you should stick to using the following elements which you not only can have control over though are compatible with screen readers:

• em for emphasis (or "italics", <i> is deprecated).
• strong for strongly read text (or "bold", <b> is deprecated).
• u for underline (be sure your anchors are styled to differentiate from u elements; u might be considered "deprecated" though I will reverse this when I fix the standards in the next ten years or so, use it appropriately).
• sub for sub-line text that appears vertically lower than normal text.
• sup for supper-line text that appears vertically higher than normal text.
• Do not use the <span> element to specifically add these styles as screen readers will not understand or reveal buggy behavior; it is still a valid generic inline element when used appropriately.

I actually have been intending to revise my Rich Editor (it's been getting patched though not yet properly rewritten) though you're welcome to look at the source code when it loads on a blog page in the site linked in my profile. The original project took me 11 months though with my experience now I think it would take me about three to four. If you're serious I highly recommend staying the hell away from frameworks and libraries. "But ... but, they make life easier!" ... until you want to use a new version and have to rewrite the entire project. Use pure JavaScript the first time and negate pointless maintenance. Good luck!

---

2021-09-24: I ended up resuming work on the Rich Editor II from roughly a year ago and managed to convert the code that changed styles from 100,515 characters to ~6,000 and reduce the file request (effective bandwidth after compression) by a full third. Here are the key parts to that success:

1. The anchorNode and focusNode can switch depending on if you select left-to-right or right-to-left. Because I couldn't find any justification of why that would matter (for my platform) I made the an object (for anchorNode) on the left and the fn object (for focusNode) always on the right side.

2. I resolved the Gecko/Presto issue using ~1,700 characters; you can find it on the site (visit a page that has a Rich form) first.

3. To resolve the issue of selecting through numerous interchanges by <s>, <sub>, <sup>, <u> etc (you must test both simple and wildly convoluted examples) I ended up using window.getSelection().getRangeAt(0).commonAncestorContainer with cloneNode and then before processing that stripped what wasn't included in the selection. Then I simply used window.getSelection().deleteFromDocument(); to remove the selection and replace it with the new style element via document.createElement that I could easily appendChild the selection to and insert it at window.getSelection().getRangeAt(0).insertNode(id_('editor_rich_text').firstChild);.

Gecko browsers such as Waterfox, Pale Moon and the now utterly destroyed Firefox allow you to select multiple instances of text. To do so simply hold the Control key to create extra selections. Since it doesn't really help in any meaningful way (and this stuff is already convoluted enough as it is) I didn't go out of my way to support it at this time.

I'll be updating my platform either today or this weekend (as of this post edit) to reflect the new changes. I am keeping a lot of the older code due to numerous issues with Gecko browsers. I have expanded upon the functionality and resolved numerous bugs and did not have to resort to any hacks and as usual no garage (frameworks or libraries).

---

2021-09-26: For those interested in redo/undo functionality you'll have to resort to basically keeping text versions of the part of the DOM that you're editing. Sure, there could be other ways to implement it though those would be wildly convoluted. You basically just make a copy of the editor parent element using .cloneNode and then while it's in memory use something along the lines of while (e.firstChild) {xml += new XMLSerializer().serializeToString(e.firstChild);}. Since you'll be storing it as text it won't have the huge memory implications that the DOM has. You will literally be replacing the entire DOM in the editor as well as tracking every iteration of a change so it'll still be a hefty project. For my platform it's not necessary right now though I wanted to cover this as some people have mentioned it in the comments.

Answer 3

You can use the following:

navigator.clipboard.writeText('text to be copied');

which does the exact same thing as document.execCommand("copy");

Answer 4

Looks like the alternative will be Input Events Level 2.

While it is very tempting to create a self-made WYSIWYG editor, I personally will stick with execCommand until the new standard arrives. Because we all will just program a whole editor by ourselves, instead of reusing present working solutions.

Answer 5

The alternative to document.execCommand() is Clipboard API, via navigator.clipboard. Per MDN Web Docs (https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API):

This API is designed to supersede accessing the clipboard using document.execCommand().

EDIT: As mentioned in the comment as well as the quoted text above, this only fulfills a subset of the requirements (clipboard access).

Answer 6

The conclusion here is that even though the w3C has a warning concerning execCommand(), it is still working and no standard alternative for it yet even now in 2022 unless one results in using javascript edition libraries.

Answer 7

The reference documentation says it as warning.

It is predicted that in the future both specs will be replaced by Content Editable and Input Events.

And as every prediction, just wait to be sure.

Answer 8

2024 Answer

The reality is that execCommand is not really deprecated in the traditional sense, but has rather been demoted to an unofficial draft. Note that the one-page WHATWG single page specification includes a specific note that all "User agents are encouraged to implement the features described in execCommand.". The reason it's marked as deprecated is because the alternative is to call it non-standard which isn't quite right either, especially when it's already being used on so many production sites.

The reason for the demotion is outlined in the draft itself and other comments here, but basically comes down to there currently being no good way to completely standardize several parts of it when so much is dependant on what users are used to on a specific platform (OS/locale/etc combination). Any reasonable replacement would likely suffer the same issues, so there's little point in waiting for one. The stance on this unofficial draft still being recommended was confirmed back in 2021.

Just know that execCommand is a way to ask the browser to do something for you without specifying how, which can have different results in different environments that you may or may not care about and have to account for. That means of course that some tasks are handled better, or at least in a more controlled manner, potentially more performantly and in a non-blocking way, by other APIs, but that's more a matter of using the right tool for what you're trying to accomplish rather than trying to avoid something that isn't going away any time soon.

Answer 9

Depends what you want to achieve

As per MDN.

The execCommand method implements multiple different commands. Some of them provide access to the clipboard, while others are for editing form inputs, contenteditable elements or entire documents (when switched to design mode).

To access the clipboard, the newer Clipboard API is recommended over execCommand(). However, there is no replacement for the editing commands: unlike direct DOM manipulation, modifications performed by execCommand() preserve the undo buffer (edit history).

Reference Here

Answer 10

It is possible to make a WYSIWYG editor using

window.getSelection()

but it is not a problem to keep on using execCommand for now.

Answer 11

There is nothing wrong with document.execCommand. The problem is that HTML 4 standard that is used under the hood of this function is not widely supported any more. For example, FontSize command uses <font> tag, which is deprecated. But there are also good news. First one is that document.execCommand will never be removed from javascript and second one - you can use insertHTML command which can insert any HTML you want.

function FontSize40px(){
   var spanString = `
   <span
      style="font-size: 40px;"
   >${ document.getSelection().toString()}
  </span>
   `
   
   document.execCommand('insertHTML', false, spanString);
}

It's just a stupid example :))