I don't think hyped-up textareas are the way to edit content in the future, or, for that matter, in the present. We should be using transparent editors and @contenteditable IMO. Way back, at an old company, we implemented a WYSIWIG editor on IE/ActiveX (I know, I know, this was back in the day) for our CMS product which made us one of the first on the market to offer live, in-place content editing. Now the time and the tech are ripe to bring that to all browsers. Imagine, instead of a beefed-up textarea entry, you just get your blog page and fill it out "live". Or your mom's little webstore. And so on. These guys are building one and want to open source it (push them to use Apache License/BSD :)): http://www.slideshare.net/draftkraft/aloha-editor-contentedi...
I'd love to see more work going in that direction.
Also, they have pretty good UI ideas in that, some of which we had in Habari for a while (media silos, everything-is-a-plugin).
That looks like a great editor. But aren't (nearly) all WYSIWYG editors technically using contenteditable? The important difference seems to be that this one hides the toolbars until you start editing?
I think what moeffju means is that the whole page (or nearly all of it) should be editable, and we should be editing it in such a way that it is truly WYSIWYG, and not just merely a "rich box".
For example: Wordpress's editor doesn't usually look correct because the theme-stylesheet isn't included. Solving this problem either requires the template-writer cooperate, or it requires the editor be a lot smarter than current "rich box" editors.
Yes, that is an excellent idea. The user interface is much better that way. The only problem I see is communicating this to the users. What would be a good way to indicate that the user can edit the content inline? I foresee a lot of "how can I edit my site" emails ;)
Current WYSIWIG editors use contenteditable or some other browser-inbuilt rich text control, with varying results. Aloha uses parts of the browsers control, but does its own selection handling, cursor handling, and formatting control. The new Google Docs editor, from what I've read, does everything manually, including layouting and rendering the cursor. So it's reimplementing RichText controls in HTML+JS.
I'd love to see more work going in that direction. Also, they have pretty good UI ideas in that, some of which we had in Habari for a while (media silos, everything-is-a-plugin).