Discussion on how we can better implement document.execCommand(); or feasable workarounds.

[DennisSuitters]

As per the title, there has been a lot of issues regarding how some elements are used incorrectly, and elements used that are considered deprecated by the W3C.

As you (reader), would figure, I've been doing a lot of research into this, and have even opened issues with the Chromium (Blink) Team, and tried speaking to members of the Mozilla (Gecko) team about how document.execCommand(); incorrectly uses markup elements.

I've found through various article's, that each Rendering Engine uses their own implementations, for e.g. EdgeHTML will use <strong/> (correct for HTML5) instead of <b/> (deprecated for HTML5 possibly others). Where Gecko (Firefox) uses <b/> (https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand).

And Summernote isn't (obviously) the only editor with this issue (thankfully). I found this https://stackoverflow.com/questions/12158503/definition-of-execcommand-function-for-bold/12166267#12166267 which indicates that CKEditor has created their own workaround, but is licensed, so can't simply be copy/pasted to solve our issues.

So, do we keep pestering Browser Vendors, HTML Rendering Engine developers to fix how their Browser and Rendering Engines interact with DOM Elements? Or do we create workarounds, which will bloat, and make the code, and in turn page slower?

Don't get me wrong, Browser Vendors have done a fantastic job providing software to allow us to view Web Pages, but I believe if they want to preach how they are better than their competition, then they need to fix the underlying API that they allow developers access to, to use the DOM recommended by W3C.

Now, I get that there is backwards compatibility to take into account, then there's Email, and different Document Types that browsers can use, so in that vein, I think they should be using the elements depending on the DocType declared in the Document, which I know they already look at when a page is loaded.

I also find it misleading, that the different browser Development tools are capable of notifying us which DOM Elements, and well as CSS elements are deprecated. It's almost as though the teams developing these tools and software don't even talk to each other.

Anyway, I'm opening this issue, and not just having it as an in-house team only as I know there are a lot of talented contributors that can have valid input.

[DennisSuitters]

Oh, and something that I find ridiculous is that Google, even though they produce and work on Chrome, their own browser-based editor (Google Docs), doesn't use the document.execCommand(); API Function.

[easylogic]

@diemendesign I agree with you.

To implement document.execCommand() function, we need a specially document structure for summernote.

For example, as you say, we must can apply strong tag in anytime.
This is able to difference by every browsers and editors both.
It seems to very challenge that implement w3c or summernote spec .

But i want to try this.

The idea is that the Web should no longer be browser-dependent.
The browser will still come out, and the changes we make cannot keep up.
If our document format is clear and in the same direction, I think we can solve many browser-specific issues.

[IgnacioHR]

Now that document.execCommand(); is deprecated, I think it is time to think on alternatives.

Mozilla execCommand, official documentation

Stackoverflow, question

I propose to create an interface to handle the modifications in an abstract way, we could even create an interface just with one method called execCommand, then, we could create concrete implementations of that interface for every DOCTYPE and some defaults...

[DennisSuitters]

As mentioned in the other issue you commented on @IgnacioHR Moz still refer's back to using execCommand(), as pointed out in the Stackoverflow link provided (thank you). Some research is needed me thinks.
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content

[DennisSuitters]

I found this https://stackoverflow.com/questions/12158503/definition-of-execcommand-function-for-bold/12166267#12166267
Which looks like from one of the CKEditor developers. Maybe we need to do similar.

[IgnacioHR]

You found a good post indeed. We tried to use ckeditor two years ago and I trust them from the technical perspective. We could not reach a commercial agreement and this is why we moved to summernote. Summernote is working very well because it is build on top of jquery. CKeditor 5 created their own DOM model to support the documentation and distribution of node changes in the team. In our implementation we decided to go other way... but that’s a different history. IMHO implementing a custom library for execCommand changes is the right aproach Enviado desde mi iPhone El 10 jul 2020, a las 12:08, Dennis Suitters <notifications@github.com> escribió:  I found this https://stackoverflow.com/questions/12158503/definition-of-execcommand-function-for-bold/12166267#12166267 Which looks like from one of the CKEditor developers. Maybe we need to do similar. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[orchardguides]

It would be a shame to lose the functionality provided by document.execCommand(). Used properly, this command makes it remarkably easy to create editors that can be used to style HTML documents in highly sophisticated ways.

In my own work, I've been able to develop an online editor that allows users to insert Tables, Lists, and other elements and style these elements in pretty much any manner allowed by CSS. In addition, the editor implements undo/redo works flawlessly. And all of this was accomplished in less than 1,400 lines of HTML, Javascript, and CSS.

If we lose document.execCommand(), I guess that my editor just stops working.

I think the mistake that developers make when using document.execCommand() is that they commit changes to the contenteditable without going through document.execCommand(). Instead, they alter the document using javascript directly. This, of course, messes up the undo/redo functions. When every change is routed through execCommand, every change is automatically registered with undo/redo and a separate mutationObserver is not required.

If you want to see how I insert and format elements such as Tables and Lists using only document.execCommand(), the source code for my project is available at: https://github.com/orchardguides/Kei-HTML-Editor

An online working copy of this editor can also be viewed at http://orchardguides.com/KeiEditor/

[DennisSuitters]

The biggest issue I have with the implementation of document.execCommand(), is each Browser producing different results and implementing it in their own way, which overall isn't such a bad thing how they code it as such. Regardless of how it's coded, the results produced using the function should have the same results output regardless of the Browser used.

Manipulating classes over inline styling is also something that needs addressing as well. Current Javascript (even though each Browser again behaves in it's own way) has new functionality to help greatly with this, which begs the question as to why that functionality hasn't been implemented into the execCommand() seeing as though the new Class manipulation functions are present, mayhaps, they aren't support in all Browser as yet.

[DennisSuitters]

I'm going to close this, as it's something that we are going to have to work on, as the document.execCommand(); even though it's still referenced in documentation by Moz, and possibly others, it is considered deprecated, and we need to take steps to stop using it, as eventually at some future point, Browsers will stop supporting it.