I am not a great fan of AI research, but it told me a few things recently that are interesting with regard to the 2026 Rich Text Editor.

I was worried about the life span of the old Javascript execCommand in the Editor that you are currently using, because it has been officially "deprecated". AI (Google) assures me that there is no danger of it failing within the forseeable future, since if support for it was totally withdrawn (i.e. the producers actually knocked it on the head), half the websites in the world would stop working. They wouldn't take that risk. Hopefully, these are not "famous last words"!

What you see below is a new editor (with similar appearance to the 2025 Editor) that nearly saw the light of day. It enables the user to do the keyboard editing and to make the text rich at the same time, in other words, it corrects the limitations of the 2025 version.

Then the trouble started. When introducing the final elements for the editing, such as copying/pasting text and so on, it was like trying to build a house, not on sand, but on quicksand. What worked fine one minute would do something completely crazy the next, with no obvious explanation. The behaviour of the app became totally unpredictable, with no apparent cause that was consistent.

Finally, I ran out of patience and abandoned the project.

So now you know. If you use the contenteditable attribute in your scripts, be prepared! The trouble is this.

When we are using highly trusted production tools, and we have a difficulty and our coding doesn't work, the normal thing is to assume that the fault is ours. And if we don't see it straight away, we just have to persist until we discover what we are doing wrong. Of course, it is understandable that the HTML producers don't exactly advertise the fact that one of their products is buggy, but in my opinion, that doesn't make it forgivable. Here's why. It may not be their intention, but the effect on the programmer is one of GASLIGHTING.

And being gaslit can be extremely unsettling, if not psychologically painful or damaging. If HTML was generally full of bugs, this would not happen, since it would be half expected. But it isn't. Perhaps they exist, but I have never found a single bug in HTML before. The 'contenteditable' attribute has been around for a very long time, certainly long enough for it to be repaired, or withdrawn and replaced.

That. then, is the story behind the WP3 Rich Text Editor for 2026, a nice idea that died on the beach. But certainly, the updated original editor is "good enough" for some time to come, and personally (although I am biased), I quite enjoy using it, and I hope you have the same experience.

JQuery handles XML just as well as HTML, and I was excited because it simplified the programming quite considerably, as I envisaged. With the exception of copying and pasting text etc., pure XML worked great, but I did have to introduce some DIVs because it was the only way to justify the text if necessary, i.e. aligning words on the left or right, or in the centre. No problem with that though.

I was able to produce it quite quickly, because I could re-use a lot of the coding I had already developed in the previous version for setting and reporting CSS etc.

I was fully aware of the exodus of programmers to the use of virtual DOMs and additional Javascript frameworks for the production of rich text editors. I understood this to be because of the difficulty of using the native HTML/Javascript DOM, and the fact that the essential execCommand had been officially deprecated, with no satisfactory alternative being offered.

But there was the confimation of one important detail that I missed, or perhaps did not want to believe, even though the evidence was before my eyes and in my skin. Google's AI told me clearly that:

"HTML's 'contenteditable' IS NOTORIOUSLY BUGGY!"