[ update April 28 ]

Mike in our office here just found this case of WYSIWYG editing in Safari. VERY cool! Unfortunately, everything works just slightly differently than in IE or Firefox … the triggering mechanism for the B, I, and U (and other) buttons is a little different. But it’s a step in the right direction.

Something I’ve been waiting for for a long, long time is rich-text editing (RTE) in Safari. Others have been waiting, too.

Rich-text editing is becoming increasingly important in a world where the web browser is becoming more and more central to our experience of a computer. Content mangers use it to allow non-technical people to update web content in a WYSIWYG interface. Webmail apps use it to give users more and better options for customizing their emails. And in the department that I lead, we want to use it to allow non-technical clients to send us data with boldfacing, italics, and underlining.

Rich text editing in a browser depends on support for document.designMode. It was supposed to arrive, according to some, including those who should know, in Safari 1.3.

But I updated to Mac OS X 10.3.9 this morning (~50 MB, yikes!), and sure enough, although Safari was updated to 1.3 (v312), RTE functionality was not available.

Now, it’s a little tough to tell, sometimes, because most sites that employ rich editing employ some form of browser detection that says, OK, if you’re Safari, I’m not giving you the RTE, I’m giving you a standard textarea box. But the guys at the office did some playing around, and took out some browser detection-code from an RTE solution we’ve put up in-house … and no dice.

So … either document.designMode was pulled from Safari 1.3, or it wasn’t actually planned, or it must be called in some manner differently than for Explorer or Firefox.

Bah. Humbug.