Re: Minimum viable custom elements

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 <rniwa@apple.com> wrote:

>
> > On Feb 4, 2015, at 11:11 AM, Chris Bateman <chrisb808@gmail.com> 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
>
>
>