[whatwg] DOM Range: redefining behavior under DOM mutation
rniwa at webkit.org
Sun Apr 3 04:54:09 PDT 2011
Sorry for the delayed response.
On Tue, Mar 29, 2011 at 11:53 PM, Aryeh Gregor <Simetrical+w3c at gmail.com>wrote:
> > That sums up the situation, yes....
> So is anyone planning on actually trying to remove DOM mutation events, or
We would love to. We've already made DOM mutation events asynchronous
during editing commands and adoptNode.
> That's actually a really hard question to answer, due to the command
> > dispatch setup used (which has tons of indirection). ;) Which command
> > you thinking here?
> Just something simple like running execCommand("bold") when "bar" is
> selected in fairly trivial markup like
> The result will be that "bar" is still selected but now wrapped in the
> same <b> as "Foo", which isn't the result you'd get using any sequence
For WebKit, we fix selection as we modify DOM. When things get really
complicated, we save Range as the visible position index at the beginning of
a command, and restore the Range later using that index because most of
commands don't add/remove text.
On Wed, Mar 30, 2011 at 2:48 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 3/29/11 5:53 PM, Aryeh Gregor wrote:
>> So is anyone planning on actually trying to remove DOM mutation events, or
> I think Jonas is still planning on it; we just need to implement a
> replacement for them first...
It's my understanding that implementing input/beforeinput events will
address most use cases of mutation events at least for editing purposes.
More information about the whatwg