Re: [custom-elements] :unresolved and :psych

Yes, I agree with what R. Niwa says.

I believe there are many variations on what should happen during element
lifecycle, and the element itself is best positioned to make those choices.

`:unresolved` is special because it exists a-priori to the element having
any control.

Scott


On Wed, Mar 26, 2014 at 12:26 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

> 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 <bkardell@gmail.com> 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
>
>
>