Implementing good text controls in Canvas is a fool's errand. The spec itself warns against it:

http://www.whatwg.org/specs/web-apps/current-work/multipage/...

They wanted to be ambitious and to their credit they got very far. They gave a few talks on the hurdles they had to overcome. Measuring the height of text, making their own custom scrollbars, resizing woes, etc. They did a good job with a lot of it.

They admitted it was fun but too hard to get everything right. They ran into most of the problems in the spec: "Unlike Skywriter, Ace uses the DOM to render instead of the <canvas> element making it compatible with a wider range of browsers and potentially giving it a leg up in accessibility."

http://mozillalabs.com/skywriter/2011/01/18/mozilla-skywrite...

The code for Skywriter was actually really good. I used a lot of it to make my in-canvas scrollbars before moving on to my own code.

I happen to know the story, since I was there for much of it.

IIRC, Ben and Dion originally went the canvas route for:

1. fun 2. performance 3. total control over rendering

I was never personally involved in the rendering part of Bespin. I do remember talking with Dion one day and he was telling me that he thought it would be possible to make a DOM-based renderer that performed well. We had lots of other stuff to do, though.

Time passed... We rejiggered Bespin a good deal before it became Skywriter.

Then, last September, I was in Berlin with Joe Walker and Patrick Walton. We were walking from the hotel to JSConf.eu and talking about accessibility and DOM-based rendering. Coincidentally, that very day Fabian Jakobs of Ajax.org showed off Cloud9 and Ace (which used DOM-based rendering and was, indeed, quite fast).

I'll just note that accessibility and full internationalization are *hard, if not actually impossible, to do with pure JS in the browser alone. I recently started a feature page to start gathering information about exposing more APIs to browser content to enable the creation of fully a10y- and i18n-ready editors:

https://wiki.mozilla.org/Features/Desktop/EditorAPI

I think the main issues were accessibility, IE support without a canvas stand-in which could be very slow, and accessibility. Also, general rendering is pretty speedy on all browsers, whereas canvas rendering was pretty variable until recently (and still is for fast redraws).

Also makes theming changes quite a lot easier using css.

(http://groups.google.com/group/ace-internals/browse_thread/t..., http://groups.google.com/group/ace-internals/browse_thread/t...)

They would have preferred to go this route in the beginning. I think the main reason at the time for avoiding DOM was actually performance -- probably all the various improvements in browsers since then have changed the situation.