- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Tue, 13 Jan 2015 11:15:53 -0800
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Webapps WG <public-webapps@w3.org>, Boris Zbarsky <bzbarsky@mit.edu>
- Message-id: <2621F35A-34FA-4B98-8415-BBE0522C70DA@apple.com>
On Jan 13, 2015, at 7:05 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Tue, Jan 13, 2015 at 6:15 AM, Ryosuke Niwa <rniwa@apple.com> wrote: >> As far as I tested, WebKit and Blink keep the old __proto__ while Gecko changes it to the adopted document's prototype. There is a bug in DOM component about this: >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567 > > So, the basic agreement as I understand it: > > * Normal elements change their prototype during adoption > * Custom elements get a callback to be able to implement the same thing By "the same thing", do you mean that they will manually change __proto__ themselves? Let's say we have MyElement that inherits from HTMLElement and we're adopting an instance of this element (let's call it myElement) from a document A to document B; MyElement is currently defined in A's global object. I have two questions: Why did we decide to let custom elements handle this themselves instead of doing it in the browser? When "myElement" is adopted into B, there is no guarantee that MyElement is also defined in B. Does that mean MyElement may need to create another class, let us call this MyElementB, in the B's context that inherits from B's HTMLElement? > Now the outstanding questions: > > * Should normal elements change their prototype at the same point in > time custom elements have the opportunity to change theirs, or should > it happen synchronously? Didn't Boris say Gecko needs to do this synchronously in order to enforce their security policy? > * Does it make sense that when subclassing a normal element this > automatic prototype changing aspect gets lost? Can I have an answer to my question 1 above first? - R. Niwa
Received on Tuesday, 13 January 2015 19:16:27 UTC