I think I've got the code to a point where it's very reliable at doing <p> line-breaks, so I think it makes sense to allow the developer to choose between that and <div> since it'll be very little extra effort. I'll add <br> as a (still highly experimental) mode with in that, which will allow me to get rid of the annoyingly-named forceLineBreaks.

Any objections?

I'm having some issues with the scroll view when the scroll bar is visible. Sometime, when I type some text at the bottom of the field, the view scroll by itself. Also, when this happen, I often can't scroll to the top of the field. Here is a GIF to show the problem:

(and kinda misnamed). The only time it's used is on initial render, when I would expect it to be used by insertNewline at the very least.

To reproduce the issue, set forceLineBreaks to true and add this HTML:

<p>some text</p><br>

If you put the cursor at the end of the paragraph, enter must be press twice to add a line break.

EditorView's value update process triggers a recurring timer which automatically recalculates the height at regular and decreasing intervals. This handles the situation where a slow-loading image pops in after a while and changes the height of things without any change registering to the value.

Instead of this blunt approach, we ought to be able to check the DOM for image elements and attach load listeners to trigger a height recalc only and automatically when the image loads.

Although it's easy to null out, this should be a style consideration rather than a property on the view. (Or at the very least, patched in for the composite convenience WYSIWYGView.)

Showcase.

Font sizes are all defined in px; if they were defined in em, it would take one line of CSS to scale the size of everything.

They're also currently mixed in with "required" layout items, making it a very manual and fragile process to override them for your own app. They should be moved to a separate, theme-able set of selectors.

The view doesn't currently support touch in any event.

I've got touch support enabled over in team/dcporter/touch, but I've broken resizing after image load (and probably some styles, due to an unrelated tweak in the same branch related to wrapping the contenteditable element in an outer one to facilitate height measurement).

Unit tests.

WYSIWYGView is a convenience view – a prefab compilation of WYSIWYGEditorView and WYSIWYGToolbarView. As such, it should handle all its own stuff internally; there should be no references to WYSIWYGView in (e.g.) the editor. Similarly, all documentation should move into the component views.

When you select a tool (i.e. bold, italic etc.) via clicking it in the toolbar its element doesn't gain the "sel" classname until the user begins typing in the editor.

This is because "editorStateDidChange" functions don't get called unless the editors value changes when they should be called when the editors state changes regardless of value change.

My proposed fix is https://github.com/tobias-g/rich-text-editor/compare/toolbar_selection_fix

As of 5f8dd15, any time the commands array changes, all children are removed and recreated. Changes within the commands array's membership don't trigger anything. Surely we can do better.

In its previous life, this project was in the process of moving the buttons from the icons in folder 'icons2' to the icons in folder 'icons'. We should complete the move and remove 'icons2'.

The defaultValue is used when the value is empty, but the value is effectively never empty because a blank editor contains one line break. Possibly the hint should be implemented separately, a la TextFieldView.

See the hackish if (!this._mouseDragged) this.becomeFirstResponder(); in mouseUp. What should actually happen is that the blur event handler doesn't force the view to lose first responder status. (That may not be sufficient.)

This framework involves so many classes that naming everything SC.WYSIWYGFoo is untenable. Let's figure out a better way.

My vote is RichTextEditor.Foo, shorthanded RTE.Foo (like SproutCore and SC are aliases).

There's an issue where if your cursor winds up off the bottom of the editable element (e.g. in the common case of hitting enter to add a new line at the end), the browser repositions the element to keep the cursor visible. A split second later, the view catches up and resizes itself, moving everything back to where it's supposed to be. This creates an ugly jump effect. My solution was to force the developer to specify a lineHeight property – this value is added to the view's height to ensure that the view has enough space at the bottom to allow the user to hit enter without triggering the jump-around.

This is a decidedly unfriendly API. Would be great to figure out another way to resolve or work around this problem.