- From: Olav Junker Kjær <olav@olav.dk>
- Date: Wed, 17 Aug 2005 11:37:49 +0200
Lachlan Hunt wrote: > I'm not disputing the fact that there is an unfortunate demand for > embedded WYSIWYG editing in web based CMSs, it is the conceputally > broken implementation I'm against. I don't consider this demand "unfortunate". I consider it an essential part of the vision for the web. The "writable web" or "universal canvas" or whatever its called, has been a part of the vision from the beginning (rumor has it that TBL's very first browser was read/write). I think creating, writing and editing web sites and content is the most fundamental kind of webapp. contentEditable (or something like it) is a requirement for this vision to come true. In itself, it doesn't do much - as you have pointed out it needs scripting to be of any use. The DOM is already mutable (in effect any document is editable throug the DOM scripting by default), contentEditable just allows direct keybord entry to mutate the DOM. (Of course this is very complicatet implementation-wise, but conceptually its simple). ContentEditable is a "platform" on which a lot of different read/write web sites or apps can be built. ContentEditable doesnt say anything about the "meaning" of an element. It just describes that the element support a certain kind of user interaction. Therefore I dont think it should be indicated by a seperate element. Requiring that editable content should live in a form control is too limiting, since lots of use cases would not be possible, e.g. editing a form. OTOH we might invent a new form control which supports rich editable content without jumping through hoops, and this could be implemented on top of contentEditable. (I dont think it should be done by overloading textarea though, since it seems a bit strange to toggle the content model of an element based on an attribute) regards Olav Junker Kj?r
Received on Wednesday, 17 August 2005 02:37:49 UTC