Comments for On Browser WYSIWYG
You equate in-browser editing with HTML, but there's a whole 'nother world of schema-driven XML editing that's out there waiting for a motivated developer to conquer. This could range from microformats on up to DITA and DocBook. AFAIK this kind of editing capability simply does not exist yet.
Hi F.Baube. You're right, I do equate browser editing with HTML, because HTML is what the browser will render. If you want to do something like Xopus's XML editor, you will still need to render something out to the user during the editing experience and having that part of the experience work correctly greatly increases the likelihood that the editor will be useable. It will get easier to edit all kinds of content in a browser when HTML editing gets better.
have you seen any key-grabbing implementations which avoid content-editable / design-mode entirely? any worth pointing out? i've been playing around with writing an editor that simply watches key events and artifices the expected screen output.the main barrier i've encountered is when watching key events, i havent figured out how to prevent the browser (personally i use opera) from digesting the keystrokes. since 1/2 the keyboard does something in opera, i've had rather poor luck in my playing around. windows start flying across the screen and things start doing haywire as the text i write fires opera commands to resize, move, rescale and shift things around.like the F.Baube, I am less interested in HTML editing specifically than i am in creating editor environments on the web.
So, from my own experience, I can tell that developing a WYSIWYG editor in-browser will eventually not involve contenteditable anymore. Hardly funny anymore, right?