In Opera 9.0TP1, we now have support for rich text editing in web pages via document.designMode. document.designMode is also what Firefox uses for rich text edting. That means Opera does it the same way Firefox does where you make a whole docuent editable, which is usually done on an iframe document or a document embedded with the object tag.
To see it in action, check out Mozilla's own Rich Text Editing demo.
The FCKeditor developers are working on compatibility with Opera. Their nightly test page already works in Opera. Once FCKeditor supports Opera, the SquirrelMail HTMLMail plug-in can be updated to support Opera.
There's one extra bonus to Opera's implementation of document.designMode. There are 3 shortcuts that automatically work without any extra coding: ctrl+b, ctrl+i and ctrl+u, which are bold, italics and underline respectively. You can use the shortcuts to toggle their styles or you can highlight text and apply their styles to the selection.
Opera now supports contentEditable also.
Textarea editors are often referred to as client-side Rich text editors, WYSIWYG editors and Iframe editors. Support for Textarea editors is an increasingly demanded feature for browsers that do not yet support them. Many find it utterly irritating to use a browser that doesn’t support this feature.
To get an idea of what a textarea editor is, view a fully-featured example. As you will see, it’s like having MS Word, Front Page, Dreamweaver or any other WYSIWYG HTML editor, built into a webpage. If you’ve used any of those programs, you know that you don’t directly edit the code. You edit the output, which in turn manipulates the code. That way you don’t have to know any programming to create the output.
You can do lots of things.
The whole power relationship of the web is changing. Technology has enabled information consumers to become information providers, and a core part of such a seismic shift is the ability to edit the web page. CMS is the main how of such technology, and many of them are using Textarea editors to enable the barrier for content production to be lowered. Markup purists may howl that one should understand HTML before writing web content, but that misguided elitism is blind to the issue that content is what really matters. If a browser doesn’t support textarea editors, the user is not going to be able to get full use of these assistive technologies.
Here’s a big list of Textarea Editors to show how much they are used.
Textarea editors by design are for generating HTML code. Because of this, a popular use for them is composing HTML mail via a webpage. Why would want to do that? The answer is simple. Webmail.
Webmail interfaces allow you to access and write email via a webpage. However, if you want to write an html formatted email, you have to know html. If you don’t know html, what can you do? Use a WYWSWYG editor if one is provided.
Many Webmail interfaces use WYSIWYG editors. Yahoo, Hotsheet, Hotmail, Mailbee and most importantly SquirrelMail?, which uses HTMLarea in its HTML mail plugin. That’s a shortlist, but as you can see, Yahoo, Hotmail and SquirrelMail? are in that list. They are very, very popular webmail interfaces.
Textarea editors are used in messaging interfaces used by many companies. Companies like that are not easily going make use of a browser that doesn’t support the things they use.
More importantly, textarea editors are used for posting on forums. Vbullentin, probably the most popular forum software, supports textarea editors and if your browser doesn’t support them, you’re stuck typing in plain text. The software more many other forums also support textarea editors and their use is increasing.
On the same order, there are millions of blogs and if your browser doesn’t support textarea editors, it’s not going to be any fun posting to them if you have to type your posts in plain text.
First off, most Textarea editors really don’t let you edit the contents of a textarea directly. They enable a contentEditable, document.designMode state of an inline frame that is layed over the top of a textarea. Enabling document.designMode for an element, basically turns it into a WYSYWYG editor with basic content manipluation abilities that you would see in a text editor. Using scripting, that content can be inserted in the underlying or hidden textarea, which can then be submitted via your basic form. For a textarea editor to work, all the textarea itself needs to support is basically, clearing and insertion of text.
However, no browser should rely on an iframe overlay to handle everything. With that said, the browser should also to be able to get the current selection in a textarea, the length of that selection, the cursor position and the start and end position of the selection. The browser also has to be able to replace the selection, remove the selection and adjust the contents of the textarea after the modification. Basically, the capabilities of simple text editor are needed, but the browser needs to be capable of doing all that via scripting.
Different browsers support different implementations of client side WYSIWYG editing.
Firefox supports the Rich Text Editing API implementation.
IE supports its own MS, partially activeX-driven contentEditable implementation. Safari 2 will supposedly support 100% compatibility with IE’s implementation.
A few specific requirements can be found at http://www.dynarch.com/forums/46
This section is obsoleted by Opera 9.0TP1!
No version of Opera supports rich text editing and therefore, Opera users are missing out. Opera9 is promissed to support Rich Text Editing
Opera developers have said that they are aware of how much Opera users are missing out, but they clearly state that it took a long time for Microsoft and the Mozilla Foundation to implement rich text editing and even longer to work the bugs out. Safari 2 supposedly will have rich text editing support, which means Konqueror most likely wil get it too. From reading, the Safari team worked long and hard to get initial support in Safari 2.
Another problem raised is, What implementation do we use?. Should Opera create their own implementation, for rich text editing or should they attempt to use an existing one.
However, Opera developers are currently concentrating on getting the basics of manipulating text in a textarea and providing some basic DOM support that rich text editors rely on. In 8 beta 1, you can see some of their efforts by looking at the document.range test, treewalker test and node iterator test. document.getSelection support is actually close to working properly now , but it is not yet complete. Basically, you have to have the basics first.
Priority is another concern. Although many feel rich text editing needs to be added now, bugs and any missing standards support needs to be added first. Rich text editing is not a standard and is probably one of the reasons it gets less priority.
Another problem is iframe security. If Opera is going to support some type of iframe overlay for WYSIWYG editing, the iframe is most likely going to need to be writable. Currently Opera’s iframe security is so tight that you cannot modify its contents like you can in other browsers; not even if the iframe is on the same domain as its parent frame/page. That means dom methods like appendChild are broken in Opera when it comes to iframes. Because of this, authors are forced to use write() or data URIs to more or less write a new page to the iframe. Using write() and data URIs is a decent workaround, for writing to an iframe, but they won’t be enough when it comes to WYSIWYG editing. (If an iframe overlay is used)
We wait patiently!
There is a Flash-based WYWIWYG editor that shows promise. This might be the only hope for rich text editing in Opera for a while.
Whether it’s evil or not, many want to compose email in HTML format and they want to do that via a WYSIWYG editor. If Opera implements a rich text editing api, WYSIWYG, HTML composition would be a possibility.
This page was created because of a reference in this thread: