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

> How can you compare an essential feature like that to niche proposals like MathML or CSS Regions?

I am arguing all the time that it really is important. And that although the percentage of websites using contenteditable may be low, almost all content on the web has gone through contenteditable as part of the production process.

That being said, it's apparently not important enough for browser makers to where they employ and entirely "department of contenteditable" which would be needed if it is really should solve all the issues there are.

> 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).

Yeah, so kind of. Raw contenteditable is not used much. But contenteditable + a ton of JavaScript is used in just about all editors because for some things there is no way around contenteditable.

And yes, so given the situation: understaffing at all browser makers, other groups that are interested, we have tried to come up with a sort of slimmer contenteditable that doesn't do things that are surprising to JavaScript developers and that they therefore more easily can write a working editor on top of. You can see the proposals of a `contenteditable="typing`", etc. in our draft spec. The idea was initially to combine that with beforeinput events to make it quite straightforward to create an editor. Unfortunately for various reasons Chrome decided last minute that beforeinput was not going to work well for them due to some Android issues. So they implemented "Input Events, level 1", which is basically half of what is needed. That was two years ago. This year there is a new proposal "EditContext" which hopefully develops into a replacement for that. Let's see where it is heading...

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

I actually don't think the issue here is that it's too difficult to make a richtext comment form editor. I think on sites that are for less techy people that's what is done. On github they have this markdown editor---I am guessing---because they found out that tech people prefer being able to type the entire thing rather than interrupt their typing to click on a bold-button.

> I want the ability to copy & paste between different native textboxes while preserving the formatting.
...
> 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.

Yeah so one case that I thought was really relevant for what you are saying is text that is being copied from Google Docs to Wordpress. At least before Gutenberg it got mangled and had to be cleaned up manually. Simple paragraphs would get double line breaks between themselves once in Wordpress. I thought it was a good example because this exact copy operation between these two software packages must be something millions of users must be doing every day, yet it wasn't just working. So for that exact purpose I would have liked to have some kind of standardization. But after talking to the browser developers I realized that that is not something they wanted to be part of - this would have to be something the two JavaScript developer teams would have to standardize. I am not heman and my time on this planet is somewhat limited so I don't have plans for setting such a standardization up, but I agree 100% that it would be a good idea to have such a standardization to be used for copy/paste between different text editors. If someone else organizes it, I'll be happy to participate.

So to go back to your point:

> I want the ability to copy & paste between different native textboxes while preserving the formatting.

In around 2005 it was apparently the common thinking that preserving style should be the top 1 priority. Preserving styles is still important, but it seems it has now switched to where one wants the style to fit in with other texts on the target end. Imagine github had a raw contenteditable commenting system here and each one of us would be using a different service like typeit to write our answers and then paste it in here and so the flow of comments ends up being a mix where I write in Times New Roman, blue 32pt, and you in some Caligraph font, grey, 8pt. Even though the style was preserved for each comment perfectly, the end result is undesirable in most cases.

 > I would be more worried if you actually provided some examples of serious contenteditable bugs

Well, just look for it in your favorite search engine and you will find all kinds of issues with it. I already explained how I could break your editor within a few seconds, but there are many other examples out there.

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