I think ProseMirror is right to have the document model as a focal point as I've reached the same conclusion with Quill and have worked on to improve for some time now. Extensibility becomes quite limited and often leads to a lot of edge case code. These editors really don't know themselves precisely what content they contain and cannot offer an API for the simple task of inserting text in a specific nth position. Older editors just use the DOM (or HTML strings) and hand that to you as their API. ![]() That way no weird/unexpected markup ends up in the editor (whether or not the editor also utilizes contenteditable).Īnother trend is a focus on the document model, which is the editor's main data structure to keep track of content. But it's near impossible to not use contenteditable at all and all editors that I know of (including Trix and ProseMirror) use it to some degree.įor example to handle paste, I've found the best way is to detect a paste, shift focus to another invisible contenteditable div, interpret the pasted content, and insert that into the actual editor through the editor's API. ![]() So the major differences would probably be when and where each of these editors tolerate native contenteditable behavior and which implement it themselves. Editors in the last couple of years simply avoid using contenteditable in as many cases as possible. ![]() I would say the old approach was to add contenteditable=true to a, call execCommand for formatting, and try to fix the issues this would cause.
0 Comments
Leave a Reply. |