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

Let me try and repeat this back to you, standards-nerd-style:

Now that we have custom elements, there's even more need for notifying a
style engine of a change in internal elements state -- that is, without
expressing it in attributes (class names, ids, etc.). We want the ability
to make custom pseudo classes.

Now, Busta Rhymes-style

Yo, I got change
In my internal state.
Style resolution
It ain't too late.
We got solution!
To save our a**ses
That's right, it's custom pseudo classes.

:DG<


On Tue, 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
>