W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Minimum viable custom elements

From: Chris Bateman <chrisb808@gmail.com>
Date: Wed, 4 Feb 2015 08:43:55 -0600
Message-ID: <CA+wC_+uUOVxGVgsKEKm5PdbnckrP7msftnk6pu1XDSm+xQ=Z+w@mail.gmail.com>
To: Ryosuke Niwa <rniwa@apple.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, Steve Faulkner <faulkner.steve@gmail.com>, WebApps WG <public-webapps@w3.org>
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

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:

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.


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
Received on Wednesday, 4 February 2015 14:44:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:43 UTC