Do custom elements present any new challenges in comparison to non-custom elements here? I feel like you have the same issue with filling a <select> with data from a remote source.
________________________________ From: Brian Kardell <bkard...@gmail.com> Sent: Tuesday, March 25, 2014 17:31 To: public-webapps@w3.org Subject: [custom-elements] :unresolved and :psych I'm working with several individuals of varying skillsets on using/making custom elements - we are using a way cut-back subset of what we think are the really stable just to get started but I had an observation/thought that I wanted to share with the list based on feedback/experience so far... It turns out that we have a lot of what I am going to call "async components" - things that involve calling 1 or more services during their creation in order to actually draw something useful on the screen. These range from something simple like an RSS element (which, of course, has to fetch the feed) to complex wizards which have to consult a service to determine which view/step they are even on and then potentially additional request(s) to display that view in a good way. In both of these cases I've seen confusion over the :unresolved pseudo-class. Essentially, the created callback has happened so from the currently defined lifecycle state it's ":resolved", but still not useful. This can easily be messed up at both ends (assuming that the thing sticking markup in a page and the CSS that styles it are two ends) such that we get FOUC garbage between the time something is ":resolved" and when it is actually conceptually "ready". I realize that there are a number of ways to work around this and maybe do it "properly" such that this doesn't happen, but there are an infinitely greater number of ways to barf unhappy content into the screen before its time. To everyone who I see look at this, it seems they conceptually associate :resolved with "ok it's ready," and my thought is "that isn't necessarily an insensible thing to think since there is clearly a pseudo-class about 'non-readiness' of some kind and nothing else that seems to address this". I see a few options, I think all of them can be seen as enhancements, not necessary to a v1 spec if it is going to hold up something important. The first would be to let the created callback optionally return a promise - if returned we can delay :resolved until the promise is fulfilled. The other is to introduce another pseudo like ":loaded" and let the author participate in that somehow, perhaps the same way (optionally return a promise from created). Either way, it seems to me that if we had that, my folks would use that over the current definition of :resolved in a lot of cases. -- Brian Kardell :: @briankardell :: hitchjs.com<http://hitchjs.com/>
