- From: Russell Bicknell <notifications@github.com>
- Date: Mon, 20 Feb 2017 23:21:42 -0800
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Tuesday, 21 February 2017 07:22:17 UTC
I don't think the custom elements API should introduce a new, single-scenario composition / inheritance mechanism (`defineBehavior`, `defineExtension`). If there are features that built-in elements have that can't be emulated by custom elements because they aren't exposed by the platform, we should be working to expose them (@rniwa's suggestion) rather than claiming that they exist because of a separate, element-only method of composition. Given that the features in question aren't currently exposed in any form (other than as part of the built-in elements), why concede that we need a special way to compose them? Wouldn't it be preferable to expose them in a way that makes them composable in plain JavaScript? Further, if this new, custom-elements-only composition API then isn't necessary for using these features in your custom element, why should it become part of (read: add complexity to) the custom elements API? This seems like a 'solution' looking for a problem. -- 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/509#issuecomment-281264461
Received on Tuesday, 21 February 2017 07:22:17 UTC