Re: [w3c/editing] Removal of browser built-in Undo stack functionality from contenteditable (#150)

> Just for kicks, I tried adding a table in TinyMCE (using the built-in feature, I didn't even have to paste anything), and after 30 seconds, I already ran into an issue where I had an empty paragraph above the table that was *undeletable*.
So I ask you, in the interest of everyone concerned, to revise your rosy picture of JS editors.


Could you give reproduceable steps as to how to get to that state?

As every other JavaScript developer, I do not personally use all the professional JavaScript editors out there. But in order for me to really be able to represent the views of JavaScript editors in general, I do not just focus on the editing framework I use myself at this moment.

For that reason also, I am not an expert on every possible bug in every software out there.

Of course there are also bugs in all of the editing frameworks out there, just as there are bugs in all known software, and if you found a new one I encourage you to file a bug about it.  But that doesn't put all editors on an equal footing. If you found a bug in a JavaScript framework with an active team behind it, there is someone you can report bugs to with a real interest in getting them fixed.

On the other hand, if you file a bug on the browsers relating to contenteditable, there is a good chance they will not be touched for a decade or longer. I say that as someone who has filed bugs against browsers years ago who would very much like for browsers to get that interest, and who has been traveling to W3C editing taskforce meetings on different continents for several years to try to get more interest in browser makers in editing to at least fix those bugs that JavaScript frameworks cannot work around. But I also understand that their priorities are elsewhere. So the best I think we can hope for is access to those primitives that JS frameworks need to provide editors that are on par with native apps. Then, maybe another 15-30 years down the line when the frameworks really have evolved a lot and do not change that much any more, maybe we see one that is really dominating the field and is close to bug free, and then that can be turned into a web standard of its own and translated to C++ to be bundled with all the browsers.

> Even if execCommand was really bad, and external JS editors really good, the whole idea of dropping native rich text editing from W3C specs and instead forcing everyone to rely on third-party libraries goes against the general philosophy of including more and more useful stuff in the browser.

That's actually not the ruling philosophy by browser makers as of today in my experience. They have actually removed several ambitions efforts that were to enter the browsers (such as MathML or CSS Regions) and have delegated the responsibility for this to JavaScript libraries (and going forward likely wasm in some cases). And it's actually oftentimes difficult to argue why contenteditable should be worth their time at all, given the relatively low percentage of pages that contain contenteditable.  Have you seen the [extensible web manifesto](https://github.com/extensibleweb/manifesto)? It's the access to primitives that that is advocating that we have been working on here over the past few years. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/150#issuecomment-560541678