W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Minimum viable custom elements

From: Chris Bateman <chrisb808@gmail.com>
Date: Thu, 5 Feb 2015 09:13:55 -0600
Message-ID: <CA+wC_+sgSLwW7-4w6FS6RXMemR8wq2CLoXpZLiZP2ztczpRCvA@mail.gmail.com>
To: Ryosuke Niwa <rniwa@apple.com>
Cc: Brian Kardell <bkardell@gmail.com>, Alice Boxhall <aboxhall@google.com>, Anne van Kesteren <annevk@annevk.nl>, Steve Faulkner <faulkner.steve@gmail.com>, WebApps WG <public-webapps@w3.org>
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>:

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


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
Received on Thursday, 5 February 2015 15:14:47 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC