In article <[EMAIL PROTECTED]>,
Steve Clark <[EMAIL PROTECTED]> wrote:
> Adam Lock wrote:
>
> > Simon Fraser wrote:
> >
> > My concern with doing it this way is that it means someone who has a
> > webbrowser instance in front of them cannot flip a switch and have it
> > turn into an editor session and vice versa. It would be very cool to able
> > do in-place editing like this rather than explicitly create either a web
> > browser or editor up front and not be able to switch between them without
> > great difficulty.
>
> In-place editing is cool, but it's not always obvious exactly what that
> means. If you in-place edit a dynamic document, what are the
> semantics? Which state of the document are you editing, the initial
> state or the state at the moment you flip the switch?
The state at which you flip the switch. It's up to the document
author to capture changed content with DOM calls, and do something
useful with them. This would be way cool though; just imagine being
able to present modifiable content without form controls! If you
could make a certain subtree of the content editable through JS,
this would be doable.
It does pose an architectural difficulty, though, and some usability
ones. First, it opens up the possibility that more than one subtree
of the document content is made editable. This either requires that
we have more than one editor on the document, or that we re-parent
the editor on focus changes between the two editable areas.
Usability issues relating to focus also become apparent; for the
user to see which part of the document is ediable, it needs some
kind of focus hilight, and the user should be able to move between
editable subtrees with the keyboard.
Let me say, however, that implementing this stuff is not high on our
list of priorities. We need to think about this stuff while
implementing the embedding APIs, but are making no commitments.
Simon
--
Simon Fraser Entomologist
[EMAIL PROTECTED] http://people.netscape.com/sfraser/
