Re: Mutation events replacement

On 24/07/11 16:18, Aryeh Gregor wrote:
> On Fri, Jul 22, 2011 at 6:58 PM, Jonas Sicking <jonas@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<dsr@w3.org>  http://www.w3.org/People/Raggett

Received on Monday, 25 July 2011 09:49:46 UTC