yabwe / words Goto Github PK

If the underlying array of character objects inside the document is instead an actual string, there will be significant performance benefit when doing each update to the data structure.

Before moving on with refactors or more functionality, let's establish a code coverage bar and help reduce regressions moving forward.

Once the JSON data structure seems to be working correctly, there needs to be unit tests...

What's an easy testing framework to add in?

• Add phantom (or another headless browser simulator)
• Create POC application test(s) to test something in words.js
• Create POC test(s) to cover code in util.js which depends on document

I stumbled on this when I read about it in one of the contenteditable issues on medium-editor.

I very much approve of the idea to not use execCommand. Have you looked at https://github.com/basecamp/trix?

From what I understand so far, a reasonable workflow around contenteditable is to

• use it to manage selection/cursor
• use it as an input device (e.g., through MutationObserver, and/or the input event)
• use it as a display device (have a separate document model that is rendered into the contenteditable element (possibly with DOM-diffing))

I tried https://github.com/jakiestfu/Medium.js and found it quite interesting, but I believe that the approach of "keeping the HTML content of the contenteditable semantic, simple, and clean" is not the best way of doing things.

To me, it looks like we still need a library that make it easy to build wysiwyg editors (not necessarily only for rich text, mind you) around contenteditable without touching the icky contenteditable parts.

Does that make any sense?