incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Coleman <>
Subject Re: editor handling events vs tracking DOM changes
Date Thu, 10 May 2012 22:09:09 GMT
That's a good summary -
For Wave we had the approach that we should take the approach of leaving
some stuff to the browser, and doing some stuff manually;
so for things like keyboard navigation, we let the browser do what it does,
then figure out what changed - it's possible to do that manually in code,
but laying out the contents manually and finding the position the cursor
should go in JS seemed overkill.

We also had Typing extractor to do that so we could try to mitigate
slowness during typing (which is annoying) but as the project went on and
got faster, it ended up tolerable to process each insert/delete
character(s) event in turn. This also turns out to be vital for when you
want logic that the browser
doesn't provide - e.g. if you select a particular document range and press
delete, the default thing is to delete all the DOM selected which can also
leave you with
a tricky extraction step to line up what remains with your DOM
(particularly tricky if you're allowing arbitrary custom elements in wave
whereas handling the event manually gives the ability to apply custom
delete logic, and the wave -> html DOM mapping will stay correct.

HTH - as mentioned above, there's no hard requirement either way, so if
browser APIs change it might be worth moving some features between the two
(e.g. one thing we were considering was implementing keyboard navigation to
allow 'smart' up/down presses, or alt/up-down to reorder lines, and if
implement APIs that give JS the ability to find the position of a cursor if
the event were to be processed, that'd make those simpler).

- Pat

On 10 May 2012 14:44, Pratik Paranjape <> wrote:

> I am sure someone will correct me if I am wrong...
> The editor does not handle all user events.The use a hybrid model.
> There are things that are taken out by watching changes in DOM (e.g.
> typing, pasting..).
> Extractors are used for Typing Extractor. These changes are
> then applied to
> underlying XML model, in turn used to calculate operations.
> Other things are handled before broswer does, like hitting Enter, bullets
> etc
> XML model is modified first in this case then rendered to HTML in DOM.
> There is also a third case, like in pasting. Browser is allowed to paste
> somewhere off screen,
> paste is observed , XML model is modified, then DOM is updated.
> It seems it has more to do with flexibility of allowing such Rich Text
> interaction
> than performance improvements for OT. Etherpad was plain text (adding rich
> text slowly now?)
> and prolly did not care of this level of control on how contents are
> handled.
> More here:
> On Fri, May 11, 2012 at 2:23 AM, Paulo Pires <> wrote:
> > As far as I can tell, and if I'm not misunderstanding your question, a
> > local local operation happens immediately, following the intent of
> > having an "Optimistic UI", as Google called it. Only remote operations
> > are transformed and then redrawn.
> >
> > Could it be that Etherpad has no such distinction?
> >
> > Btw, have you read the Operational Transform (OT) whitepaper?
> >
> > Cheers,
> > PP
> >
> > On 10/05/12 21:21, Dylan Dandelion wrote:
> > > If I understand correctly, the Wave editor handles user events and
> > > processes them to generate operations, which are then applied to the
> > > document result in the visual rendering of the operation.
> > >
> > > This approach is different from Etherpad, which finds DOM nodes that
> have
> > > changed at regular intervals, and then generates operations, sanitizes
> > the
> > > input and redraws the actual DOM.
> > >
> > > What are some of the advantages and disadvantages of the event-driven
> > > approach versus the diff-ing approach? Why did Wave choose to implement
> > the
> > > editor using the event-driven approach?
> > >
> >
> > --
> > Paulo Pires
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message