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

> 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

Well, you probably know more than me about the current thinking among browser devs, but I am genuinely surprised to see you dismiss the importance of having a native HTML textbox with basic formatting when almost every forum/blog software out there has support for formattable comments. How can you compare an essential feature like that to niche proposals like MathML or CSS Regions?

Contenteditable may not be very popular (I take your word for it), but I would argue that's because it tries to do too much (and does a mediocre job of it). It's just not a great match if you're writing a comment feature (how do you prevent people from pasting some tag soup in?). But if you reduced the scope and allowed authors to customize what tags are allowed, it could replace Markdown. Browser devs might also be more interested if the scope was less daunting. You really see no problem with the fact that we have to do \*\* for bold in 2019?

> > 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).
>
> I wish I were. I tried, like you, to build my own editor on top of contenteditable several years ago. That was the first few years of Fidus Writer. I spent every awake moment fixing bugs until I finally gave up trying to create both an editing framework and a working editor (with export to various formats, document management, etc.) at the same time and switched to an editing framework for the document manipulation part.

You say "I wish I were", and then you write a whole paragraph confirming that you do in fact take the perspective of a JS editor developer :) Whereas I am talking about someone who just wants a basic rich text widget.

>>  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.
>
> I disagree. About 10-15 years ago that's what everyone did. The result then was that people would write blog posts in various word processors and pasted it into the JavaScript text editor of their platform (for example Joomla). The result would be a horrible mishmash of differently styles and noone really wants that, which is why CKEditor, TinyMCE & co improved over time.

I'm not sure what you mean by "That's what everyone did" (What did they do? Harmonize markup across browsers?), but copying from word processors is not relevant here. That's probably a lost cause (you think TinyMCE will preserve my Word formatting perfectly?). I'm talking about copying formatted text from one Web textbox to another (possibly across browsers).

I want the ability to copy & paste between different native textboxes while preserving the formatting. That's why I'm talking about standardizing that `<b>` means bold in a rich textbox. I suppose you want formatting to get mangled when the user copies from CKEditor to TinyMCE and then back to CKEditor. Because that's what you'll get if you allow each editor to have its own markup conventions.

Again, I am not against opening up primitives -- FidusWriter seems like a prime example of an advanced project that could benefit from low-level access.

> Look, no one can stop you from creating a broken web experience.

I would be more worried if you actually provided some examples of serious contenteditable bugs other than "it doesn't generate the tags I want", "it doesn't play well with direct DOM manipulation", "it has no ability to edit tables/images" or "it breaks when you paste from Word". As it stands, I don't see it as being significantly worse than editors in many applications I use everyday. I'd be happy to change my mind! It's quite possible I'm missing something.

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