Using WYSIWYG editing tools is the ONLY thing that makes me use Firefox or IE.
I don’t care if adding WYSIWYNG editor support would break the standards or not. Opera is a commercial product, and if there isn’t a standard way to do something then it had better invent its own way (or copy Mozilla) to satisfy demand.
I am so looking forward to the day I can build a weblog tool using “Bitflux Editor”:http://www.bitfluxeditor.org/ (which allows for inline editing, probably the most revolutionary online editor around), and edit my pages in Opera. Editors like this are the way of the future, and Opera must not be left behind (as it is ahead of the crowd in most areas at present).
Even if something as radical as the Bitflux Editor couldn’t be supported, at least support the tradtional textarea-replacement type like “kupu”:http://kupu.oscom.org/ (being designed for “Plone”:http://www.plone.org), “htmlArea”:http://www.interactivetools.com/products/htmlarea/, or “FCKEditor”:http://www.fckeditor.net/.
That’s not too much to ask for, is it?
_[First posted in the "Opera forum":http://my.opera.com/forums/showthread.php?s=&threadid=59735 where it got no replies]_
2 comments ↓
Kupu (and most other JS HTML editors) relies on a widget provided by the browser. This widget was originally something IE specific (and M$ called it ‘ContentEditable’) but was adopted by Mozilla a bit over a year ago (which called it ‘Midas’). KHTML (Konqueror, Safari) is about to adopt it too, but I don’t know about any plans of the Opera people, I didn’t hear much about it still.
Bitflux uses a different approach: it leverages the (more standard) DOM API to write a complete XML editor (which does schema validation and all) and theoretically it should be possible to port it to Opera, since that seems to (unfortunately I’m not an expert here so I’ll stick to ’seems to’ for now) support most of the DOM standard and such. As far as I know, however, Christian Stocker is a Mozilla user himself and I don’t know if he’s interested in porting his application (which usually doesn’t only mean you have to write additional JS but also that you modify existing code, which can obviously lead to bugs and instability).
Perhaps it makes sense to ask the Opera people to implement some form of ContentEditable (the more like the IE implementation, the better I would say), or of course you can try to join development of Bitflux (or perhaps even branch it).
It looks like there is still no progress at implementing the MIDAS specification in KHTML. The KDE bug tracking system says that noone should hold its breath for the KDE v3.4 release.
Leave a Comment