- From: Andrea Giammarchi <notifications@github.com>
- Date: Thu, 27 Oct 2016 09:46:28 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/598/256702169@github.com>
@matthewp the problem is that in your case the element gets promoted. This is, metaphorically speaking, the equivalent of the following: ```js var obj = {data: 'BUG'}; // redundant extends here // it's only to explain the metaphoric case function MyObj() { Object.call(this); // super() console.log(this.data); } Object.defineProperty( MyObj.prototype, 'data', {get: function () { return 'OK'; }} ); // when a custom element is defined // elements that reflect its definition // will be promoted in a similar fashion // upgrade the prototype Object.setPrototypeOf(obj, MyObj.prototype); // and execute the constructor (+ super call) MyObj.call(obj); // BUG // but new instances ... new MyObj(); // OK ``` **Why is that?** The previously defined `data` property is **own**, and own properties shadow inherited properties. Custom elements can be defined in the future, but until that moment, if you have them already in the page, or you create them in some other way, these acts exactly like any other regular `HTMLElement` would. The moment they get promoted, passing through the constructor, is the moment they could have own properties able to shadow inherited one, like in your case. There's no way to change this behavior because there's no way we want to lose the ability to define in a non blocking way with asynchronous promotion Custom Elements. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/598#issuecomment-256702169
Received on Thursday, 27 October 2016 16:47:20 UTC