- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Tue, 13 Jan 2015 11:36:32 -0800
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Webapps WG <public-webapps@w3.org>, Boris Zbarsky <bzbarsky@mit.edu>
On Jan 13, 2015, at 11:27 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Tue, Jan 13, 2015 at 8:15 PM, Ryosuke Niwa <rniwa@apple.com> wrote: >> By "the same thing", do you mean that they will manually change __proto__ >> themselves? > > Yes. > > >> 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? > > With two realms it's not a given that both realms use the same custom > element registry. (As you acknowledge.) Okay. >> 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? > > Well, if you control both realms I would assume you would give the same name. I'm not sure I understand what you mean by that. The name of the new class MyElementB isn't important. Do you agree that the author has to create a new class in B if there is no definition of MyElement there? But how do we even determine whether MyElement's defined in B? And if did, how do we get the class's prototype? >> Didn't Boris say Gecko needs to do this synchronously in order to enforce >> their security policy? > > I don't think that's conclusive, though if it turns out that's the > case we would need different timing between normal and custom > elements, yes. Great. Thanks for the clarification. - R. Niwa
Received on Tuesday, 13 January 2015 19:37:08 UTC