On 24/07/11 16:18, Aryeh Gregor wrote:
On Fri, Jul 22, 2011 at 6:58 PM, Jonas Sicking <jo...@sicking.cc> wrote:
We should have much richer events to aid with rich text editing. Using
mutation notifications for this is will not create a good experience
for the page author.
Agreed. I'd be really interested in specific use-cases if people are
using mutation events for editing here.
I am interested in web-based collaboration, e.g. for distributed
meetings, something we do a lot at W3C. We currently rely on IRC plus a
bunch of scripts to support meeting management, such as the agenda,
actions, resolutions, and generating an HTML version of the minutes from
the IRC record. My aim is to replace the current IRC system with
something much better that runs in the browser. An associated use case
is to allow people to edit slide presentations as they are being shown,
where the slides are expressed in HTML via a microformat (HTML Slidy).
I am using mutation events with content-editable plus clean up
operations to work around variations in how different browsers treat
Enter, Backspace and Delete. Higher level editing actions that are
application specific (e.g. insert slide or next agendum) can be
serialized as such instead of serializing the constituent mutations.
Cut, copy, and paste, and drag and drop operations are further
challenges to ensuring interoperability. I keep a local undo/redo
queue for mutations, and frequently serialize the changes for exchange
with other clients via a lightweight websockets server module. One
client acts as the senior editor, automatically reviewing edits proposed
by other clients (junior editors). This role is swapped around
automatically or manually. The senior editor serializes the official
changes as a sequence of updates for the trunk version of the document.
Junior editors need to be able to revert their DOM to the latest trunk
version, and reapply their local (proposed changes) after adjusting them
for the changes since the last common version (a 3 way merge). Ditto for
their undo/redo queue. Likewise, the senior editor needs to adjust the
proposed changes to an earlier trunk version to align with subsequent
trunk versions. This probably sounds complicated, but it works, and the
performance is pretty good!
--
Dave Raggett<d...@w3.org> http://www.w3.org/People/Raggett
