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

> > Out of curiosity, I just tried to grab a table cell with an email address from a webpage, and paste it into TinyMCE. It created a table, just like contenteditable.
> 
> Sure, if your editor has tables whitelisted and grab enough of a table it will paste a table. The difference to your editor is that it can then guarantee that it can handle that table correctly and the user will not her/himself in a situation where a pasted table somehow breaks the rest of the editing experience.

Your optimism is endearing. I, on the other hand, have near-zero expectation that TinyMCE (or any other JS editor) will handle any table I paste into it without weird editing behavior. Not even Word, after decades of development, handles tables 100% correctly. 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.

> It's first when they have real users in production mode and they actually rely on the thing not messing up your formatting or eat user content that they notice it makes a difference.

Every rich text editor I've used has some quirks. For example, in TinyMCE, when you press Backspace here: `text <a href="ddd">e</a>|`, the result will be `text|` (why did it "eat" the space after "text"?). And the markup it generates is much uglier than contenteditable (perhaps it is customizable, I haven't checked). Tons of housekeeping attributes on elements, dummy `<br>` elements...

Generally, based on my 30+ years of experience using various text editors, I do not expect them to behave predictably during certain operations, such as deleting the last character of a link (will it preserve the link formatting despite the fact that no characters are left?) or whether the caret is (in the "mind" of the editor) inside or outside some formatted block. I simply avoid those "borderline" operations if I can, and when I have to do them, I brace myself for the pain of having to redo some small part of my work because the editor just won't let me do the exact selection I need. I suspect other users have similar "coping" mechanisms. Furthermore, nobody with any experience expects MS Word to behave the same as Thunderbird or GMail or TinyMCE. That's just the reality we live in. The fact that execCommand has its own quirks is hardly a deal-breaker.

> I defer to this very nice blog post from Piotr (CKEditor): https://ckeditor.com/blog/ContentEditable-The-Good-the-Bad-and-the-Ugly/ There are more links in there.

First off, thank you for the link. I spent over an hour carefully reading Piotr Koszuliński's blog post, as well as several related resources that I found thanks to it, e.g. [Fixing Contenteditable](https://medium.com/content-uneditable/fixing-contenteditable-1a9a5073c35d), [Why ContentEditable is Terrible](https://medium.engineering/why-contenteditable-is-terrible-122d8a40e480) and [this public-webapps post from Piotr](https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0575.html). That last post actually has a more comprehensive list of problems with contentEditable than the blog post.

The picture I get is the following:

- There are a lot of complaints about the fact that contenteditable generates "ugly" markup and that you cannot control whether you get `<b>` or `<strong>`, etc. Let me play devil's advocate here and ask, **why should you care about the underlying markup**? When you write a document in Word, the editor has some internal representation of the text. Do you worry about whether this internal representation is pretty? OK, the markup may matter in some interop scenarios, or when you want to allow the user to edit the HTML source (although mixing manual edits with WYSIWYG has never worked well), but what percent of usage is that? 
- Another set of frequently mentioned issues concerns poor handling of editing operations on "advanced" elements like tables, images. These are complex things and I would support removing them from contentEditable altogether (for example, by enforcing a restricted set of markup, as I described in my `<textarea type=rich>` idea).

Other than these, I don't see any huge problems with contentEditable. Some of the issues PK writes about have actually been fixed since the time of writing. For example, 2 out of [these 4 issues](https://bugs.chromium.org/p/chromium/issues/detail?id=226941) (related to backspace handling) no longer exist. I am not saying it works perfectly. For example, I have discovered that when you press Backspace here: `text| <a href="ddd">eee</a>`, the result will be `tex&nbsp;<a href="ddd">eee</a>` (where did the nbsp come from?).

To sum up my current thinking on the issue:
- "Bare" contentEditable with execCommand **quite possibly works "well enough" for simple editing**, so long as you don't care whether the generated HTML looks pretty, whether paragraphs are done with `<p>` or `<div>`, etc. You keep calling it "broken", but maybe this is because you have this perspective of a JS editor developer (which I sympathize with, but it's not the only perspective).
- For most users, ensuring the ability to copy & paste between different rich textboxes will be more important than the "purity" of the HTML. Therefore, a **harmonized set of markup across browsers** (e.g. `<b>` for bold) may be more important than the freedom of editor developers to micromanage the DOM. 
- **Advanced JS editors like TinyMCE have their own share of issues**, so outsourcing the editing tasks to external JS dependencies is no silver bullet. In fact, all text editors I have ever used (incuding multi-million dollar products) have issues that could be described as "messing up the formatting", and behave inconsistently. So I would argue that your opinion of 3rd party libs is too high (and by comparison, you judge execCommand too harshly).
- 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. This philosophy is why we get new HTML5 and CSS features all the time. A rich-text textbox is a perfectly reasonable input type to have, and the fact that so many sites have to rely on Markdown in 2019 is mindboggling. Considering your position as a W3C editor, reading your comments is a little like listening to the Minister of Health argue in favor of selling off all the hospitals, because only the private sector is smart enough to work out all the issues. :)



-- 
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-560499963