- From: <bugzilla@jessica.w3.org>
- Date: Fri, 07 Jun 2013 21:43:27 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21969 --- Comment #13 from Rafael Weinstein <rafaelw@chromium.org> --- Dominic, Olli is correct that what you are proposing is similar to an option we discussed for mutation observers. The danger with it is the same as it was for mutation observers. Think about it this way: the abstract danger is inviting "foreign" code to run that may invalidate your assumptions. By delaying delivery until the DOM is finished, you've removed the danger for the (C++) DOM, but you've left page script still vulnerable. The design of mutation observers has at its core two invariants: -When an observer is invoked, he can be sure that no other "actor" is in the middle of making modifications -When an observer wants to do further work on the DOM, he won't invite other observers to pre-empt him. You're proposal does not provide either of these invariants. I'm willing to be persuaded that the use here is fundamentally different and therefore should be allowed to be morepowerful (and thus dangerous), but I'm not really seeing anyone make the case that specific uses require it. In particular, having talked in person with Scott & Steve, it's not obvious to me that more synchronous semantics are actually neccessary. Steve pointed out that you misintepretted the meaning of his jsbin example. The point wasn't that it was important that the callback was synchronous. The point was that the callback wasn't firing at all. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 7 June 2013 21:43:28 UTC