> On Jan 31, 2015, at 10:40 AM, Chris Bateman <chrisb...@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

Reply via email to