Re: Minimum viable custom elements
As an example I made a simple input-based Custom Element which prevents alphabetic input, and dropped it in an very simple Ember app. Here's the version with a subclassed : http://jsbin.com/mevemu/1/edit?html,output And the version with an nested in a custom element: http://jsbin.com/hepuvif/1/edit?html,output. The custom element adds an input if one wasn't provided in the markup. Click the "Show" button to inject the CE. The CE is registered at the top, and the template (where it's included) is at the bottom. Note that the 2nd version isn't completely functional because Ember isn't expecting to update a value based on an attribute - but this is something that Ember can solve (they've stated intent to support Web Components). So - it was extra code to map the input's value to the custom element (and I didn't do a very robust job of it) - but I'll let you draw your own conclusions. In my opinion - it's definitely not as ideal as the subclass - but maybe it's not prohibitive either. ** Bonus issue - I didn't know this, but Chrome doesn't upgrade when you add the is= attribute to an element that's already been created. Ember builds up its templates into document fragments - so the input failed to upgrade in Chrome. This doesn't happen with the polyfill, however, so I got around the issue by forcing the polyfill to override the native document.registerElement. Chris On Wed, Feb 4, 2015 at 1:15 PM, Ryosuke Niwa wrote: > > > On Feb 4, 2015, at 11:11 AM, Chris Bateman wrote: > > > > Ugh, I forgot about that. Without subclassing - terseness is a very > minor drawback, but remapping the interface is a big pain. > > Could you give us a concrete use case in which remapping the interface is > necessary or hard/impossible to do? > > - R. Niwa > > >
Re: Minimum viable custom elements
Ugh, I forgot about that. Without subclassing - terseness is a very minor drawback, but remapping the interface is a big pain. On Wed, Feb 4, 2015 at 1:01 PM, Brian Kardell wrote: > On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall wrote: >> On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa wrote: >> >>> >>> On Feb 4, 2015, at 10:12 AM, Brian Kardell wrote: >>> >>> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman >>> wrote: >>> >>>> 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 >>>> >>>> >>> As I pointed out ealier: >>> >>> >>> >>> >>> >>> seems like barely a ternseness savings worth discussing. >>> >>> >>> Indeed. Also, authors are used to the idea of including a fallback >>> content inside an element after canvas and object elements and this fits >>> well with their mental model. >>> >> >> I'm just trying to get my head around this pattern. In this example, does >> the web page author or the custom element developer embed the input? And >> who is responsible for syncing the relevant attributes across? In reality, >> isn't this going to look more like >> >> >> >> >> >> or as a slightly contrived example, >> >> >> >> >> >> Or does the custom element get its state from the embedded element? >> > the custom element uses its contents as input and, in the simplest sense, > just moves it or maps it during creation... In a more complicated world > with something more like shadow dom (a separate topic) it might be > 'projected' > -- > Brian Kardell :: @briankardell :: hitchjs.com
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 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 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: >> >> - >> - and a page-level listener >> - and call a function after it's >> injected > Or . 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. >> >> >> >> 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
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: - - and a page-level listener - 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 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. 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 wrote: > > On Feb 3, 2015, at 7:13 AM, Chris Bateman 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 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 > >
Re: Minimum viable custom elements
> > 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 that automatically resizes itself? 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. Chris On Mon, Feb 2, 2015 at 9:40 PM, Ryosuke Niwa wrote: > > On Jan 31, 2015, at 10:40 AM, Chris Bateman wrote: > > The -webkit-appreance CSS is definitely another issue, so here's an > example with just JS behavior: > > > > This component would only allow numeric input, and insert decimals, > commas, etc. Let's just assume that devs want to do this kind of thing. > Here's an example I found of a such behavior: > http://opensource.teamdf.com/number/examples/demo-as-you-type.html > > > Thanks for a great use case. I think this is a problem we should solve > one way or another but I’m not convinced custom elements is the best > solution for the problem at hand. > > If we accept that being able to specify the number of decimal points is a > valid use case, I hope we can all agree that being able to specify the > radix or the base of the number is also a valid use case. Suppose we > authors should be able to specify this with attribute "radix" where its > value is any natural number between 1 and 15. If we follow the school of > thought in your proposal, then we would either add > is="number-with-radix-input" (case A) or make "number-input" support both > support "decimals" and "radix" attributes (case B). > > Case A: In this case, we quickly run into a combinatorial explosion. As > we add k new attributes to support, we would need 2^k elements in order to > support every combination. But this is silly because it's okay for authors > to not use attributes supported by an element. This brings us to case B. > > Case B: If we accept that we should create a single element that supports > all extensions, then why do we use "is" attribute at all? Why don't we > just make all input elements support these new attributes we're adding? > > The best thing you get from using a Custom Element here is the component's > ability to automatically initialize (and destroy) itself. If it's inserted > into the page dynamically (via AJAX, templates in a SPA, or whatever), it > just sets itself up. > > > What kind of initializations does it have to do? It seems like all the > component has to do is to listen to the event listener, in addition to > potentially sanitizing the value if the original value had more than two > decimal points. > > If JS fails, you've still got an input. It was succinct and easy to set > up. And if the app wants to get or set the value, it just does it the same > way it always interfaces with an input. > > > Indeed the fallback scenario is very interesting here but again, it seems > like there is no reason to use "is" attribute at all. We can just extend > all input elements by attaching event listeners, etc... > > - R. Niwa > >
Re: Minimum viable custom elements
The -webkit-appreance CSS is definitely another issue, so here's an example with just JS behavior: This component would only allow numeric input, and insert decimals, commas, etc. Let's just assume that devs want to do this kind of thing. Here's an example I found of a such behavior: http://opensource.teamdf.com/number/examples/demo-as-you-type.html The best thing you get from using a Custom Element here is the component's ability to automatically initialize (and destroy) itself. If it's inserted into the page dynamically (via AJAX, templates in a SPA, or whatever), it just sets itself up. If JS fails, you've still got an input. It was succinct and easy to set up. And if the app wants to get or set the value, it just does it the same way it always interfaces with an input. Alternative 1: no Custom Element: The downside here is that there's no automatic initialization/destruction. Which is ok if the element is never dynamically inserted, but not so great when it is - you're going to have to call a function to initialize it. Alternative 2: regular Custom Element: When this thing initializes, let's say it adds a native as a child (or in a shadow root), so that it doesn't have to manually add all the necessary accessibility items Steve has pointed out. Of course, you get nothing if JS fails. As a backup, you could certainly ask page authors to add the themselves - but that's starting to defeat the goal of having simple declarative custom elements (if that is indeed a goal). Maybe it wouldn't be the end of the world though: Brian also mentioned the possibility of server-side rendering of the createdCallback, but that certainly won't be feasible for everyone's server-side environments. Additionally - you'll need to create an API on the so the app can get and set the value. Of course you'd be doing this anyhow with any regular Custom Element - but it'd be nice to skip if you could. Anyhow - point is just that I see value in the ability to add Custom Element callbacks to native elements. Thanks for all your work on everything here! Chris Bateman On Fri, Jan 30, 2015 at 10:46 AM, Anne van Kesteren wrote: > On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner > wrote: > > In this radio and checkbox example (view in chrome) > > https://rawgit.com/alice/web-components-demos/master/index.html > > (which has been referenced several times in this thread, but no one has > > critiqued to my knowledge) all of the above are evident, while at the > same > > time appearing to overcome the issue of standard control fugliness > > The only way it overcomes that is by relying on a proprietary > extension called -webkit-appearance that is not standardized and does > not work reliably across browsers. Furthermore, it's not at all clear > to me why that example needs custom elements to begin with. If we > assume this proprietary extension exists, we can just do this: > > http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397 > > Which is much much simpler and requires none of the HTML imports, > shadow tree, and all that script. It's also fully accessible and > backwards compatible to the same extent. And shows that the real > tidbit here is -webkit-appearance and not custom elements at all. > > (For identical styling you need to move the background-image line into > a distinct input:checked selector block. I messed up a bit with copy > and pasting.) > > > -- > https://annevankesteren.nl/ > >
Re: Minimum viable custom elements
That does not prevent the entering of alphabetic characters, does not add commas, and does not format to a precise number of decimals . Maybe you'd argue that these things shouldn't be done - but I'd think the existence of multiple libraries that do these things demonstrates that it's a valid need. On Mon, Feb 2, 2015 at 4:36 AM, Anne van Kesteren wrote: > On Sat, Jan 31, 2015 at 7:40 PM, Chris Bateman > wrote: > > The -webkit-appreance CSS is definitely another issue, so here's an > example > > with just JS behavior: > > > > > > The way to do this, FWIW, is and solve > the styling issue. > > > -- > https://annevankesteren.nl/ >
