4 ms·
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 hi
by jules 16y ago
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?
- geocar 16y agoI 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. I've started something that takes the latter approach at http://geocar.sdf1.org/ed/test.htm http://geocar.sdf1.org/ed/test.htm The idea was that an Apache filter would insert an enable_editor() if the user had a logged-in cookie, but the above link just activates it in onload.
- jules 16y agoYes, 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 ;)
- moeffju 16y agoCurrent 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.