Re: Minimum viable custom elements

Assuming a situation where a native element – with custom functionality –
is dynamically injected into the page, the basic options I can think of are:

 - <input is="my-custom-formatter">
 - <input class="my-custom-formatter"> and a page-level listener
 - <input class="my-custom-formatter"> and call a function after it's
injected

Option 3 is really cumbersome, in my opinion. Option 2 could work, except
for A. when I want to execute some functionality right away, and B. when
the native element won't be sending events to hook onto.

An better example of both A and B (than my previous hypothetical) might be
GitHub's <time is="relative-time"> extension:
https://github.com/github/time-elements/.


I'm not certain having two different mechanisms, namely "type" and "is"
> attributes, to specify the type of an input an element expects is a
> desirable approach.


<input type="text" is="my-custom-formatter">

I certainly can't speak to your perspective on this, and you may be right.
An input's probably not be the best example for making is="" look good.
Regardless, I have to trust that devs are smart enough to figure out what's
going on here, and set it up properly.

Chris



On Tue, Feb 3, 2015 at 2:04 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

>
> On Feb 3, 2015, at 7:13 AM, Chris Bateman <chrisb808@gmail.com> wrote:
>
> 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?
>
>
> That sounds like a slightly different use case. Social security number,
> credit card number, etc… seems like a different input type to me while
> "numerals" or "radix" attributes are extra configurations/options each
> input type may respect.  While I agree allowing author defined input types
> will be useful, I'm not certain having two different mechanisms, namely
> "type" and "is" attributes, to specify the type of an input an element
> expects is a desirable approach.
>
> 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.
>
>
> That sounds rather hypothetical to me.  I would like to know a concrete
> use case in which the initialization of an author defined input type or an
> input configuration/option is impossible or too cumbersome to be
> implemented using existing API.
>
> Adding a new feature to the Web platform incurs an inherently higher cost
> because multiple vendors have to coordinate, and removing or changing the
> behavior of a feature is virtually impossible.
>
> - R. Niwa
>
>