[whatwg] Editing

[Jerrett Taylor]

Something else that might be worth taking into consideration is the
mangling (formating?) that the editors output as. 

Having similar behavrious is one thing, but if the markup output is
drasticly different it can be a nightmare to try to get the end result
displayed the same .. then you get different people editing the same
content with different browsers, and changing a lot more than the typo
they went to fix....




On Tue, 2005-04-19 at 22:09 +0200, Olav Junker Kjær wrote:
> 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