[joelgwebber]

One important thing to consider before going down that route -- the font metrics in the Canvas API are extremely impoverished, so it will be very difficult to do much more than a simple text editor. In particular, there's no support for constraints, wrapping, etc. You can only ask for the width of a given string. This is particularly nasty if you want to do, e.g., asian languages that are hard to segment. The browser desperately needs real font metrics, segmentation, etc.

[chime]

You're right. Though I could do what Google is doing. They're not doing direct font-on-Canvas, which would be pretty cool actually. They're creating/editing divs/spans on the fly. I already do that with textareas but the problem is textareas work differently on different browsers where different events get fired for similar actions. So technically, I'm doing almost the same thing they're doing at a basic level (pressing enter in middle of a sentence creates a new textarea below the current one and move the text after the cursor into the new textarea).

What I was wondering if I should do or not is create my own cursor management. The benefit of that will be better control over copy-paste, drag-drop etc. I am trying to build an undo system for Bulletxt and in some browsers, you can just drag-drop text in the same text-area without firing any keypress/up/down events. Then I have to hook on to the onupdated/onchanged events which may not offer enough granularity if you make multiple drag-drop actions. Additionally if you drag text from one textarea and drop it into the other, I can't always tell what the source was in all the browsers. Writing my own layout-engine would definitely solve that issue. Plus undo would be very easy because every mouse-click/keyboard would be an event that can be undone.