Re: [custom-elements] :unresolved and :psych
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 bkard...@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
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 rn...@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 bkard...@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
Re: [custom-elements] :unresolved and :psych
On Wed, Mar 26, 2014 at 4:53 PM, Scott Miles sjmi...@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 rn...@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 bkard...@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
RE: [custom-elements] :unresolved and :psych
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.comhttp://hitchjs.com/
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 bkard...@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
Re: [custom-elements] :unresolved and :psych
On Tue, Mar 25, 2014 at 6:10 PM, Domenic Denicola dome...@domenicdenicola.com wrote: 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. Only really the fact that select exposes no clue already that it isn't :unresolved or something. You can see how the hint of an I'm not ready yet can be interpreted this way. Precisely, if someone created an x-select data-src=... kind of tag, then yes, I do think most people would think that that indicated when the actual (populated) element was ready. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: [custom-elements] :unresolved and :psych
On Tue, Mar 25, 2014 at 6:27 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: 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 Probably it comes as no shock that I agree with our want to push Custom Pseudo-Class forward, and I am *very* pro experimenting in the community (#extendthewebforward), so - in fact, I am already experimenting with both Custom Pseudo-Classes in general and this specific case (returning a promise). I'm happy to go that route entirely, but I'm sharing because I am seeing a fair amount of confusion over :unresolved as currently defined. In the least case, we might make an effort to spell it out in the spec a little more and let people know when we talk to them. Ultimately, from what I am seeing on the ground, it seems like :loaded or :ready or something which is potentially component author-informed is actually actually way more useful a thing for us to wind up with We'll see, I'm not trying to push it on anyone, I'm just trying to pick the brains of smart people and provide feedback into the system (tighten the feedback loop, right). -- Brian Kardell :: @briankardell :: hitchjs.com
RE: [custom-elements] :unresolved and :psych
It seems to me you probably should have just not included :unresolved in your
very small subset. In reality, it seems, :unresolved for existing elements is
just { display: none; }. That is, if you do
`selectoptiona/option/select` you don't see the unstyled string a on
the page, only later replaced by a fully-styled dropdown control. You just see
nothing, or you see the dropdown control. It's *that* which :unresolved
explains. It says nothing about the data actually being present or loaded or
mutated. So I don't see how anyone should have any expectations that
:unresolved will be more useful than that, as our existing platform doesn't
have such useful pseudo-classes.
