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

On Wed, Mar 26, 2014 at 4:53 PM, Scott Miles <sjmiles@google.com> wrote:

> 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
>>
>>
>>
>

Just to be clear, so there is no confusion (because I realize after talking
to Dimitri that I was being pretty long winded about what I was saying):
 I'm simply saying what y'all are saying - the element is in the best place
to know that it's really "fully cooked".  Yes, there could be N potential
states between 0 and "fully cooked" too, but we do know (at least I am
seeing repeatedly) that folks would like to participate in saying "ok, now
I am fully cooked" so that the CSS for it can be simple and sensible.

I'm not looking to change anything specifically (except maybe a little more
explicit callout of that in the spec), I'm just providing this feedback so
that we can all think about it in light of other proposals and
conversations we're all having and - maybe - if someone has good ideas you
could share them (offlist if you prefer, or maybe in public-nextweb) so
that those of us who are experimenting can try them out in library space...



-- 
Brian Kardell :: @briankardell :: hitchjs.com