[whatwg] Editing

[Olav Junker Kjær]

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