W3C home > Mailing lists > Public > public-webapps-bugzilla@w3.org > August 2012

[Bug 18732] [Custom]: element upgrade algorithm does not preserve attributes, event listeners, references

From: <bugzilla@jessica.w3.org>
Date: Thu, 30 Aug 2012 14:54:23 +0000
Message-Id: <E1T768V-0000r3-AW@jessica.w3.org>
To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18732

Daniel Buchner <danieljb2@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danieljb2@gmail.com

--- Comment #22 from Daniel Buchner <danieljb2@gmail.com> 2012-08-30 14:54:22 UTC ---
(In reply to comment #21)
> If we copy event listeners based on that arguments, we should copy also
> all the expando properties.
> And I don't want either one.
> I prefer simple APIs which use as much existing infrastructure as possible.
> So, clone() + replace() + whatever defaults the options has is what I'd
> prefer.

After consideration, I agree that we should *not* copy event listeners for a
few reasons:

- Node.clone(), even with the deep arg set to true, does not do this. The
expectation of this clone/replace would be symmetric with that existing,
similar interface.

- Presumably (step in if this is not the case Dimitri) a developer would just
add any default event listeners that must be strictly bound to the inflated
custom element inside the upgrade event the recieve.

- Due to the rise of event delegation techniques to near-ubiquitous status in
the developer community (I can't recall a single popular JS framework that
doesn't use it), many of these even situations have become non-issues.

- Scott brings up a developer expectation mismatch that I at first agreed with,
but after further thinking, do not believe is an issue. The fact is, this is a
pretty advanced web API - it is unlikely folks with only basic-to-novice level
understanding of HTML will ever get stumble across a situation where they're
dealing with custom elements. Consider this: If you have gotten to a point
where you even know to write <x-foo> you probably have a working understanding
of custom elements. I'd rather defer to the educational power of web API
socializers and evangelists here to get the word out that the clone()-ish node
replacement done here behaves the same way the existing Node.clone() interface
does.

That's my 2 cents :)

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 30 August 2012 14:54:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 30 August 2012 14:54:25 GMT