As an example I made a simple input-based Custom Element which prevents alphabetic input, and dropped it in an very simple Ember app.
Here's the version with a subclassed <input>: http://jsbin.com/mevemu/1/edit?html,output And the version with an <input> nested in a custom element: http://jsbin.com/hepuvif/1/edit?html,output. The custom element adds an input if one wasn't provided in the markup. Click the "Show" button to inject the CE. The CE is registered at the top, and the template (where it's included) is at the bottom. Note that the 2nd version isn't completely functional because Ember isn't expecting to update a value based on an attribute - but this is something that Ember can solve (they've stated intent to support Web Components). So - it was extra code to map the input's value to the custom element (and I didn't do a very robust job of it) - but I'll let you draw your own conclusions. In my opinion - it's definitely not as ideal as the subclass - but maybe it's not prohibitive either. ** Bonus issue - I didn't know this, but Chrome doesn't upgrade when you add the is= attribute to an element that's already been created. Ember builds up its templates into document fragments - so the input failed to upgrade in Chrome. This doesn't happen with the polyfill, however, so I got around the issue by forcing the polyfill to override the native document.registerElement. Chris On Wed, Feb 4, 2015 at 1:15 PM, Ryosuke Niwa <[email protected]> wrote: > > > On Feb 4, 2015, at 11:11 AM, Chris Bateman <[email protected]> wrote: > > > > Ugh, I forgot about that. Without subclassing - terseness is a very > minor drawback, but remapping the interface is a big pain. > > Could you give us a concrete use case in which remapping the interface is > necessary or hard/impossible to do? > > - R. Niwa > > >
