Friday, September 7th, 2007

On Browser WYSIWYG

Category: RichTextWidget

Alex is on a roll (just call him butter!) and has written about the state of browser WYSIWYG editing:

The state of in-browser WYSIWYG is somewhere between pitiful and mind-numbingly painful. Opera and Safari have pulled themselves up by the bootstraps and soon all the major browsers will be at the same level of awful, more or less. This area of DHTML doesn’t get much love from browser vendors in part because only the heartiest souls ever venture into these deep, shark-infested waters so there aren’t many people clamoring for fixes to the underlying capabilities. Everyone sane just picks up the Dojo Editor, TinyMCE, or one of the other good editing packages that are available.

Since watching Abe Fettig talk about his experience building a cross browser editor in Dojo, I have stayed away with a ten foot poll. Everyone is broken.

Alex has a set of APIs he would like to see:

Since it’s not really reasonable to expect that browsers will remove contentEditable, here are my proposed APi additions to it which would allow any sane editing UI to ditch the entire command structure which can slowly fade into the background over time.

  • editableElement.openUndoTransaction(callbackHandler): starts an undo transaction, implicitly closing any previously opened transactions. All subsequent DOM manipulation to elements which are children of this element will be considered part of the transaction and normal browser-delimited undo transaction creation is suspended until the transaction is closed. The optional callback handler is fired when the user cycles back this far in the undo stack from some future state.
  • editableElement.closeUndoTransaction(): ends a manual undo transaction. Implicitly called by openUndoTransaction. Closing the transaction has the effect of pushing the current DOM state (or whatever differential representation the browser may use internally) onto the browser’s undo stack for this editable element. When an undo transaction is closed, browsers may resume automated generation of undo states on the stack intermingled with the manually added states.
  • Support for non-standard DOM positioning properties of range objects as outlined in MSDN

These APIs added to elements with contentEditable set will allow us to use regular-old DOM methods of manipulating user selections and adding complex content from user input without fighting for control of the undo stack or inventing our own (which has so many problems that I don’t want to begin to address them). Additionally, this method of manipulation will allow toolkit authors to deliver editors which operate on the semantics of the markup more easily.

Robbert Broersma of Xopus already commented that “developing a WYSIWYG editor in-browser will eventually not involve contenteditable anymore”. Somehow I don’t see the browser vendors stepping up? :/

Posted by Dion Almaer at 8:37 am

3.6 rating from 18 votes


Comments feed TrackBack URI

i want the same behavior for createRange and createSelection in all browsers… thats the main problem of all wysiwyg editors out there :(

Comment by André Fiedler — September 7, 2007

To add to Robbert’s comment, with my work [1] on the custom caret we’re pretty close to uncoupling the entire editor from the browser. This means that we can use the HTML DOM and CSS for rendering, and the XML DOM for maintaining the document. The caret is moved through the HTML DOM using TextRange, and any edits can go straight to the XML DOM from where they are synced back to the HTML DOM.

Pretty cool (and crazy) stuff!

[1]: For the sake of clarity, I, too, work for Xopus.

Comment by Mark Wubben — September 7, 2007

You should post a link to Abe Fettig’s blog next to his name. Perhaps even reference his post concerning WYSIWYG.
On the topic, I have implemented Dojo Editor in a web-based Content Management System, and it is sweet.

Comment by Joe Donahue — September 7, 2007

What Xopus is doing sounds awesome. Wish it was open source.

Comment by Justin Kramer — September 7, 2007

I think a Flex component would be great for this.

Comment by mike — September 7, 2007

@Justin – A Flex component would be spectacularly bad for this as Flex has _no_good_way_ to _accurately_ render HTML.

I too look forward to seeing the work done by the Xopus folks.

Comment by David — September 8, 2007

The whole undo idea Alex proposes is already in the whatwg HTML 5 specification.

The Xopus idea to rewrite the whole caret handling is really impressive but there is currently a major draw back. You can’t copy paste rich content into such environment or at least currently not in Firefox and Opera. But I guess this might change in the future when all browsers support the onpaste event and better clipboardData retrieval.

I think the main problem with the contentEditable/designMode is that there are no clear specifications on what commands browser vendors should support and how they should work the HTML 5 spec is just to generic.

Comment by Spocke — September 8, 2007

As someone who has (and still is) dabbling in the creation of CMSs, this is the one area that drives me absolutely batty. The creation of content within the controls more often than not makes code like Dreamweaver, with headings inside of paragraphs, or uses styled spans instead of just or . And most users seem to feel compelled to paste in Word text, where the real fun begins. If only Word would abandon the use of their proprietary

Comment by Mike Ritchie — September 8, 2007


Comment by Mike Ritchie — September 8, 2007

If only Word would abandon the use of their proprietary mso: elements and just use standard CSS and HTML, the problem would be solved instantly. But since that’s not going to happen, no WYSIWYG editor can call itself a success until it does the translations themselves– seamlessly and accurately. So far, none of the editors I’ve tried have come even close to that.

Comment by Mike Ritchie — September 8, 2007

Hey Spocke:

You’re right, the HTML 5 thing might be too generic. What I outlined is highly constrained whereas the WHAT-WG API could indeed cover the broader case. ISTM that the separation is important. If the editable area can’t have it’s *own* undo stack/state, it does us very little good to be able to roll back global DOM state. In fact, this is kinda where IE’s contentEditable falls down today. Changes to the DOM of the editable element get co-mingled with changes in the rest of the doucment for undo purposes, so hitting “ctrl-z” rarely does the “right thing”, particularly if you’re building your own editor chrome and changing it during editing in response to editing actions.


Comment by Alex Russell — September 8, 2007

Does anyone think it might be better if browser vendors themselves provided basic rich text editors with an API for extending them? I know that this would create a greater need for divergent browser-specific code (if extension is necessary), but it would allow the editors to leverage each browser’s own internal DOM creation/manipulation routines.

Comment by Trevor — September 8, 2007

Apologies to justin, s/@justin/@mike/.

Comment by David — September 8, 2007

Trevor, I’d like to see a text editing component which allows you to move the caret (preferably via an API), without CSS being dropped or weird borders being shown. Couple that with the option to maintain your own undo stack and we can build a really good editor without much hassle.

The problem right now is that the browsers try to “help” by adding resize handlers and what not, and (at least IE) by dropping certain CSS properties when editing text. Plus crappy undo.

It’s possible to build all this in DHTML but I’d really prefer not to :)

Comment by Mark Wubben — September 9, 2007

Leave a comment

You must be logged in to post a comment.