Re: Minimum viable custom elements

>
> Why don't we just make all input elements support these new attributes
> we're adding?


In my opinion, I'd say because you can't possibly cover every case - what
about doing the same kind of formatting for social security numbers, credit
card numbers, phone numbers, or who knows what else? How about other kinds
of functionality - like a <textarea> that automatically resizes itself?

What kind of initializations does it have to do?


Yes, probably just adding a listener in this case – which you certainly
could handle with event delegation. But maybe someone might want to simply
execute some functionality when the element is created or attached. An
input that automatically populates itself with a random number. An awful,
contrived example for sure - but it wouldn't be possible with delegation
alone.

Again - simply wanted to make the point that devs do add functionality to
native elements - so it might be handy to have custom element callbacks to
assist with it.

Chris



On Mon, Feb 2, 2015 at 9:40 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

>
> 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
>
>
> 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
>
>