Just quickly coded up some proof of concept Flash stuff to show how one would go about making an editor in Flash:

http://oopstudios.com/stuff/dlite/flash_experiments/?dir

Hopefully this makes it’s way to Dion et all

I left out some important bits, specifically thoughts on how accessibility and SVG relate to what we did in canvas. I created a second half to the blog post here:

http://benzilla.galbraiths.org/2009/02/18/bespin-and-canvas-part-2bespin-and-canvas-part-2/

We kind of already know what Flash and SVG can do (although I am interested in hearing why you eliminated them as possibilities). You’re showing what Canvas can do. And the results are shockingly good.

I agree with not supporting IE. This isn’t an end user app, it’s a dev app. You don’t have to worry about plugin saturation. Likewise, let WebKit play catchup on this one :)

I like the idea of rendering complex widgets like a text editor using canvas. However I wonder whether the browser’s key events are sufficient to implement a full editor. I’ve already observed that curly braces do not work in FF3 on my Mac. I’ve written the key event layer for qooxdoo and it was a major pain to get roughly consistent behavior between different browsers on different platforms. I’m really interested in how you solved key handling for Bespin.

I applaud the choice of canvas. Many great editors have shipped their own UI toolkits. Since Bespin is an experiment, this gives them ultimate latitude in experimentation.

The open web depends on the platform, design, and implementation of the editor. So far so good.

Another point of flexibility is keyboard bindings and vim/emacs emulation. Personally, I can’t justify using an IDE (online or other) for serious development unless it has decent vim emulation. I imagine a canvas solution is the best bet for something like.

Presumably the performance gain was mostly from painting only the relevant parts of a file that appear on-screen. Why not do the same thing with your DIV solution (nowrap, overflow:hidden)?

In principal, I’m fine with a canvas-based text editor if it’s done right, but it has to provide all standard conventions on all platforms (accelerator keys are the biggie in my book). Also it needs to allow copy/paste in from other applications.

Are any of those things a problem in Bespin? Are any of them insurmountable?

Thanks,
Jeff

http://labs.mozilla.com/2009/02/thanks-for-the-bespin-contributions-eclipse-xwiki-and-more/

If browsers can get canvas support and performance up to the point that its a viable option for full screen canvas, we could see a world of change coming. Its not a far cry to building higher levels of abstractions over canvas the same way we do with desktop software over native graphics support. In fact, I guess that’s already happening with Objective-J to a certain degree.

Clearly this is not the kind of thing one would consider part of the “semantic” or “accessible” web, but it could be a shot in the arm for developers of complex web applications thinking they’ll have to move to flash. Here’s hoping it works out.

And then the day will come when someone will implement a browser entirely in Javascript, on top of canvas. And it’ll run in your browser too!

I’m not sure which is sickest, that it will actually happen, or that I actually can’t wait for that day :)

Having tinkered (a lot) with this sort of thing (codepress) I’d much rather see a non-javascript driven framework. A Java Applet, or even a Flash element will knock spots off in terms of speed…

Decidedly on the fence. :(