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.

The minimum payload is about 80 KB (after compression), though it will depend on the ad that gets loaded. If the user has disabled ads, it's about 40 KB compressed. I am assuming that the user will have the Google ad scripts cached.
You also seem to have missed my comments about the time spent parsing and executing all that complex editor code.

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

A specious argument. Updating your browser is not an activity where responsiveness is important, unlike navigating between web pages.

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

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.

> Or as I demonstrated above even without any pasting just by hitting "enter" in a paragraph on pure contenteditable in Chrome.

Hmmm... that doesn't affect the functionality and if you're concerned about how the HTML looks, you can always renormalize the HTML -- if there are two adjacent \<b\> tags, merge them.

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

Assuming the "simple editor" does not generate its own markup, but relies exclusively on execCommand, are there any serious problems?

> Note though that your editor only functions well because other editors do the cleanup that yours does not.

It seems to work fine when I copy some formatted text from my editor opened in Firefox to my editor opened in Chrome. 

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

Maybe you don't need to standardize the caret/selection operations. It's okay if the widget behaves slightly differently across browsers with respect to things like which parts of nodes get selected when I change the selection. Every editor app works a little differently anyway. (In fact I think it's humanly impossible for two teams to write two text editors that behave identically. Too complex.) Just make sure the HTML output can be understood by another browser. But perhaps it already works all right in that respect?

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

OK, so you think it's a minor speed difference, but what would be the advantage of going with an external JS editor? What exactly does TinyMCE do better than bare contenteditable?


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