- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Thu, 12 Aug 2010 13:32:32 +0300
- To: Travis Leithead <travil@microsoft.com>
- CC: "www-dom@w3.org" <www-dom@w3.org>, Doug Schepers <schepers@w3.org>
On 7/2/10 1:19 AM, Travis Leithead wrote: > DOMCharacterDataModified event—should it provide a “prevValue” and > “newValue”? The definition of the event > <http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-DOMCharacterDataModified> > [1] seems to indicate “no” (which is what other browsers have > implemented), but the definition of > <http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-Events-MutationEvent-prevValue> > [2] “prevValue” and “newValue” seem to contradict that. DOM 2 Events indicates it should provide prevValue. http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-MutationEvent > > The third IE9 platform preview [3] is currently supporting supplying the > prevValue/newValue, but at a large performance cost. I still don't quite understand why this case is particularly bad. Mutation events slow things down a lot in general, but how is this case worse than others. I guess it is some IE9 specific implementation issue. I’d like to see > this apparent contradiction resolved one way or the other. Thanks! FYI, I did some testing http://mozilla.pettay.fi/moztests/events/domcharacterdatamodified.html and Gecko and Webkit seem to support prevValue. For some reason the testcase doesn't work on Opera; perhaps it doesn't support DOMCharacterDataModified with contenteditable or something. So I'd say we keep .prevValue the way it is in DOM 2 Events. -Olli > > -Travis > > [1] > http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-DOMCharacterDataModified > > [2] > http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-Events-MutationEvent-prevValue > > [3] http://ie.microsoft.com/testdrive/Default.html >
Received on Thursday, 12 August 2010 10:33:13 UTC