Hacker News Reader

Comment by agotterer | Hacker News Reader

The replacement of the built in html editor is what all the wysiwyg's need to get so that code generation stays consistent across browsers. Think they will open source at least that portion?

View on HN

Possibly, but Google Docs doesn't write in HTML anymore. Advanced positioning and stuff like tab stops don't translate easily into CSS, so even if they _did_ open source the editor, the final HTML will look different than what it did in the editor.

Example: create a document with two lines of tab-stopped text with varying lengths, and then export to HTML.

I hope for the same. The Bespin project by Mozilla is also interesting in this space, they've built a text engine based on canvas. They target code editing but at least they're solving a (very important) part of the same problem.

I have been seriously considering going the Bespin/canvas way myself. I wrote http://bulletxt.zetabee.com/demo using a bunch of textarea tags but having seen how well Bespin works, I think it would be much better to code it on canvas. It would work much better across all the different browsers.

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.

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.

Reply on news.ycombinator.com