- 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