Re: Minimum viable custom elements

> On Jan 31, 2015, at 10:40 AM, Chris Bateman <chrisb808@gmail.com> wrote:
> 
> The -webkit-appreance CSS is definitely another issue, so here's an example with just JS behavior:
> 
> <input is="number-input" decimals="2">
> 
> This component would only allow numeric input, and insert decimals, commas, etc. Let's just assume that devs want to do this kind of thing. Here's an example I found of a such behavior: http://opensource.teamdf.com/number/examples/demo-as-you-type.html <http://opensource.teamdf.com/number/examples/demo-as-you-type.html>
Thanks for a great use case.  I think this is a problem we should solve one way or another but I’m not convinced custom elements is the best solution for the problem at hand.

If we accept that being able to specify the number of decimal points is a valid use case, I hope we can all agree that being able to specify the radix or the base of the number is also a valid use case.  Suppose we authors should be able to specify this with attribute "radix" where its value is any natural number between 1 and 15.  If we follow the school of thought in your proposal, then we would either add is="number-with-radix-input" (case A) or make "number-input" support both support "decimals" and "radix" attributes (case B).

Case A: In this case, we quickly run into a combinatorial explosion.  As we add k new attributes to support, we would need 2^k elements in order to support every combination.  But this is silly because it's okay for authors to not use attributes supported by an element.  This brings us to case B.

Case B: If we accept that we should create a single element that supports all extensions, then why do we use "is" attribute at all?  Why don't we just make all input elements support these new attributes we're adding?

> The best thing you get from using a Custom Element here is the component's ability to automatically initialize (and destroy) itself. If it's inserted into the page dynamically (via AJAX, templates in a SPA, or whatever), it just sets itself up.

What kind of initializations does it have to do?  It seems like all the component has to do is to listen to the event listener, in addition to potentially sanitizing the value  if the original value had more than two decimal points.

> If JS fails, you've still got an input. It was succinct and easy to set up. And if the app wants to get or set the value, it just does it the same way it always interfaces with an input.

Indeed the fallback scenario is very interesting here but again, it seems like there is no reason to use "is" attribute at all.  We can just extend all input elements by attaching event listeners, etc...

- R. Niwa