Re: Minimum viable custom elements

Yeah, I had noted in that post that wrapping a native element with a custom element was an option - only drawback is that the markup isn't as terse (which is generally advertised as one of the selling points of Custom Elements). But that doesn't seem like a deal breaker to me, if subclassing needs to be postponed.




Chris

On Wed, Feb 4, 2015 at 10:51 AM, Ryosuke Niwa <rniwa@apple.com> wrote:

> See https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html <https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html> first.
>> On Feb 4, 2015, at 6:43 AM, Chris Bateman <chrisb808@gmail.com> wrote:
>> 
>> 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
> Or <my-custom-formatter><input></my-custom-formatter>.  Note that the author of the custom element can force the markup to have an input element inside by making the element not function when there isn't one on the contrary to what you said in https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0410.html <https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0410.html>  Since custom elements aren't supported by all browsers initially, authors have to implement the fallback anyway.
>> 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.
> I'd say that line of thought could be dangerous in that once we say we should trust devs to the right thing, we may just say devs should do the right thing for accessibility for themselves.  Since the point of Web components is to improve developer ergonomics, I don't think we should assume developers to be particularly "smart" or "experienced".  We want to make the Web a place where everyone can start writing great apps without knowing some weird quirks of the platform.
> - R. Niwa