W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2011

[whatwg] Feedback on UndoManager spec

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Thu, 27 Oct 2011 16:10:52 -0700
Message-ID: <CABNRm63G12moeYbbUYLRrUk7W0+6=K8MzyV4FBEWbH=z-P9wcQ@mail.gmail.com>
On Wed, Oct 26, 2011 at 9:42 AM, Aryeh Gregor <ayg at aryeh.name> wrote:
>
> 9) In section 3.1 Mutations of DOM, you define "DOM changes" and "DOM
> State" by reference to DOM 3.  It would be better if you gave explicit
> lists, for clarity.  I think the only things that qualify as DOM
> changes to a node are
>
> * Changing the data of a text/comment/PI node
> * Changing an attribute's name or value, for an element
> * Adding or removing an attribute, for an element
> * Inserting or removing a child
> * Any DOM change to a child
>

On my second thought, I'd rather not duplicate information already present
on the DOM level 3 spec. Authors, implementors, and developers have spent a
lot of time solidifying DOM level 3, and I'd rather defer the definition of
what it means to mutuate DOM there.

13) "The highest node affecting an automatic transaction" is "the
> editing host of the lowest common ancestor of nodes, inside the undo
> scope associated with the UndoManager to which the transaction is
> added, mutated while applying the transaction".  For "editing host
> of", you might want to link to my definition:
>
> http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#editing-host-of


> In particular, your current text isn't totally clear about what
> happens if you have non-editable elements nested inside editable ones.
>  If a transaction mutates "bar" in <div contenteditable>foo<span
> contenteditable=false>bar</span>baz</div>, is the highest node the
> div, or the text node "bar"?  I assume you mean the latter.
>

It seems like just referring to your spec solves the problem because the
editing host is null if a node is not editable, in which case, we'll default
to the the lowest common ancestor of nodes.

- Ryosuke
Received on Thursday, 27 October 2011 16:10:52 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:37 UTC