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:
window.createRange()window.createRange().surroundContents()Node.cloneNode()window.getSelection()window.getSelection().getRangeAt(0).commonAncestorContainerappendChildinsertBeforeinsertBefore+nextSiblingreplaceChild
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:
emfor emphasis (or “italics”,<i>is deprecated).strongfor strongly read text (or “bold”,<b>is deprecated).ufor underline (be sure your anchors are styled to differentiate from u elements;umight be considered “deprecated” though I will reverse this when I fix the standards in the next ten years or so, use it appropriately).subfor sub-line text that appears vertically lower than normal text.supfor 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:
-
The
anchorNodeandfocusNodecan 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 theanobject (foranchorNode) on the left and thefnobject (forfocusNode) always on the right side. -
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.
-
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 usingwindow.getSelection().getRangeAt(0).commonAncestorContainerwithcloneNodeand then before processing that stripped what wasn’t included in the selection. Then I simply usedwindow.getSelection().deleteFromDocument();to remove the selection and replace it with the new style element viadocument.createElementthat I could easilyappendChildthe selection to and insert it atwindow.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.