- From: Olav Junker Kjær <olav@olav.dk>
- Date: Tue, 19 Apr 2005 22:09:47 +0200
Ian Hickson wrote: > So, if you have proposals for Web Apps-y features, please let's hear them. > I was mainly working on semantics stuff since that's what people were > posting about. I have been thinking about HTML editing, which I think is a critical feature. IE has it, Mozilla has a limited form (designMode but not contentEditable), and Safari is rumored to get support for it soon. Therefore I think its quite important to get it specified sooner rather than later. The WA1 requirements includes: - Rich text editing: an underlying architecture upon which domain-specific editors can be created, including things like control over the caret position. - A predefined HTML editor based on the rich text editing architecture. - Text selection manipulation APIs. I think the initial goal of the spec should be to describe the level of implementation in IE 6, since this is already used in lots of apps (primarily CMS'es). However, the IE model is not very flexible, the spec should preferably be more open and allowing customization on different levels. I'm not sure about the "predefined HTML editor" requirement. Is this just the editing logic, or is it a complete editor widget with toolbar etc.? Something like <htmlarea> which automatically included toolbars could be cool. Its not critical, though, since it's easy to build a toolbar if the editing logic is available, and most app authors would want to customize the toolbar anyway. Editing is a complex topic, and the question is how many details should be specified. In IE the editing commands are specified, but lots of editing logic is not documented - e.g what exactly happens if you press delete on the boundary between two block level elements. On one hand, web app authors would like consistency across browsers, on the other hand it's would be a large undertaking to specify, and by having it unspecified browsers could compete on having the most user friendly editing. Anyways, editing could be broken up into these topics: - A way to mark an element as editable (the contentEditable attribute). - Caret and selection. When an element is editable it should be possible to place and move a caret or create a selection in the element, using keyboard and mouse. The UI for this should not be specified, since this is platform and media dependent. There should, however, be an API for getting the position and contents of the current selection. Theoretically, all editing logic could be implemented in script on top of a sufficiently advanced caret/selection API. The IE selection API, however, is *not* flexible enough to implement the editing commands which is available in the higher-level editing interface (execCommand et.al). - Typing and deletion. Typing and deletion of characters is simple in most cases (just insert/remove a character in the DOM), but it gets complicated when crossing element boundaries, eg. pressing enter, or pressing delete when positioned before the first character in a element, or pressing delete when a selection crosses element boundaries. I dont think there is a single "right" way to handle these issues. For example, in a editor for structured data, element boundaries might be explicit, so you can place the caret between two adjacent opening tags, while in a simple comment editing box, element boundaries would be transparent. How much or how little should be specified? - Undo. Undo is also a major issue. Every editing action should preferable be undoable, however since this is really a UI feature and wont impact the actual html produced, it might be left unspecifed. The question is how transparently undo can be handled. E.g. should any scripted change to the DOM in a editable element be automatically undoable, and is this even possible? Or should undo be explicitly supported by specifying "save points" in the script? - Editing commands. In IE this is supported through the methods execCommand, queryCommandEnabled, queryCommandValue etc. Again the question is how detailed the actual DOM transformations and queries should be specified. There should be a way to customize existing commands and add new commands. Perhaps the execCommand-style interface should be replaced with something consistent with the WA1 Command interface. regards Olav Junker Kj?r
Received on Tuesday, 19 April 2005 13:09:47 UTC