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

> Firstly, my editor is one JS file that is only ~30 KB minified, and that's mostly because of the various extra functionality related to the extensive keyboard shortcut system, continuity between languages, etc.. 

Right, but the user still needs to download all that other stuff to get to see the page. So it's doesn't really matter if your library is only 40kb if in the end you do require the user to download 300+kb to get access to your site.

Every time the users update their browser (on desktop every 6 weeks), they also need to download some extra bytes of code related to execCommand.

> Generally, I'm not sure who would expect to paste a webpage into a Web editor and expect good results with regard to formatting. Perhaps I lack imagination...

Actually, all modern production ready JS editors that are not just a little shim on top of execCommand should deliver decent results. It's not just about a test where one pastes an entire webpage. It's also when you select and copy an email address and accidentally grab a little too much so that you also took in a table cell that surrounded the email without realizing it. Or as I demonstrated above even without any pasting just by hitting "enter" in a paragraph on pure contenteditable in Chrome.

I don't think we should encourage filling the web with more garbage content nor web sites that are not working well - which is what happens if we tell people they should use execCommand-based editors for "simple editors". Note though that I think your case is different because you don't have a save function - that means that the output of your editor will necessarily have to go through a second editor before being saved. For this reason I think you actually found a case that's different from previous cases. Note though that your editor only functions well because other editors do the cleanup that yours does not.

> Also, I noticed that the cleanup performed by TinyMCE doesn't preserve formatting if you copy from MS Word to TinyMCE, then to MS Word again. There goes one potential use case. 

That's right, it will always require white listing and for the editor to actually grasp what they are dealing with. You cannot just let the browser throw anything in, but you have to write filters that interprete the incoming text.

> As with any feature, you have to draw the line somewhere. Of course, the W3C would decide the scope, based on demand. I think the key is to start small. Define something like `<textarea type=rich>` and allow only a very restrictive subset of HTML. Let's say, whatever formatting is allowed in a Reddit comment. The goal would be to allow faithful copying from one textarea to another, even across browsers.

See the thing is that I have been at this for around 5-6 years. Others have been at it for a decade before that. It's just not that simple, and so we gave up on trying to standardize the exact dom manipulations that come out of execCommand a long time ago.

I think that your usecase is one in which execCommand isn't overly problematic if your users don't accidentally paste something in there that breaks it. But besides a minor improvement in download speed, I don't really see any advantage for you either going that route. 

Altogether, I don't think it's a usecase that by itself justifies us spending maybe a decade or two trying to standardize and fix the dom manipulation aspect of browser's native contenteditable implementations + execCommand. That will likely also turn into an increase in browser download size so the advantage of your site being 330kb rather than say 600 kb is not really an improvement for the users anyway.

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