W3C home > Mailing lists > Public > public-webplatform@w3.org > July 2014

Re: MutationEvents

From: PhistucK <phistuck@gmail.com>
Date: Sun, 13 Jul 2014 19:33:13 +0300
Message-ID: <CABc02_Jq8078SA8VTe5mm-jjQ6iTmegQBczMenF21FoBSixR7A@mail.gmail.com>
To: "Rob^_^" <iecustomizer@hotmail.com>
Cc: List WebPlatform public <public-webplatform@w3.org>
​You seem to have gotten yourself into an infinite loop, because you change
innerHTML (mutate) of an element inside of the current document when these
mutation events fire​...
I created an iFrame and changed the content of the iFrame instead - nothing
loops anymore for me. The edited version is attached.

With the fixed version, I think your testing would be feasible.
These events do slow down the renderer, but not by that much that it is not
possible to work with them. When a lot of DOM operations happen, they will
be slow (say, 100 milliseconds instead of 0 milliseconds...), but the
renderer does not get stuck, unless you are in an infinite loop. :)


Unless anyone else objects within a week, I will remove
dom/Navigator/constructor.


☆*PhistucK*


On Sun, Jul 13, 2014 at 1:58 PM, Rob^_^ <iecustomizer@hotmail.com> wrote:

>   Hi PhistucK, et al.
>
> attached please find mutationevents.htm which is my mashup for exploring
> the MutationEvent api. Load the file up in your favorite browser and
> check/uncheck the event handler checkboxes. The event properties and
> methods are displayed in a sidebar on the rhs. Press an action button, for
> example the toggle bgcolor attribute of the body tag which will fire the
> DOMAttrChange event.
>
> I’ve moved on since drafting the mashup and have not compared all of the
> event handlers support in other browsers. The trouble is that MutationEvent
> do impinge severely on browser performance... turns My Favorite Browser
> into a brick!
> Using it to monitor depreciated presentational attributes is probably not
> a good example, but anything more complicated, say a recursive ul
> appendChild, is known to slow the browser down.
>
>  What do you mean by "Gecko and Webkit ignore the addEventListener calls"?
>
> the DOMAttrChange event does not fire in other browsers.... a bit of
> research suggests this is a known ‘feature’ of those browsers
> implementation of the depreciated API. There are no errors in the console,
> nadda...
>
> It appears to me that the API has been (and probably should be) abandoned.
>
> Greetings from Australia.
>
> Additionally:
>
> The following is a list of constructor methods that I have been allocated.
>
> dom/Navigator/constructor
> ... only the one item in my list.
>
> Please flag for deletion.
>
>
>  *From:* PhistucK <phistuck@gmail.com>
> *Sent:* Sunday, July 13, 2014 7:20 PM
> *To:* Rob^_^ <iecustomizer@hotmail.com> ; public-webplatform@w3.org
> *Subject:* Re: MutationEvents
>
>  There used to be a deletion candidate flag, but it is not there anymore.
>  I also think it should be deleted, but I want to wait for comments of
> others. If everyone agrees "constructor" property articles should be
> deleted, you can give me a list of article links to delete and I will
> delete them.
>
> What do you mean by "Gecko and Webkit ignore the addEventListener calls"?
> It is mostly implemented in these engines. Perhaps you picked a certain
> event that is not implemented.
>
>
> ☆*PhistucK*
>


Received on Sunday, 13 July 2014 16:34:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:02 UTC