https://github.com/joshmarinacci/semantic-editor-js
Questions: What do you look for in an editor? Where do the existing ones fall down? What would you like see done differently?
thx
https://github.com/joshmarinacci/semantic-editor-js
Questions: What do you look for in an editor? Where do the existing ones fall down? What would you like see done differently?
thx
In the OP, for example, create a table, go to a cell, press return (creating a second line), and then press delete. You're basically left with a p inside a td, when before there wasn't one. I feel like if you press a key and then press delete, you should go back to the exact state you were in before (or maybe after pressing delete twice).
Another thing that bugs me is when elements that should be rejoined after a split are not rejoined. For instance, if you inadvertently split a ul in two by hitting return one too many times, and then you press delete, with many editors you will now have two ul elements (and potentially weird spacing in the middle of the list in the final rendering). Another example: removing and then re-adding italics to a paragraph that had been 100% italics before the edit. Before, you had one i element, but now you might have three. I've seen some editors handle these cases some of the time, but I haven't found one that handles them 100% of the time.
In terms of features, I have always looked for the ability to visually edit Bootstrap or Foundation columns. It would be great to be able to add column systems to an editable space, and then re-size them, or even nest them.
(1) Lists, especially indenting and nesting properly. (2) Tables. Everything about tables. (3) Pasting rich text from other apps. (4) Accumulating invisible formatting data.
From what I've read, if your library uses "contentEditable" and tries to clean up after it, you're in for a bad time. Instead, the best thing is to write your own engine, like Google Docs did (this is of course very difficult and no one has mastered it).
I'll give yours a shot!
I hear you with respect to the difficulty in getting it right. Sometimes we would have a few lines of code and then 50 lines describing why the code was necessary in order to get around weird edge case behavior in one version of one browser.