- From: <bugzilla@jessica.w3.org>
- Date: Mon, 29 Oct 2012 22:45:24 +0000
- To: public-webapps-bugzilla@w3.org
- Message-ID: <bug-19763-2532-092UddfG8a@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19763 Daniel Buchner <danieljb2@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |danieljb2@gmail.com --- Comment #1 from Daniel Buchner <danieljb2@gmail.com> --- I would be against copying event listeners for a few reasons, here's why: - there are a number of things set by user JS after the page is parsed that cloning a node does not copy, to only do a subset would be confusing. - by copying event listeners, which will likely contain calls to the custom element's unique prototype methods, we create a situation where events may be able to be invoked by the interface end-user *before the element it upgraded*. This means that the refs to anything custom about the element would fail. It is better to say to the developer "assign all user-defined JS events not part of the component's operation itself, inside of the upgrade event (as opposed to DOMContentLoaded,Load, etc)" - I cannot be sure of this, but I would bet performance would be impacted negatively if we allowed this (though I am unsure to what extent) Bottom Line: push developers to do all such operations within the upgrade event loop, it is a more cohesive and expected position than hopscotching on what we will copy and what we won't (child elements and originally-specified HTML source attributes withstanding, for obvious reasons) -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 29 October 2012 22:45:26 UTC