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 <[email protected]> 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 <[email protected]> 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
