> On Feb 3, 2015, at 7:13 AM, Chris Bateman <chrisb...@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
