Maybe the problem comes from not distinguishing elements being created and ready for API access versus elements is ready for interactions?
I’d also imagine that the exact appearance of a custom element between the time the element is created and the time it is ready for interaction will depend on what the element does. e.g. img behaves more or less like display:none at least until the dimension is available, and then updates the screen as the image is loaded. iframe on the other hand will occupy the fixed size in accordance to its style from the beginning, and simply updates its content. Given that, I’m not certain adding another pseudo element in UA is the right approach here. I suspect there could be multiple states between the time element is created and it’s ready for user interaction for some custom elements. Custom pseudo, for example, seems like a more appealing solution in that regard. - R. Niwa On Mar 25, 2014, at 2:31 PM, Brian Kardell <[email protected]> wrote: > 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
