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

Re: Minimum viable custom elements

From: Erik Bryn <erik@erikbryn.com>
Date: Thu, 5 Feb 2015 10:41:09 -0800
Message-ID: <CAGJrKUo8WCoO1UA8Yt8WP1i2WB2NEuEq3YNjFAWaRoAG89zCTw@mail.gmail.com>
To: Chris Bateman <chrisb808@gmail.com>
Cc: Ryosuke Niwa <rniwa@apple.com>, 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>
Thanks for the mentioning the Ember issue Chris :) I've filed it here:
https://github.com/tildeio/htmlbars/issues/288

On Thu, Feb 5, 2015 at 7:13 AM, Chris Bateman <chrisb808@gmail.com> wrote:
> 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
>>
>>
>
Received on Thursday, 5 February 2015 18:41:58 UTC

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